From: Don G (dongryphon_at_[hidden])
Date: 2005-03-16 00:07:02
> Networking is inherently asynchronous. Initiation and acceptance
> of connections and I/O may be disguised as synchronous but other
> activity (e.g. "network down") cannot. Network APIs will often
> defer such errors until the next reporting opportunity (e.g. next
> I/O request) but this is a band-aid that is sometimes enough and
> at other times downright misleading. I assume that something
> going by the name of Boost.Net would be targeting a higher
Amen. It took me some time to get used to the work around that one
should always try to have a pending read in order to detect problems.
In some cases that works, but it depends on the protocol whether or
not you can read at the right time.
> Proposing that all network communication is asynchronous does
> not preclude any synchronous coding. As discussed in other
> threads (i.e. RPC) a "low-level", asynchronous library may be
> the "core" of a Boost.net while synchronous services may be
> built on top.
While this will work, in my experience there are efficiencies to be
had if the synchronous methods aren't forced to create/store
callbacks that simply signal condition variables. Of course, the
gains will depend on the cost of the async mechanism in question.
> I think an asynchronous, core Boost.Net should expose fundamental
> network services. In the case of TCP, that would be the reliable,
> async 2-way transfer of data blocks. Achieving a clean and
> portable library at this level would be achievement enough.
What, no UDP? :)
> Dragging I/O streams into the "network discussion" at this
> point is almost premature; it moves the focus up the network
> stack. Again this doesn't preclude those who need to from
> integrating with I/O streams at a later point.
Hey! That was at least $0.03!
Do you Yahoo!?
Make Yahoo! your home page
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk