0

When reading from a socket using read(2) and blocking I/O, when do I know that the other side (the client) has no more data to send? (by "no more data to send" I mean that, as an example, the client is waiting for a response). At first, I thought that this point is reached when less than count bytes are returned by read (as in read(fd, *buf, count)).

But what if the client sends the data fragmented? Reading until read returns 0 would be a solution, but as far as I know 0 is only returned when the client closes the connection - otherwise, read would just block until the connection is closed. I thought of using non-blocking I/O and a timeout for select(2), but this does not seem to be a tidy solution to me.

Are there any known best practices?

watain
  • 4,838
  • 4
  • 34
  • 35
  • This is a bit broad as there are numerous approaches to network *protocols*. Send the first four bytes as an `int` representing message length. Look for line terminators. Etc, etc, etc. – Brian Roach Feb 25 '14 at 09:46

3 Answers3

1

TCP is a byte-stream protocol, not a message protocol. If you want messages you really have to implement them yourself, e.g. with a length-word prefix, lines, XML, etc. You can guess with the FIONREAD option of ioctl(), but guessing is all it is, as you can't know whether the client has paused in the middle of transmission of the message, or whether the network has done so for some reason.

user207421
  • 305,947
  • 44
  • 307
  • 483
1

The protocol needs to give you a way to know when the client is finishes sending a message.

Common approaches are to send the length of each message before it, or to send a special terminator after each message (similar to the NUL character at the end of strings in C).

user253751
  • 57,427
  • 7
  • 48
  • 90
1

The concept of "the other side has no more data to send", without either a timeout or some semantics in the transmitted data, is quite pointless. Normally, code on the client/server will be able to process data faster than the network can transmit it. So if there's no data in the receive buffer when you're trying to read() it, this just means the network has not yet transmitted everything, but you have no way to tell if the next packet will arrive within a millisecond, a second, or a day. You'd probably consider the first case as "there is more data to send", the third as "no more data to send", and the second depends on your application.

If the other side doesn't close the connection, you probably don't know when it's ready to send the next data packet either.

So unless you have specific semantics and knowledge about what the client sends, using select() and non-blocking I/O is the best you can do.

In specific cases, there might be other ways - for example, if you know the client will send and XML tag, some data, and a closing tag, every n seconds. In that case you could start reading n seconds after the last packet you received, then just read on until you receive the closing tag. But as i said, this isn't a general approach since it requires semantics on the channel.

Guntram Blohm
  • 9,667
  • 2
  • 24
  • 31
  • 1
    What has 'using select() and non-blocking I/O' got to do with application-level protocols? Spurious info. – Martin James Feb 25 '14 at 11:21
  • If you have an application-level protocol that tells you when to read data and how much data to read, you might get away without select and non-blocking I/O, if there is a good reason to avoid it. – Guntram Blohm Feb 25 '14 at 11:27
  • 1
    If you have an application-level protocol that tells you when a message is complete, one way or another, you don't need non-blocking I/O. I can't actually think of an application protocol that doesn't do this and that does rely on non-blocking I/O and select(). Lines; length word prefixes; XML; type-length-value; ... – user207421 Feb 25 '14 at 11:30