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.