please wait
- Forum
- General C++ Programming
- difference betw synchronous and asynchro
difference betw synchronous and asynchronous sockets
Feb 29, 2012 at 5:54am
Hi,
Can someone please explain to me the difference between synchronous and asynchronous sockets w.r.t. my following understanding:
I understand that on windows one can implement an asynchronous socket with CAsyncSocket. This class has overidable methods for OnReceiving data, or OnSending, ... Basically these overidables act as callbacks, ie they get invoked when the associated io operation is pending process.
I believe Linux offers async functionality via Kqueue or some other library.
Would one also be able to achieve this by implementing in a seperate thread a select function call on a listening socket for incoming calls and on all connected sockets for read requests pending. Then upon the select function call returning we pass the read request or incoming call to a thread pool for processing.
The sending operations seem trivially fine as these don't block, so can ideally be called from anywhere and any time (as long as socket is connected).
If the above were implemeted, would this essentially be using sockets asynchronously?
Thanks for any help in advance.
Can someone please explain to me the difference between synchronous and asynchronous sockets w.r.t. my following understanding:
I understand that on windows one can implement an asynchronous socket with CAsyncSocket. This class has overidable methods for OnReceiving data, or OnSending, ... Basically these overidables act as callbacks, ie they get invoked when the associated io operation is pending process.
I believe Linux offers async functionality via Kqueue or some other library.
Would one also be able to achieve this by implementing in a seperate thread a select function call on a listening socket for incoming calls and on all connected sockets for read requests pending. Then upon the select function call returning we pass the read request or incoming call to a thread pool for processing.
The sending operations seem trivially fine as these don't block, so can ideally be called from anywhere and any time (as long as socket is connected).
If the above were implemeted, would this essentially be using sockets asynchronously?
Thanks for any help in advance.
Feb 29, 2012 at 11:13am
Yes.
Synchronous sockets block. Ansynchronous sockets don't block.
The rest is detail of how you might implement async sockets. select() is the BSD Sockets way and as BSD Sockets is the reference implementation, it's portable.
The most efficient methods are Completion Ports for Windows, kqueue for BSD and epoll for Linux. These are native non-portable methods.
Synchronous sockets block. Ansynchronous sockets don't block.
The rest is detail of how you might implement async sockets. select() is the BSD Sockets way and as BSD Sockets is the reference implementation, it's portable.
The most efficient methods are Completion Ports for Windows, kqueue for BSD and epoll for Linux. These are native non-portable methods.
Feb 29, 2012 at 11:46am
Thank you for the replies and the link - I can learn alot from site.
So the select statement does provide us with a mechanism for implementing asynchronous sockets.
I note your comment that synchronous sockets in particular block while asynchronous socket don't.
Does this have to be a hard rule - if I implement a select on a bunch of blocking sockets, would I not get the same effect as with non blocking sockets?
My understanding would suggest that a return from the select statement would imply that a read is pending or a connection request is pending. Thus a call to recv or accept should not block after this point. Am I understanding this correctly.
So the select statement does provide us with a mechanism for implementing asynchronous sockets.
I note your comment that synchronous sockets in particular block while asynchronous socket don't.
Does this have to be a hard rule - if I implement a select on a bunch of blocking sockets, would I not get the same effect as with non blocking sockets?
My understanding would suggest that a return from the select statement would imply that a read is pending or a connection request is pending. Thus a call to recv or accept should not block after this point. Am I understanding this correctly.
Feb 29, 2012 at 11:54am| if I implement a select on a bunch of blocking sockets |
Feb 29, 2012 at 12:26pm
I have used select on blocking sockets with no problems encountered.
As mentioned - the select operates in its own thread.
The select only processes read states or incomming connections. To set this up does not require the sockets to be non blocking. The FD_SET structure can be successfully loaded and passed to the select statement on these blocking sockets.
Once these blocking sockets receive some data or a new connection comes in on the listening socket the select will return and the pending operation can be completed successfully on the blocking socket.
I can post an example of such code - I just need get a stripped down version - do I have to go that far?
As mentioned - the select operates in its own thread.
The select only processes read states or incomming connections. To set this up does not require the sockets to be non blocking. The FD_SET structure can be successfully loaded and passed to the select statement on these blocking sockets.
Once these blocking sockets receive some data or a new connection comes in on the listening socket the select will return and the pending operation can be completed successfully on the blocking socket.
I can post an example of such code - I just need get a stripped down version - do I have to go that far?
Topic archived. No new replies allowed.