Serial (rs232 etc.) to IP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

Could anyone lend some light into which protocol or technique is used
to actually send I/O from a legacy serial port device onto a TCP/IP
network?  I see there are many products out there, but none of the
product sites describe the actual protocol used on the IP network side.
 An RFC search also came up with nothing, though I could have missed it
as well...  I know that on the client side (such as a Windblows
machine) the IP packets can also then be accessed as a COM port from
the software side...

TIA,
-D


Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

AFAIK there is no 'standard' for the transport of serial traffic over an
IP network. Each case is application-specific. (There may be a few
'system management' standards - I see 'SoL' bandied about - but nothing
generic as far as I can tell).

Usually a generic solution would 'tunnel' serial data over raw UDP/TCP
packets via a proprietory driver, optionally with a PC API for accessing
the serial data at the other end of the network connection. For example,
the API/driver would abstract a virtual serial port over the network.

The actual payload of course is application-specific, and how you choose
to process the data after extracting from the IP packet is completely up
to you.

There's a couple of open-source projects involving serial over ip.

Other 'turn-key' solutions offer boxes that you connect either end of a
network connection to transparently transport serial data. They're using
their own abstraction and it's not visible to the user.

Regards,
Mark

Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

Hi,

have a look at RFC 2217 "Telnet Com Port Control Option"
http://www.faqs.org/rfcs/rfc2217.html

Greetings,
Frieder

Re: Serial (rs232 etc.) to IP
Thanks Frieder,
   I suspect that it is indeed simply a Telnet connection, but no-where
can I confirm that's how it's done, so I imagine that single character
mode is used, and the recieve end does it's own message framing for the
application on the other end.  I'll have to look at how TCP/IP data
payloads are then directed to COM port based applications.

As far as ...
"  ... Other 'turn-key' solutions offer boxes that you connect either
end of a
network connection to transparently transport serial data. They're
using
their own abstraction and it's not visible to the user. "

   I think I already said that...

Thanks,
-D


Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

Telnet isn't a bad way to think of (and debug) it, but a common method
is really just plain TCP to an arbitrary port (with which a telnet
client is sort of backwards compatible).

If your serial link is fast, you probably don't want to put each
character in it's own packet, instead wait a short amount of time and
then send as many characters as you have collected from the serial
line.  Going the other way, when a packet comes in your push all its
characters out the serial - optionally waiting to acknowledge the
packet until you have done so.

You also need to decide what to do on the serial link if your TCP
packets aren't being acknowledged.  Do you just let incoming serial ->
ethernet characters collect in a buffer?  What do you do when it
overflows?

One commercial vendor uses something in the style of the old modem "AT"
command set to control the ethernet link from the serial side.


Re: Serial (rs232 etc.) to IP
Frieder,
   Thanks again.  The reason I mention using singel character mode is
that if the system is to be "blind" (to the serial protocol) through
the TCP transport, then you have to transmit a single character at a
time, since some messages may be a single character, but I suppose a
good bet for better efficiency would be to send what data you have
after something like 2-3 character times elapse since the last recieved
character at the serial end.
   One last thought ... how does one choose an arbitrary TCP or UDP
port?  I'll take a look through the RFC's

Thanks Again,
-D


Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

Well, if you look up the definition of "arbitrary" that pretty
much explains it.

--
Grant Edwards                   grante             Yow!  Did I say I was a
                                  at               sardine? Or a bus???
We've slightly trimmed the long signature. Click to see the full one.
Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

The Telnet protocol has special interpretations
for the octets in the range of 240 to 255.

If your serial link is not going to transfer
data in the special octet range, a raw TCP
connection is equivalent to Telnet.

There is a common misuse to call a raw
TCP connection Telnet, as the commonly
printable character range can be handled
with a standard Telnet client.

--

The port ranges in use are listed (among
plenty of other numbers) in the RFC 1700.

We've slightly trimmed the long signature. Click to see the full one.
Re: Serial (rs232 etc.) to IP

[X]

Quoted text here. Click to load it

I remember my first "private TCP protocol". I chose a port number easy
to remember and within the above range; so I picked yymmd, which is the
day I was born. So you now know I am between 40 and 56 years old...

Re: Serial (rs232 etc.) to IP
The number of the port that you use is generally irrelevant other than both
ends of the connection need to know which port they are both using.

Specific protocols tend to use specific port numbers and these are referred
to as "Well Known Ports"

As you may have seen when using a web browser (HTTP Client), you can
actually connect to a web server (HTTP server) using any port that the
server is listening on. I think it goes something like
http://192.168.0.123:1234 , where 1234 is the port you are choosing to
connect to the HTTP server on. For this to work, the HTTP server must be
listening on 1234 instead of (or as well as) port 80.

Key reasons why you would use a well known port number are:
. So your request from the client arrives on a port that the server is
listening on
. So your traffic is able to break through firewall configurations
. So your traffic can be proxied
. So your traffic can be routed with quality of service applied

Other than that, you could have a server listening on port 80 (HTTP) for any
type of connection, including your stream of serial data.

For socket communication, you create a socket, 'bind' the socket to a port,
and then listen on the port.

When a client connects to the port that you are listening on, you can then
start reading from the port. You can read one character at a time if you
wish. In this way your server (that is receiving data) can receive as much
data as it can at a speed that it is able.

The easiest way to choose an 'arbitrary' port is to choose one outside of
the well known numbers or choose a well known port for an obscure protocol.

Even if you only send one character, the nature of Ethernet is that your
single character might not get to its destination. TCP will ensure that the
character is resent until it is either acknowledged or the connection times
out.

The telnet protocol does much more than just transferring characters. TCP
does that without requiring telnet.




Quoted text here. Click to load it



Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

..and by doing this also ruin the serial line throughput when a half
duplex protocol is used with short message frames. Some converters
wait 10-100 ms after the last serial character received, before the
(TCP or UDP) IP-frame is sent. For instance at 115200 bit/s, this
corresponds to 100-1000 character times.

Paul


Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

There's always going to be an throughput efficiency vs. latency
tradeoff when doing Async<->Ethernet.  You should pick a
product that allows you to control this tradeoff (or if it
doesn't, make sure the designer chose a tradeoff that matches
your requirements).

--
Grant Edwards                   grante             Yow!  Yow! I'm imagining
                                  at               a surfer van filled with
We've slightly trimmed the long signature. Click to see the full one.
Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

This is a valid concern, however there's a bit of a problem with single
character packets when many common embedded TCP devices try to talk to
common desktop operating systems.

TCP requires that you hang onto all outgoing data until it has been
acknowledged, because if it's not acknowledged you will have to resend
it.  Most embedded implementations handle this by sending a packet, and
then being unable to send another until the first has been
acknowledged.  The Windows TCP stack often takes as much as 200 ms to
acknowledge a packet when only one is outstanding, so single character
packets can be slowed down to the rate of only five per second!

There are a number of fixes.  You can hit windows with a bogus ack
right after you send it a packet and it will acknowledge yours.  That
gets you down into the 10 ms per packet regime, but then you are still
going to be collecting at least 10 ms worth of incoming serial
characters before each packet you send (no need for a delay, just when
you get the ack packetise and send everything that came in while you
were waiting on the ack).

A smarter method would be to keep better track of what has not been
acknowledged, so that you can have multiple outstanding packets and not
have to wait for the ack before you can send another.  But most of the
other wise turnkey implementations - OpenTCP for example - don't do
that.


Re: Serial (rs232 etc.) to IP
ok,
   Heres a link to an example configuration page from NetBurner for a
customizable
device using arbitrary TCP ports ... however they imply that PORT 23 is
used to sense a connection from the IP network side... so that implies
telnet delivers data to the serial unit, and comms from the serial unit
go to an "arbitrary" port ... in this case 1000.

 http://www.netburner.com/products/processors/sb70/SB70config.htm

  I was aware of the "ack" aspect, hence single char mode.

  If anybody has any other experience/wisdom ... pipe up.

TIA,
-D


Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

There's arbitrary (you pick one you like) and then there's arbitrary
(it gets dynamically assigned).

Because your device may not be literally running a telnet service, you
might want to pick a port other than telnet's port 23 to listen on.  In
some cases, client computers may even not be able to access some
traditional low port numbers.  For a custom function you might want to
pick something slightly over 1024.  If you want to use a telnet client
to open an interactive test session to your device, you specify the
port number in addition to the IP address to the program, and you do
something similar with the operating system call to open a TCP session
if you are building it into a program.

When you connect to the device, it then picks a port to reply to you
on... you don't have to worry much about that part unless you are
building the TCP stack from scratch.  Just worry about picking the
device's listen port/


Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

If you are using a protocol that was initially written for serial line
communication with normal CRC checks and timeout controls, why bother
with TCP, just use simple UDP. If the UDP frame is lost, let the
original serial line protocol timeout mechanism handle any missing
data.

Paul


Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

Yes, if you are using such a protocol.  But most common serial devices,
be they lab test equipment, printers, modems, or whatnot do not use
such a protocol all of the time, though users may be in the habit of
using one (XMODEM or something) when corruption is intolerable.

In packet switched networks it is permissable to drop packets just
because you "don't feel like passing them on right now".  In most
point-to-point serial, the practical assumption is of quite high
reliability, usually interrupted only by total failure.

When that's not true - with really noisy phone lines... 1200 baud
dialup in Moscow circa '92... error correcting packetized protocols
such as MNP made sense for interactive user sessions.  You just had to
get used to typing far ahead of the several retries necessary to get
the packetized half-duplex echo through.


Re: Serial (rs232 etc.) to IP
Quoted text here. Click to load it

This has at least one problem: these serial line protocols usually
assume that packets arrive in order. This makes sense for these
protocols (I cannot imagine a message jumping over the previous one and
reaching its destiny sooner than the other), but not for IP packets.

Re: Serial (rs232 etc.) to IP

Quoted text here. Click to load it

And unduplicated.  I see duplicate packets not infrequently on
my home wireless network, but I don't ever remember seeing
out-of-order packets (though I've never specifically looked for
them either).

Quoted text here. Click to load it

Any decent serial protocol would deal with out-of-order or
duplicated packets, but there are a lot of indecent protocols
in use.

--
Grant Edwards                   grante             Yow!  I'm rated PG-34!!
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: Serial (rs232 etc.) to IP
I'm not sure if I am missing something, but this seems like a stupid
conversation :)

TCP is a connection based protocol and as such it ensures that all data is
received in the correct order and without errors.

There is no need to 'use' another protocol like Telnet if all you wish to do
is transfer a serial stream of characters from one place to another over IP.
That is what TCP/IP does.

Open a socket on one end and listen.

Start sending characters to the remote socket.

TCP uses a sliding window mechanism, which is effectively a buffer of data
that has been sent that has not yet been acknowledged. The sender will
continue to send until this sliding window is full. As data is acknowledged
from the remote end, the window opens up some more and more data can be
sent.

The size of the window dictates how much data you can send before you must
receive an ACK from the other end.

Every time a SYN is sent, the other end must ACK, unless the remote end has
implemented delayed acknowledgement. You can normally decline delayed
acknowledgement when the socket is first negotiated.

Job done!

Hope this helps.


Quoted text here. Click to load it



Site Timeline