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" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
