relationship between DCE/RPC and NT Named Pipes.
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Thu Jan 10 09:50:02 GMT 2002
> -----Original Message-----
> From: Luke Kenneth Casson Leighton [mailto:lkcl at samba-tng.org]
> Sent: Wednesday, January 09, 2002 21:15
> To: tng-technical at lists.dcerpc.org; David Allan Finch;
> rsharpe at ns.aus.com; samba-technical at samba.org;
> freedce-dev at lists.dcerpc.net
> Subject: Re: relationship between DCE/RPC and NT Named Pipes.
> On Thu, Jan 10, 2002 at 12:49:27AM +0000, Luke Kenneth Casson
> Leighton wrote:
> > unix supports TCP (guaranteed and ordered data delivery)
> > and it supports UDP (guaranteed message sizes) but it doesn't
> > support both.
> [if anyone has a more technically accurate explanation,
> i'd appreciate it if you could clarify this limited
> and ambiguous assessement: you know what i mean, but
> i can't find the words].
SOCK_STREAM (e.g. TCP in PF_INET) sockets provide the following semantics:
- supports read() and write() operations
- connection-oriented; a socket is connected to a specific remote endpoint
- no message boundaries; message receipt happens at byte granularity
- that is, recv() and friends will return all availible data up to
the supplied buffer size regardless of how many write()s/send()s
were required to send it; any remaining data remains waiting for
the next recv()
- next recv() is not guaranteed to start on a write()/send() boundary
- first sent, first received (ordered data delivery)
- guaranteed delivery; all data sent is guaranteed to (eventually) be
received as long as the connection is still alive
SOCK_DGRAM (e.g. UDP in PF_INET) sockets provide the following semantics:
- only supports send() and recv(), not read() and write()
- datagram-oriented; a socket collects all packets sent to its bound
- message boundaries; granularity of receipt is entire messages
- that is, recv() and friends will return as much of a message (as
sent by a single send()) as will fit in the supplied buffer --
the rest will be discarded
- next recv() is guaranteed to start on a message boundary
- no ordered delivery; data within a message sent by a single send() will
be in order, but the ordering of messages across send()s is not assured
(for example, the message sent with the third send() might be the first
- no guaranteed delivery; a message sent may never be received (UDP
messages; garbled messages are discarded)
NT named pipes supply (as I understand it):
- stream and datagram-based operations (read/write/send/recv equivalents)
- message granularity
- guaranteed order
- guaranteed delivery
- credentials passing
To supply the characteristics of NT named pipes for message passing, you
need to layer a message-boundary aware protocol over SOCK_STREAM, and back
up the socket with your own buffer to collect message fragments.
If you're feeling really masochistic, you can use SOCK_DGRAM (UDP) and
layer a protocol to handle sequencing and guaranteed delivery of messages
over it (backing up the socket with a buffer/list so you can reorder
out-of-order messages and wait for resends of missing intermediate
It also requires you to do something about connection-oriented situations.
UDP specifically also lacks TCP's congestion control, so as far as being
a good Internet citizen, TCP is probably preferable.
Hrm. I forgot credentials passing above. Oh well.
Fwiw, if I remember correctly PF_UNIX sockets only support SOCK_STREAM.
PF_INET, however, they also support passing file descriptors (which are
just Unix's abstraction of capabilities (in the sense of capability-based
security) plus a little state information -- maybe 1/2 of credentials
I _should_ note that there are such beasts as SOCK_RDM and SOCK_SEQPACKET
in Unix (SOCK_DGRAM + reliable delivery, and SOCK_STREAM + message
respectively), but I don't know offhand what protocol families they are
offered for. Not PF_INET, unless there are some standard IP-based protocols
I don't know about.
(is this what you meant, luke?)
More information about the samba-technical