|
Boost : |
From: Ani Taggu (ataggu_at_[hidden])
Date: 2002-11-24 03:40:08
Not sure if this point is within the scope of current socket design:
Should the functionality be a very thin wrapper over the OS calls only?
E.g, in win32, blocking sockets especially within a GUI application behaves
erratically. A common way is to use to use non-blocking sockets and use
timed operations.
On UNIX however, blocking sockets are the norm.
So, in my homegrown socket library (similar to some extent with the current
design), the sockets which are accepted and connected are by default
non-blocking.
Of course then, send/recv become slightly more complex -- in that it has to
implement more logic to handle timed operations.
My $0.02,
-Ani
"Hugo Duncan" <hugoduncan_at_[hidden]> wrote in message
news:1103_1038068542_at_news.gmane.org...
> Sockets have come up from time to time on this list, without
> concrete results. I am no expert, but based on previous
> discussions, I have tried to start describing a design at:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
> (I don't often write formal designs, so please excuse (or correct)
> misuse of terminology etc.)
>
> I propose working with a group of interested people to develop
> this design and put together some code.
>
> As my socket programming experience is limited to tcp/ip streams,
> I would also like to ask people to provide small test cases.
> In particular, examples of datagram usage, multicast,
> broadcast, and non-ip usage.
>
> Please feel free to edit the wiki pages with comments, etc.
>
> Hugo
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk