Hi Scott,
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 sophistication.
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.
I agree.
$0.01
Hey! That was at least $0.03! Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs