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

Groups > comp.arch.embedded > #25559 > unrolled thread

UDP Terminal Protocol

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#25559 — UDP Terminal Protocol

Many devices have had a serial port for attaching a console of some
sort, for low-level configuration/diagnostic work.  While very simple
to implement, serial ports have issues which don't need repeating.

An obvious alternative is to implement the "serial console" as a
TELNET server.  Conceptually this is trivial, not to mention well
standardized and well understood.  OTOH, this piles on a fair bit of
complexity, and requires something akin to a full TCP/IP stack.  And
if you're going to do that, you might as well just go for a web-based
admin, it's only going to be a bit more work.

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. IOW, something
with a relationship to TELNET sort of like TFTPs relationship to FTP.

OTOH, despite looking, I just don't see any standards for doing that
sort of thing.  Am I just missing it?  Is there a defacto standard
even if there's no RFC?

[toc] | [next] | [standalone]

#25560

On 13.12.2016 г. 12:23, Robert Wessel wrote:
> Many devices have had a serial port for attaching a console of some
> sort, for low-level configuration/diagnostic work.  While very simple
> to implement, serial ports have issues which don't need repeating.
>
> An obvious alternative is to implement the "serial console" as a
> TELNET server.  Conceptually this is trivial, not to mention well
> standardized and well understood.  OTOH, this piles on a fair bit of
> complexity, and requires something akin to a full TCP/IP stack.  And
> if you're going to do that, you might as well just go for a web-based
> admin, it's only going to be a bit more work.
>
> 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. IOW, something
> with a relationship to TELNET sort of like TFTPs relationship to FTP.
>
> OTOH, despite looking, I just don't see any standards for doing that
> sort of thing.  Am I just missing it?  Is there a defacto standard
> even if there's no RFC?
>

I suppose you have found nothing simply because doing telnet over
UDP will take reinventing tcp. tcp is very well designed, I can't
see how it can be simplified while retaining its basic functionality.
I would expect there are super minimalistic tcp implementations
which might more or less work and would do what you need but I
don't really know what is out there, I have only written the
tcp for dps which is not minimalistic.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#25569

On Tue, 13 Dec 2016 17:10:44 +0200, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 13.12.2016 ?. 12:23, Robert Wessel wrote:
>> Many devices have had a serial port for attaching a console of some
>> sort, for low-level configuration/diagnostic work.  While very simple
>> to implement, serial ports have issues which don't need repeating.
>>
>> An obvious alternative is to implement the "serial console" as a
>> TELNET server.  Conceptually this is trivial, not to mention well
>> standardized and well understood.  OTOH, this piles on a fair bit of
>> complexity, and requires something akin to a full TCP/IP stack.  And
>> if you're going to do that, you might as well just go for a web-based
>> admin, it's only going to be a bit more work.
>>
>> 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. IOW, something
>> with a relationship to TELNET sort of like TFTPs relationship to FTP.
>>
>> OTOH, despite looking, I just don't see any standards for doing that
>> sort of thing.  Am I just missing it?  Is there a defacto standard
>> even if there's no RFC?
>>
>
>I suppose you have found nothing simply because doing telnet over
>UDP will take reinventing tcp. tcp is very well designed, I can't
>see how it can be simplified while retaining its basic functionality.
>I would expect there are super minimalistic tcp implementations
>which might more or less work and would do what you need but I
>don't really know what is out there, I have only written the
>tcp for dps which is not minimalistic.


Sure, doing TCP *well* requires pretty much re-inventing TCP.  But the
requirements here are much lower than that.  Performance requirements
are minimal, and operation over WANs (especially efficient operation
over WANs) is not really an issue either.  And it's already been done.
A lot.  I just want to know how.  Again, TFTP is an example of a
solution to a very similar problem.

[toc] | [prev] | [next] | [standalone]

#25561

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

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

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.

> OTOH, despite looking, I just don't see any standards for doing that
> sort of thing.  Am I just missing it?  Is there a defacto standard
> even if there's no RFC?

If you want something reliable that works over WANs, use TCP: it's the
only way you're going to dependably make anything work through a
firewall.

If you're going to assume local Ethernet, you can just use UDP.

-- 
Grant Edwards               grant.b.edwards        Yow! Gee, I feel kind of
                                  at               LIGHT in the head now,
                              gmail.com            knowing I can't make my
                                                   satellite dish PAYMENTS!

[toc] | [prev] | [next] | [standalone]

#25562

On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

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

Thanks for the pointer to netcat.

I tried to find out , does it also support raw ethernet frames (with
MAC addressing) so that it could work without IP-headers and ARP ?

[toc] | [prev] | [next] | [standalone]

#25564

On 2016-12-13, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
><invalid@invalid.invalid> wrote:
>
>>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.
>
> Thanks for the pointer to netcat.
>
> I tried to find out , does it also support raw ethernet frames (with
> MAC addressing) so that it could work without IP-headers and ARP ?

I don't think so.

It's trivial to write something (on Linux) in Python that bascially
does what "netcat" does but in MAC mode.  On Windows, it's way more
work...

-- 
Grant Edwards               grant.b.edwards        Yow! Will it improve my
                                  at               CASH FLOW?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#25566

On 14/12/16 08:13, Grant Edwards wrote:
> On 2016-12-13, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
>> <invalid@invalid.invalid> wrote:
>>
>>> 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.
>>
>> Thanks for the pointer to netcat.
>>
>> I tried to find out , does it also support raw ethernet frames (with
>> MAC addressing) so that it could work without IP-headers and ARP ?
>
> I don't think so.
>
> It's trivial to write something (on Linux) in Python that bascially
> does what "netcat" does but in MAC mode.  On Windows, it's way more
> work...
>

libpcap has pcap_sendpacket, which I think does what you want,
including on Windoze

[toc] | [prev] | [next] | [standalone]

#25565

On 12/13/2016 08:51 AM, upsidedown@downunder.com wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> wrote:
>
>> 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.
>
> Thanks for the pointer to netcat.
>
> I tried to find out , does it also support raw ethernet frames (with
> MAC addressing) so that it could work without IP-headers and ARP ?
>

There's a Linux program called socat that will do that type of thing. 
It's not installed by default but should be easy to get.

[toc] | [prev] | [next] | [standalone]

#25568

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.


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


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

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.


>> OTOH, despite looking, I just don't see any standards for doing that
>> sort of thing.  Am I just missing it?  Is there a defacto standard
>> even if there's no RFC?
>
>If you want something reliable that works over WANs, use TCP: it's the
>only way you're going to dependably make anything work through a
>firewall.


Sure, no disagreement there.  And no, operation over WANs is not a
prime consideration, although it certainly wouldn't hurt if it could,
even if the user had to deal with firewall issues, or set up a relay
server of some sort.  But the scope would be within a data-center, or
perhaps campus (assuming at least real IP address assignment - without
that, local LAN).  Remember the idea here is to replace a serial
console port.


>If you're going to assume local Ethernet, you can just use UDP.

[toc] | [prev] | [next] | [standalone]

#25573

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]

[toc] | [prev] | [next] | [standalone]

#25581

On Wed, 14 Dec 2016 15:29:47 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 12/14/2016 12:28 PM, Robert Wessel wrote:
>> 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


Yes, that's why I mentioned it as an example of a protocol solving a
similar problem.


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


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


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

[toc] | [prev] | [next] | [standalone]

#25583

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.

[toc] | [prev] | [next] | [standalone]

#25591

Don Y wrote:
> On 12/14/2016 12:28 PM, Robert Wessel wrote:
<snip>
> 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.
>

I am pretty sure bootp only works on local segments. Not 100% sure about 
TFTP, but I would be surprised if it survived fragmentation or
changes in sequencing.

<snip>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25592

On 12/15/2016 8:52 PM, Les Cargill wrote:
> Don Y wrote:
>> On 12/14/2016 12:28 PM, Robert Wessel wrote:
> <snip>
>> 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.
>
> I am pretty sure bootp only works on local segments. Not 100% sure about TFTP,
> but I would be surprised if it survived fragmentation or
> changes in sequencing.

Classic TFTP only allows one outstanding packet.  Later revisions
allow a window size to be negotiated -- essentially allowing
multiple packets to be on the wire (from the standpoint of the
client) simultaneously.  Client-side code decides which packets
to acknowledge and when.  So, if a packet 5 (of 1-8 in this window)
arrives later than the client "planned", 1-4 are acknowledged
causing 5-12 to be sent in the next window... even if the "first" 5
arrives just after the ack has been sent.

You can workaround fragmentation by negotiating a suitable packet
size (yet another extension to the original TFT protocol).

I.e., you can conceivably configure TFTP to bridge routers
*if* that's a deliberate goal.

BOOTP only addresses the idea of centralizing the devices'
configurations (instead of having to push them into the
device at "install time").  DHCP can achieve similar results
(in a more modern approach).

[Of course, you can also bastardize any number of protocols
to come up with your own approach -- "downloading" configuration
"files" that are named (by convention) with the MAC address
of the device in question, etc.  But, you want to be cognizant of
typical "best practices" so you don't pose a system configuration
headache for the network administrator(s)]

[toc] | [prev] | [next] | [standalone]

#25574

Robert Wessel <robertwessel2@yahoo.com> writes:
> 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.

I still don't see the problem: TCP has been around for decades and there
are some tiny implementations, especially if you don't need multiple
packets in the air at the same time etc.  Why not just use one?

[toc] | [prev] | [next] | [standalone]

#25579

On Wed, 14 Dec 2016 15:22:42 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>> 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.
>
>I still don't see the problem: TCP has been around for decades and there
>are some tiny implementations, especially if you don't need multiple
>packets in the air at the same time etc.  Why not just use one?


That may well be the way we go, but given that more than a few
UPD-only implementations have been done, I was trying to determine if
a lighter-weight alternative was feasible.

[toc] | [prev] | [next] | [standalone]

#25575

Robert Wessel <robertwessel2@yahoo.com> 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.

My experience with TFTP in early nineties was that on our
network attempting to send file larger than 1MB will usually
stall.  We had several segments of thin Etehrent connected
via a repeater and used cheap equipement.  TCP run with
quite resonable performance, but TFTP was essentially
unusable.  Apparently TFTP specification was extended
to get better reliability (or maybe our implemetation
dropped optional parts), but it seems that using raw UDP
will give you _more_ reliability than I got from TFTP.
More preciesely, IIRC both at Ehernet level and IP level
you get a checksum for each packet.  You are talkong
about low performance, so presumably no need to throttle
transmission.  At low speed in local network there
should be no problem with reordering packets.  As my
expample shows in practice TFTP was unable to retransmit
missing packets.  Together this means that acknowledgements
buy you nothing => you are end up at raw UDP level.

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

Well, maybe modern TFTP is better, but IME TFTP did _not_ address
the isssues.

I think you look at your problem from wrong point of view.  Once
you want decent capability for transmitting streams of data you
end up with something very similar to TCP.  So better question
is: "what parts of typical TCP implementation can be safely
skipped and which existing implementation has good support
for doing so".  Partial answer is: TCP implementation can be
simplified quite a lot and still work reasonably well.
Commer and Stevens in their 1994 book described "complete"
implementation of Internet protocls, their code was simple
but they tried to cover all required parts.
They wrote that they needed about 3000 LOC for TCP
(and slightly larger amount for mamdatory lower level parts).
If you limit their implementation to TCP only (+ needed lower
level parts) it will by probably 60% bigger than UDP only (again
UDP + needed lower level parts).  Compared to 1994 TCP
was extended, but it seems safe to assume that even in
modern network you should be able to use implementation
having 6000 LOC (for TCP and lower layers, but exluding
hardware handling).  This 6000 LOC-s is likely to
produce no more than 8-16 KB of machine code.  RAM
overhead is of order few hundreds bytes per connection
plus needed buffering (likely few kilobytes).  If
you want reliable transmission you need buffering
(to be able to retransmit) so extra requirements
seem to be quite modest.  And if you have enough free
RAM you probly also have enough program space (typical
MCU-s seem to have much more program space than RAM).
Of course, you may use tiny MCU with external
Ethernet (or Wifi) chip providing buffering, but
if you add such a chip to existing system maybe
it is better to add a "communication processor"
that handles all network aspects (ESP8266 will
do this for Wifi).

The TCP/IP stacks that I know about seem to be larger
than estimate I gave above.  But they have options
to omit parts, so maybe you can trim them down.

Significant part of complexity of TCP comes from
handling long streams.  If you can live with small
HTTP pages than there is very small implementation
at tuxgraphics.org.  The implementation is quite
small but they do it via limiting HTTP page to
a single Ethernet packet.  This implementation
violates several requirements of TCP/IP, but
seem to work quite well in practice.


-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#25580

On Thu, 15 Dec 2016 01:49:38 +0000 (UTC), antispam@math.uni.wroc.pl
wrote:

>Robert Wessel <robertwessel2@yahoo.com> 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.
>
>My experience with TFTP in early nineties was that on our
>network attempting to send file larger than 1MB will usually
>stall.  We had several segments of thin Etehrent connected
>via a repeater and used cheap equipement.  TCP run with
>quite resonable performance, but TFTP was essentially
>unusable.  Apparently TFTP specification was extended
>to get better reliability (or maybe our implemetation
>dropped optional parts), but it seems that using raw UDP
>will give you _more_ reliability than I got from TFTP.
>More preciesely, IIRC both at Ehernet level and IP level
>you get a checksum for each packet.  You are talkong
>about low performance, so presumably no need to throttle
>transmission.  At low speed in local network there
>should be no problem with reordering packets.  As my
>expample shows in practice TFTP was unable to retransmit
>missing packets.  Together this means that acknowledgements
>buy you nothing => you are end up at raw UDP level.
>
>> 
>> >> 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.
>> 
>> 
>> >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.
>> 
>> 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.
>
>Well, maybe modern TFTP is better, but IME TFTP did _not_ address
>the isssues.


Certainly bad TFTP implementations exist, but there's really nothing
in the protocol that should permit behavior as bad as you describe.


>I think you look at your problem from wrong point of view.  Once
>you want decent capability for transmitting streams of data you
>end up with something very similar to TCP.  So better question
>is: "what parts of typical TCP implementation can be safely
>skipped and which existing implementation has good support
>for doing so".  Partial answer is: TCP implementation can be
>simplified quite a lot and still work reasonably well.
>Commer and Stevens in their 1994 book described "complete"
>implementation of Internet protocls, their code was simple
>but they tried to cover all required parts.
>They wrote that they needed about 3000 LOC for TCP
>(and slightly larger amount for mamdatory lower level parts).
>If you limit their implementation to TCP only (+ needed lower
>level parts) it will by probably 60% bigger than UDP only (again
>UDP + needed lower level parts).  Compared to 1994 TCP
>was extended, but it seems safe to assume that even in
>modern network you should be able to use implementation
>having 6000 LOC (for TCP and lower layers, but exluding
>hardware handling).  This 6000 LOC-s is likely to
>produce no more than 8-16 KB of machine code.  RAM
>overhead is of order few hundreds bytes per connection
>plus needed buffering (likely few kilobytes).  If
>you want reliable transmission you need buffering
>(to be able to retransmit) so extra requirements
>seem to be quite modest.  And if you have enough free
>RAM you probly also have enough program space (typical
>MCU-s seem to have much more program space than RAM).
>Of course, you may use tiny MCU with external
>Ethernet (or Wifi) chip providing buffering, but
>if you add such a chip to existing system maybe
>it is better to add a "communication processor"
>that handles all network aspects (ESP8266 will
>do this for Wifi).


All at least roughly true.  As an aside, though, the LOC count is
wrong in the 1994 edition.  The pie chart is correct, but they didn't
update the LOCs from the 1991 edition, despite adding OSPF and some
other stuff to the implementation.  So from the 1991 edition, you had
26% of the 15KLOC base in TCP (or ~4K, which is about the right number
for their implementation), not 20% of 15KLOCs as in the 1994 edition
(where the count should actually be been ~19KLOCs).  The 4KLOCs in
their SNMP and RIP implementations are omitable.


>The TCP/IP stacks that I know about seem to be larger
>than estimate I gave above.  But they have options
>to omit parts, so maybe you can trim them down.


Yes, in my experience they've all been bigger than that.


>Significant part of complexity of TCP comes from
>handling long streams.  If you can live with small
>HTTP pages than there is very small implementation
>at tuxgraphics.org.  The implementation is quite
>small but they do it via limiting HTTP page to
>a single Ethernet packet.  This implementation
>violates several requirements of TCP/IP, but
>seem to work quite well in practice.


Not really an option, one packet is just going to be too small for
HTTP.

[toc] | [prev] | [next] | [standalone]

#25576

On 2016-12-14, Robert Wessel <robertwessel2@yahoo.com> 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,

By the time you do "packet sequencing and acknowledgements" for both
target and host side, test it, revisit the bad protocol design
decisions, and then re-implement it for both sides you've spent more
time than you would have just doing a simple TCP implementation.

And in the end you've got something that's non-standard, non-portable,
probably still doesn't work right, and for which Wireshark doesn't
have a packet dissector.

Don't underestimate the importance of that last one.

>>> IOW, something with a relationship to TELNET sort of like TFTPs
>>> relationship to FTP.

What features of TELNET do you need?

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

In my experinece the incremental value of Telnet is negative, since
various Telnet clients behave it vastly different and bizarre ways.

YMMV.

> And as I said, if you have TCP, why not just do this with HTTP, and
> really make things convenient for people.

OK.

>>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?  

Um... UDP.

> How many characters can you put in a packet?

UDP says 65536 bytes per datagram.  UDP will fragment that and
reassemble it.  If you want to do a stripped-down UDP iplimentation,
limit it to about 1200.

> Any sequencing or recovery?

Nope.

> Acknowledgements?

Nope.

> Checksums on or off?

For a local Ethernte segment, you let the MAC layer worry about that.

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

Some IP stacks won't receive UDP broadcast packets with a
non-reachable source IP.

> 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?

Unless your Ethernet segment is pretty heavily loaded, I find you can
ignore all that.

If you can't, then you need the equivalent of TCP.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#25577

Grant Edwards <invalid@invalid.invalid> writes:
> you've spent more time than you would have just doing a simple TCP
> implementation.

I still don't understand why the OP would want to "do" (i.e. write) a
simple TCP implementation instead of downloading one.  There are lots,
e.g.:

https://en.wikipedia.org/wiki/UIP_(micro_IP)

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web