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].
>
> lkcl
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
port/address
- 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
one received)
- no guaranteed delivery; a message sent may never be received (UDP
checksums
messages; garbled messages are discarded)
NT named pipes supply (as I understand it):
- stream and datagram-based operations (read/write/send/recv equivalents)
- connection-oriented
- 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
messages).
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.
Unlike
PF_INET, however, they also support passing file descriptors (which are
really
just Unix's abstraction of capabilities (in the sense of capability-based
security) plus a little state information -- maybe 1/2 of credentials
passing).
I _should_ note that there are such beasts as SOCK_RDM and SOCK_SEQPACKET
in Unix (SOCK_DGRAM + reliable delivery, and SOCK_STREAM + message
boundaries,
respectively), but I don't know offhand what protocol families they are
normally
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
mailing list