Re: [boost] Sockets vs. net connection

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-01-09 18:13:59

Beman Dawes wrote:
> That was what I was talking about.  Python socket constructors take family,
> type, and (optional) protocol arguments.   Family can be AF_INET or
> AF_UNIX. Type can be SOCK_STREAM (for TCP), SOCK_DGRAM (for UDP), SOCK_RAW,
> or SOCK_SEQPACKET.  So "although it is based on Unix, this module is
> available on all platforms," to quote Python Essential Reference by David M
> Beazley.

I'd vote not to mix everything into one boost socket class.
Yes, Unix has the "everything is a file" mentality --- and then
found out it needed sendto/sendmsg calls in addition to write
to handle the special cases in communications.

SOCK_STREAM and SOCK_DGRAM types have sufficiently different
semantics that differently named methods seem appropriate.

In particular, SOCK_DGRAM (UDP) seems inappropriate for an iostream
buffer backend, because there's no way to talk about
"end of datagram; send this now".  However, SOCK_STREAM (TCP)
seems perfectly well suited for such an iostream buffer backend,
because it really looks like a non-seekable file, with reliable
delivery and everything.  In short, a UDP socket needs special
care by the application anyway, thus the interface can (and should)
be different.

While we're at it, I would very much like to handle both IPv4 and
IPv6 in some generic "address" object.  Thus, "uint32_t hostnumber"
is not a good idea at all. (IPv6 has 128 bit host addresses.)

All in all, it seems we're looking at the implementation far too
much.  We need more use-cases first.

Jens Maurer