Loco
07-24-2002, 11:21 PM
Taken from the original FAQ.
1.5 - How do Sockets Work?
The implementation is left up to the vendor of your particular unix, but from the point of view of the programmer, connection-oriented sockets work a lot like files, or pipes. The most noticeable difference, once you have your file descriptor is that read() or write() calls may actually read or write fewer bytes than requested. If this happens, then you will have to make a second call for the rest of the data. There are examples of this in the source code that accompanies the faq.
From: Stanislav Shalunov
Actually, no standard I am aware of prohibits short read()'s and write()'s for pipes or even regular files.
From: Pinocchio
So if sockets can do more than pipes, why does anyone use named pipes?
From: S.Murali Krishna
What is the difference between FIFOS and Unix domain
sockets. Both of them are doing the same job (interprocess
Communication) then what is the difference (or advantage)
between them ? Can anyone tell me in detail.
Thanks - S.M.K
From: Rob Seace
Well, the main difference between a named pipe (FIFO) and
a Unix domain socket is that pipes are uni-directional
(half-duplex) while sockets are bi-directional (full-
duplex)... So, to communicate in both directions via a
named pipe, you'd need TWO of them, one for each direction;
or, you'd need to arrange some very careful read/write
synchronization on both ends, to keep from stepping on each
other's toes by simultaneously trying to write, or
deadlocking from simultaneously trying to read... But, an
AF_UNIX socket has pretty much all of the normal TCP/UDP
semantics and behaviors you would expect from an AF_INET
socket; just with no network lag... ;-) And, with a few
added features (like being able to pass file descriptors and
credentials to peers)...
However, one advantage named pipes have is that they work
transparently as if they were real files... Ie: if you have
an app that only knows how to read from or write to a file,
it's trivial to make it use a named pipe instead... But, in
order to make it use a Unix domain socket (or any other kind
of socket, for that matter), you would need to rewrite it to
do all of the proper socket API calls, rather than simply
doing fopen() or whatever it was already doing...
From: Muppalla Phaneendra
Added on: 2002-07-15 04:42:29
Any body cane tell me how socket works (in terms of internal file structures)? ANd how data passed thru sockets from application layer to networ layer.
From: Rob Seace
Added on: 2002-07-15 07:21:28
It would vary from OS to OS... Read your local kernel
source code... Or, get a copy of Stevens' "TCP/IP
Illustrated, Volume 2"...
1.5 - How do Sockets Work?
The implementation is left up to the vendor of your particular unix, but from the point of view of the programmer, connection-oriented sockets work a lot like files, or pipes. The most noticeable difference, once you have your file descriptor is that read() or write() calls may actually read or write fewer bytes than requested. If this happens, then you will have to make a second call for the rest of the data. There are examples of this in the source code that accompanies the faq.
From: Stanislav Shalunov
Actually, no standard I am aware of prohibits short read()'s and write()'s for pipes or even regular files.
From: Pinocchio
So if sockets can do more than pipes, why does anyone use named pipes?
From: S.Murali Krishna
What is the difference between FIFOS and Unix domain
sockets. Both of them are doing the same job (interprocess
Communication) then what is the difference (or advantage)
between them ? Can anyone tell me in detail.
Thanks - S.M.K
From: Rob Seace
Well, the main difference between a named pipe (FIFO) and
a Unix domain socket is that pipes are uni-directional
(half-duplex) while sockets are bi-directional (full-
duplex)... So, to communicate in both directions via a
named pipe, you'd need TWO of them, one for each direction;
or, you'd need to arrange some very careful read/write
synchronization on both ends, to keep from stepping on each
other's toes by simultaneously trying to write, or
deadlocking from simultaneously trying to read... But, an
AF_UNIX socket has pretty much all of the normal TCP/UDP
semantics and behaviors you would expect from an AF_INET
socket; just with no network lag... ;-) And, with a few
added features (like being able to pass file descriptors and
credentials to peers)...
However, one advantage named pipes have is that they work
transparently as if they were real files... Ie: if you have
an app that only knows how to read from or write to a file,
it's trivial to make it use a named pipe instead... But, in
order to make it use a Unix domain socket (or any other kind
of socket, for that matter), you would need to rewrite it to
do all of the proper socket API calls, rather than simply
doing fopen() or whatever it was already doing...
From: Muppalla Phaneendra
Added on: 2002-07-15 04:42:29
Any body cane tell me how socket works (in terms of internal file structures)? ANd how data passed thru sockets from application layer to networ layer.
From: Rob Seace
Added on: 2002-07-15 07:21:28
It would vary from OS to OS... Read your local kernel
source code... Or, get a copy of Stevens' "TCP/IP
Illustrated, Volume 2"...