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
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)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk