standard io and sockets

standard io and sockets

Post by slid » Fri, 28 Oct 1994 13:18:28



I've been reading Stevens' Unix_Network_programming trying to learn about
sockets.  The only thing I've done so far is a simple gopher client which
opened a socket then used fdopen() to buffer io on the socket.  Then, I'm
reading the Steven's book and he says ( p. 281 ) that we have to worry
about the possible interactions of the stdio library and we should be
cognizant of the buffering that's taking place.  However, he doesn't
go into what these presumably negative effects are.  Anyone know what
problems can occur when buffering a socket?  I could use some enlighten-
ment.  Thanks.
 
 
 

standard io and sockets

Post by James Vlc » Sun, 06 Nov 1994 02:36:55



> I've been reading Stevens' Unix_Network_programming trying to learn
> about sockets.  The only thing I've done so far is a simple gopher
> client which opened a socket then used fdopen() to buffer io on the
> socket.  Then, I'm reading the Steven's book and he says ( p. 281 )
> that we have to worry about the possible interactions of the stdio
> library and we should be cognizant of the buffering that's taking
> place.  However, he doesn't go into what these presumably negative
> effects are.

A file pointer opened via fdopen atop a socket will be fully buffered.
This means that writes will be buffered until a certain amount of data
(perhaps 4096 bytes) is available to be sent over the line.  This is
independent of how many "lines" may be contained in the buffer.
Everything is then sent in one burst.

If your intent is that interactive communications take place over the
socket, full buffering will vex you no end as data will not
necessarily be sent whenever an "end-of-line" condition is met.  Thus,
both peers will be blocked waiting for the other to send a message,
while the initial message is left languishing in the output buffer of
the first peer to talk.

See the setvbuf(3) man page for information on the buffering of file
pointers.

Jim Vlcek


 
 
 

1. LCSDNYR 2001 -> standards, standards, standards

[snip - a call for standardisation]

I completely agree, but I don't think Linux is going the wrong way (yet).

As always, tarballs (./configure, make, su -c 'make install') stay (oh yes
they will). Package-like installing (cfr deb, rpm, jbl, ...) goes the
right way: easy, user-friendly and without any hassle. I don't think it's
necessary to evolve to one package. Each type of packaging has it
advantages and disadvantages. It's a choice, a mindgame if you will. Some
people like the deb-packages since they are extremely easy to install.
Some others want rpm, since the availability of those files is enormous.
Some people stay with the tarballs.

I don't think Linux is going the wrong way.

With packages without any hassle. With tarballs you should look at the
Makefile before 'make install'-ing and search for 'make uninstall'. If
that's available (and correctly programmed), there isn't any other hassle.

This could be one point of discussion (tarballs - uninstalling software),
but I don't know enough about tarballs (I only use them if I can't find
any rpm-files for it) so I'd better shut up :-/

Again, with packages no troubles. Tarballs are also without any hassle,
since upgrading is very simpel. Configuration-files stay (thus not the way
M$ handled things, i.e. registry), binaries get upgraded, libraries are
... how do they say it... renewed? I mean, a newer version of library
doesn't overwrite things (f.i. libsmpg-2.0-3.so.2), only has a greater
version-number (f.i. libsmpg-2.1-1.so.2). And ldconfig makes sure programs
use the right library...

/etc/*.conf, $HOME/.*rc, ... I think Linux (and most unix-like OS'ses) are
doing a great job on that. They are easy to back-up, easy to modify
(manually AND with scripts/tools), ...

--
 SwifT

2. fsck

3. read/write standard io

4. Help reading config file

5. problem in standard header file <sys/io.h> ?

6. Still can't install. HELP!

7. joystick input => standard io driver/program (does one exist)

8. ws.ftpd and umask

9. Fix for Ne2000 Ethernet card with non-standard IRQ/IO address.

10. Getting Linux to see a non-standard IO IDE controller

11. Matrox Mystique ands X.

12. non-blocking io and sockets...

13. IO::Socket::SSL