Sockets input and output

[C.E. Piggott]

I'm not sure if this is what you want or not ... but if by "the sockets
buffering" you mean that the read() on the socket blocks if there is no
data ready to be processed, then there are ways around that: one would
be to do the fcntl() to make the socket NON-BLOCKING; then, the read
would fail with errno==EWOULDBLK (or something like that - look it up).
This, however, would produce a spinlock as you check for data - not
too effecient.

A better approach would be to use select() to look at a bunch of
file descriptors - in your example, say, three remote sockets which
may have data ready to be read, and the keyboard.  BEWARE that most
machines I've tried have seem to have had one problem or another with
select() - for starters, documentation claims that select() returns
an EXCEPTION condition on a socket if that socket has terminated
(fine print indicates that the only exception that is supported under
Ultrix-32, SUN-OS, and Unix 4.3 is out-of-band data).

The third approach is to make the whole thing interrupt driven with
a handler for a SIGIO, generated when data is ready...however, for the
# of sockets you want to have open at once, you'd have the same problem
all over again trying to figure out which one it is.

Other than that, sockets shouldn't "buffer" past the normal time it
holds on to data before it can get squeezed out the other end...as soon
as the sockets are osculate, if you write one byte to it, one byte should
immediately (relative term) pop out.

Chris N2JGW
--
-- 
Christopher E. Piggott, N2JGW                   cep4478 at ultb.isc.rit.edu
President                                       n2jgw at n2jgw.ampr [44.69.2.1]
Rochester Institute of Technology               N2JGW @ WB2WXQ
Amateur Radio Club K2GXT                        CEP4478 at RITVAXA.BITNET