Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25583

Re: UDP Terminal Protocol

Show all headers | View raw

On 12/14/2016 11:34 PM, Robert Wessel wrote:
>>> Given how little TELNET actually does (or at least, needs to do), if
>>> you have TCP, there would be no really issue implementing that.  Raw
>>> TCP is obviously an option, but again, the incremental cost to do
>>> actual TELNET is low.  And as I said, if you have TCP, why not just do
>>> this with HTTP, and really make things convenient for people.
>>
>> Have you looked at an *actual* TELNETd implementation?  You're looking
>> at several KLoC's.  You can pare this back by deciding to only
>> advertise certain capabilities.  But, it's not a "weekend job"!
>
> Yes, and I've actually done a couple.  And yes, if you just handle the
> common TELNET commands (which you can mostly ignore, or handle
> trivially), support a minimal number of options (ECHO, SGA, TERMTYPE,
> and BINARY (maybe)?) and maybe accept and TERMINAL-TYPE you get from
> an IAC/SB/TERMTYPE negotiation, it's pretty small.

Given that you're talking about a "console" in a "data center" (as
one application domain), I'd also consider support for encryption (not a
"standard" option in many telnet clients).  Else you risk someone
eavesdropping on the connection(s) and harvesting (console) passwords,
traffic, etc.

I.e., you might find ssh/sshd better (and more modern) alternatives.

Of course, this brings key management into the picture, etc.  Tug
on a loose thread and you never know where it will lead!  :-/

If "campus" is a generic term (i.e., not specifically tied to
academic institutions), then you're faced with a network that
potentially spans multiple buildings/floors/departments/etc.
This suggests internal firewalls, routers, etc.  (which makes
a UDP solution more problematic -- unless you station a "special
host" in each such network segment and let *them* talk to each
otehr).

You'll also have some sort of IT department with which to contend.
And, "local policies".  I.e., certain ports/protocols might be
blocked as a matter of course.

This suggests you may need to offer additional configuration
options for each node.  Which begs the issue of how you maintain
and distribute that configuration information.

It might lead to using something like a BOOTPd -- or DHCPd as the
more modern/flexible alternative.  If you're expecting *many* of these
at a site, then maintenance approaches that lend themselves to
applying a template to a whole set of devices (e.g., a DHCP "class")
can have considerable appeal to the bloke charged with keeping
them all running, NOT having to read MACs printed in 3pt type
off of labels affixed to the underside of devices, etc.

The point of all this is that the cost of TCP might be a small
fraction of the total "consequences" of adopting an ethernet
solution (over a more straight-forward "serial port" approach).

So, instead, you might try approaching the problem with a different
set of assumptions:  assume you *have* a full stack (with some
particular set of capabilities, yet to be quantified).  With that,
what might you do differently?  And, why?  Is it still appropriate
to think of it as providing a "serial port for interactive use"?
Or, might there be other features for which you can leverage this
capability?

>> As you're *probably* not looking for maximum performance, minimum latency,
>> etc. ("It's a serial port!"), you can probably deliberately tone down the
>> implementation so it doesn't tax the fabric *nor* the clients involved
>> (i.e., if you give a client plenty of time to process packet 1 before
>> trying to send packet 2, there's a better chance that it won't DROP
>> packet 2 and, thus, need to re-request it).
>
> That would be the assumed protocol.

That is how RLOGIN works (but, over TCP)

>> [Historically, there have been NICs that would "not see" packets
>> appearing too close to other packets on the wire -- think of it
>> as "hardware bugs" necessitating software work-arounds]
>
> Thank you for reminding me of 3c501s.  I had put that piece of crap
> out of mind decades ago...  The 3c501 was special in that it had only
> one I/O buffer, and it needed to be set to either transmit or receive
> mode.  So if you sent a packet, you'd set it to transmit mode, push
> the packet into the buffer, tell the NIC to send it, and then switch
> the NIC into receive mode.  Unfortunately the switch was slow enough
> that if whoever you sent the packet to was really fast to respond
> (that required a better NIC than a 3c501 at the other end, of course),
> it was not actually possible to get the local NIC into receive mode
> fast enough!  So the "software workaround" was a delay at the other
> end.
>
> Of course the 3c501 had issues with too many consecutive receives as
> well.

Actually, I was thinking at the component level -- specifically,
the LANCE.

But, my point was for you to fold your hardware considerations
into the design of the stack -- instead of trying to work-around them
outside its scope.  I'm guessing you're targeting a SoC implementation...?
A peek at any outstanding "issues" for the chosen target might save
you hassles, later.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 04:23 -0600
  Re: UDP Terminal Protocol Dimiter_Popoff <dp@tgi-sci.com> - 2016-12-13 17:10 +0200
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 13:33 -0600
  Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-13 15:16 +0000
    Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-13 18:51 +0200
      Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-13 21:13 +0000
        Re: UDP Terminal Protocol Clifford Heath <no.spam@please.net> - 2016-12-14 09:05 +1100
      Re: UDP Terminal Protocol Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-12-13 13:23 -0800
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 13:28 -0600
      Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-14 15:29 -0700
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:34 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 01:10 -0700
        Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:52 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 22:00 -0700
      Re: UDP Terminal Protocol Paul Rubin <no.email@nospam.invalid> - 2016-12-14 15:22 -0800
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:00 -0600
      Re: UDP Terminal Protocol antispam@math.uni.wroc.pl - 2016-12-15 01:49 +0000
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:17 -0600
      Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-15 02:06 +0000
        Re: UDP Terminal Protocol Paul Rubin <no.email@nospam.invalid> - 2016-12-14 21:09 -0800
          Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-15 17:38 +0000
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 23:58 -0600
      Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:49 -0600
      Re: UDP Terminal Protocol Morten Reistad <first@last.name.invalid> - 2016-12-24 16:10 +0100
        Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-24 18:53 +0000
          Re: UDP Terminal Protocol Theo Markettos <theom+news@chiark.greenend.org.uk> - 2016-12-25 13:45 +0000
            Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-25 11:44 -0700
  Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-13 12:53 -0700
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:03 -0600
      Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-14 15:09 -0700
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:50 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 11:01 -0700
        Re: UDP Terminal Protocol Morten Reistad <first@last.name.invalid> - 2017-01-15 16:08 +0100
      Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-15 15:08 +0200
  Re: UDP Terminal Protocol wzab01@gmail.com - 2016-12-14 13:16 -0800
  Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-15 12:56 +0200
    Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 11:06 -0700
      Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 16:34 -0600
        Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-27 07:45 +0200
        Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-26 23:00 -0700
          Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2017-01-03 18:48 -0600
  Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:42 -0600
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 17:21 -0600

csiph-web