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

Groups > comp.arch.embedded > #25573

Re: UDP Terminal Protocol

Show all headers | View raw

On 12/14/2016 12:28 PM, Robert Wessel wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> wrote:
>
>> On 2016-12-13, Robert Wessel <robertwessel2@yahoo.com> wrote:
>>
>>> OTOH, it's clear that a number of people have implemented a UDP-based
>>> protocol for handling the sort of things often done with a serial
>>> console attached to a device.  This has a number of advantages - you
>>> can fake UPD over Ethernet with very little code, especially if you
>>> define away things like fragmentation and options.  A simplified
>>> TELNET-ish protocol on top of that would be pretty simple, you just
>>> need some basic packet sequencing and acknowledgements.
>>
>> I know of people who have implemented that on top of IP rather than
>> UDP.  They call it TCP. ;)
>
> Well, yes, but the point is that TCP is a fair chunk of code, and for
> this function it has to go in a spot where it's less than convenient
> to update.  Hence the desire for maximum simplicity.  I used TFTP as
> an example, since it solves a similar problem (and you could
> certatinly trivially implemented a TCP version of TFTP), with similar
> constraints.

TFTP runs using UDP datagrams.  It's simplicity lies in the fact
that it has very few options (that need to be negotiated) and
a window size of 1 packet:  next packet isn't sent until
previous is ACK'd

[lie:  newer RFC's extend TFTP to support multiple outstanding
packets; but, this means a more complicated implementation]

>>> IOW, something with a relationship to TELNET sort of like TFTPs
>>> relationship to FTP.
>>
>> Just use a raw TCP connection. There's no need to implement the TELNET
>> protocol at all.  The Unix command line client will skip all the
>> handshaking stuff if you use a non-standard port.  Or you can use
>> netcat.  Or any number of terminal emulators or COM port redirectors
>> that support raw TCP connections.
>
> 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"!

[I assume the TELNET client is something you'd offload to the user's
responsibility]

And, with a "virtual serial port", other issues crop up that
you may not have anticipated (if you're in a "hardware serial port"
mindset).  E.g., what happens if TWO clients try to connect to your
TELNETd?  Is that a *feature*?  Have you anticipated locks on
the various structs/parameters that the user will be modifying
via these interfaces?  Have you addressed the possibility of a
TELNET session "hanging" and the held locks never being released?

Etc.

[All of this is obvious -- in hindsight!  :> ]

>> If you're on a local Ethernet segment, just use raw UDP.  I've been
>> using both those approaches for close to 20 years, and have never had
>> any problems.
>
> Yet what exactly is the protocol?  How many characters can you put in
> a packet?  Any sequencing or recovery?  Acknowledgements?  Checksums
> on or off?  With UDP (and a bit of consideration at the protocol
> layer), you can even avoid any IP configuration requirements (at least
> on a single LAN) by doing everything with broadcasts.

If you're trying to emulate a serial port, you probably won't *need*
to pack many characters into a datagram.  Figure 500 bytes is "always
safe" and don't even bother trying to negotiate a larger datagram
size.

> I've simply never implemented anything with UDP that didn't take error
> handling into account - is the common practice just to assume that you
> will not lose/reorder/duplicate/mangle any packing so long as you're
> on a local segment?  Again, TFTP addresses those issues, at least as
> they apply to its requirements.

TFTP without the "windowsize" option handles the problem just by requesting
retransmits until you've "got" the next packet IN SEQUENCE.  Support
for the windowsize forces the client to keep track of *which* packets
it's received -- and tolerate the possibility that it might accumulate
them out-of-order in how it frames its acknowledgements.

"No free lunch"

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).

[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]

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