Re: [boost] sockets /network programming Requirements

From: Josh M Osborne (stripes_at_[hidden])
Date: 2001-07-30 19:55:03

On Mon, Jul 30, 2001 at 06:24:22PM -0400, George A. Heintzelman wrote:

[...throwing exceptions on short reads inside operator>> rather then
blocking...]

> Now, it is likely that doing this kind of thing frequently, as a 
> polling loop for example, will cause performance problems. So other 
> means need to be provided for checking the presence of 'enough data' in 
> tight inner loops. But in cases where, most of the time but not always, 
> you expect the input to be there, this could be a nice simplification 
> of the programmer's problem dealing with incomplete reads.

Performance problems seems like a bit of an understatement, but
I'm guessing here based off how I think gcc handles exceptions
rather then any benchmarks...

> Comments on this idea? Is there something that I've missed that 
> prevents/argues against such an approach? If there is interest, I am 
> going to try to design the skeleton of such an iostream/streambuf pair 
> and see if it can be made to work.

Users of your method need to make sure they do nothing that
an exception won't undo until they are done reading from the
socket.  For example this could be bad:

  sock >> count;
  cout << "Reading " << count << " more thingies." << endl;
  for(int i = 0; i < count; i++) {
        sock >> thingie;
        thingie.run();
  }

What parts would you wrap with the handler for an incomplete socket
I/O?  Clearly if it is the whole thing you will at the very least
see "Reading SOME-NUMBER more thingies." more times then you should,
and who knows what damage "thingie.run()" has done.

If it is each individual item, then the loop that reads N thingies
has to store N somewhere so when it called it can read the right
number of thingies.

--------------------------------------------------

In the past I have always attempted to make sure there is "enough
data" to do the job.  Sometimes by reading into a buffer, and then
having another layer of "event" on top of that when I see a newline.
Other times by having length bytes in the data and making sure
there is enough for a "complete message" before parsing it, and
still other times by dealing with the data as a true byte stream
(for example feeding it byte for byte down a pipe to another process
like mpg123).

(sometimes "enough data" is very similar to "too much", a single
line with 16M worth of data: URL really makes a noticeable delay in
processing other streams)

As long as I can continue to things that way I don't mind if there
is another method that may be dog slow that lets one try to do
streams style I/O.  I'll even play with it, and may come to use it
when I don't care so much about speed.

In fact I have to note that unless there will be a way to get the
raw file descriptors and tell this library that it should may have
more data on fd#X that there are a lot of places you won't be able
to use it.  For example if you want to write something using any
of the X window toolkits, they are going to insist that they control
the main loop.  They will give you "file events" for at least read
and write, and in many cases "exception" (which I assume is whatever
would cause select to set an exceptfd bit).