On 10/01/2010 02:50 AM, Roger Oberholtzer wrote:
On Thu, 2010-09-30 at 11:41 -0400, Jerry Feldman wrote:
First of all, TCP is not stream oriented. It is a protocol that requires a connection with a remote host. The IP protocol is a windowing protocol (in contrast to an old ack/nak protocol). Data sent via IP is transparent as the '\n' has no meaning.
TCP is very much a stream. In fact, I would call that it's defining characteristic. As opposed to UDP, which is packet based (a write on one side corresponds directly to a read on the other).
There is really no concept of a line in Linux WRT communications. Essentially a line is just some data with a '\n'. I suggest you consult a good book on Unix/Linux network programming, such as /UNIX Network Programming/, by the late W. Richard Stephens. This was at one time the best set of books. I think that this can answer all your questions. In the past I wrote a satellite communications system using either TCP or UDP based on lines. The issue is not so much the IP, TCP or UDP protocols, but how the end-user application handles the data.
Indeed. Lines are imposed by the receiver for whatever nefarious purposes they have. But, some device drivers let you define a termination character so that a read() call is limited to the data between these delimiters, and only satisfied when a delimiter arrives. The serial port driver is such a driver.
Unix SVR4.2 has a concept of stream drivers. These were modules that you could stack to process data (e.g. TCP) in a pipeline. So, you could push a 'line locating' stream module on your TCP stream and it would ensure that reads were satisfied according to whatever logic was in the module. These modules were loaded in a program and pushed on the TCP socket file descriptor. It is a powerful concept.
I was just curious if there was anything similar in Linux.
And I do have the Stevens books. They are indeed excellent. We used them when implementing a network stack in an small embedded device that we make. What I am curious about would be something outside the scope of these books.
Currently it is in the end-user app, as you stated. But I am trying to unify the implementation for RS-232 line-orientated communications (which is what I want), with the TCP code that looks for lines in the stream. I thought that before refactoring the code, I would check my options.
The entire IP suite is packet driven, TCP, UDP, ICMP. The difference
between UDP and TCP is that TCP sets up a connection between the two
ends with a guarantee that the entire message (1 or more packets) will
be delivered. UDP on the other hand is a datagram where packets are sent
to the destination without any checking. A lot of network management
protocols, such as SNMP, use UDP and provide end-to-end delivery. That
way if a remote host goes down, the application can manage the time outs
rather than the packet protocol. What TCP does is to send several
packets out up to a window size (usually 7). Each packet is numbered. If
the sender detects an error by not receiving the appropriate responses,
it may resend packets that fail to arrive. Packets can arrive at the
destination out of order, and it is the receiver's responsibility to
assemble the packets in the correct order before presenting the data to
the application.
--
Jerry Feldman