Re: Sockets library requirements

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-24 20:52:39

--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "Timothy M. Shead" <tshead_at_k...> wrote:
> > On Sun, 2002-02-24 at 16:03, davlet_panech wrote:
> 
> Perhaps; although framing is not an issue for stream-based 
protocols. 
> Blocking doesn't seem like a big issue for a stream also -- after 
all 
> file streams are blocking, even though the underlying OS frequently 
> supports non-blocking file operations. I think I agree that error 
> handling might be problematic, though.
> 
There is a reasonable difference between blocking sockets and 
blocking files though, in that files access is usually at worst over 
a slow LAN, whereas socket access is frequently over an unreliable 
WAN with potential 10-20 second blocking times.  OS's can also do a 
lot of caching for files that can't be done with sockets.
If you can get away with one thread per socket, then blocking is fine 
of course, but in my own experience you need somewhat more 
sophisticated mechansism whereby a block allows some background 
processing to go on (which might include accepting more connections 
or processing data on other existing connections).
Error handling almost has to be done with exceptions - and note that 
basically all socket errors except EWOULDBLOCK mean the socket is no 
longer usuable anyway.
Still given all this, streaming over a socket is quite workable.  I 
put a socketbuf in files sometime ago and also a binary_stream (the 
two are actually orthogonal, but people seem to assume socket I/O is 
usually binary whereas file I/O is usually ascii).

Dylan