Topic
  • 6 replies
  • Latest Post - ‏2012-09-16T05:09:56Z by Prithiviraj
Prithiviraj
Prithiviraj
60 Posts

Pinned topic Sockets : Non blocking Vs Asynchronous

‏2012-09-05T08:40:12Z |
Can some body explain the behavioral differences of Non blocking Vs Asynchronous and real life application scenarios.?

working samples would help ;-)
Updated on 2012-09-16T05:09:56Z at 2012-09-16T05:09:56Z by Prithiviraj
  • scott_klement
    scott_klement
    244 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-12T20:24:44Z  
    Let me use a recv() call as an example:

    In blocking mode, when you call recv(), it sits and waits for data to arrive.

    In non-blocking mode, when you call recv(), if there's no data to receive at that instant, it tells you so by returning an error code that means "it would've blocked" (i.e. it would've waited)

    In async mode, you start the receive, and then data gets received in the background. Then your program can do other things, and later come back and see if the receive completed. (and if so, use the data.)

    Personally, I've never had much reason for async -- I typically need the data when I call the API, so starting it and then checking for it later doesn't make a lot of sense to me. But, it's certainly possible that I'm just not thinking about it the right way.
  • Prithiviraj
    Prithiviraj
    60 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-13T13:31:33Z  
    Let me use a recv() call as an example:

    In blocking mode, when you call recv(), it sits and waits for data to arrive.

    In non-blocking mode, when you call recv(), if there's no data to receive at that instant, it tells you so by returning an error code that means "it would've blocked" (i.e. it would've waited)

    In async mode, you start the receive, and then data gets received in the background. Then your program can do other things, and later come back and see if the receive completed. (and if so, use the data.)

    Personally, I've never had much reason for async -- I typically need the data when I call the API, so starting it and then checking for it later doesn't make a lot of sense to me. But, it's certainly possible that I'm just not thinking about it the right way.
    @Scott: isnt the concept of Overlapped I/O has been put to best use for building scalable apps/servers both in windows world and unix world for long time now.

    Windows uses a notify on completion model (hence IOCP/I/O Completion Ports). You start some operation asynchronously, and receive a notification when that operation has completed. Calls to perform I/O are returned immediately, while the actual operations are completed asynchronously by separate worker threads.

    Linux applications (and most other Unix-alikes) generally use a notify on ready model. You receive a notification that the socket can be read from or written to without blocking. Then, you do the I/O operation, which will not block.

    I wanted to use the QSO* APIs to leverage IOCP concepts in iSeries world and am fairly successful with it except for few roadblocks i faced.

    As I have learned from you the basic idea of using the right solution/tool for the right situation. so i wanted to hear from you and other experts about this. I was also wondering while the world needs Async I/O how iSeries world managed to live without it, IMHO It could be possible people didnt not resort to this solution because RPGLE started supporting "complete" multi-threading in V6R1. But with C and multithreading QSO* APIs were available for long.

    Please share your thoughts.
  • scott_klement
    scott_klement
    244 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-14T08:07:48Z  
    @Scott: isnt the concept of Overlapped I/O has been put to best use for building scalable apps/servers both in windows world and unix world for long time now.

    Windows uses a notify on completion model (hence IOCP/I/O Completion Ports). You start some operation asynchronously, and receive a notification when that operation has completed. Calls to perform I/O are returned immediately, while the actual operations are completed asynchronously by separate worker threads.

    Linux applications (and most other Unix-alikes) generally use a notify on ready model. You receive a notification that the socket can be read from or written to without blocking. Then, you do the I/O operation, which will not block.

    I wanted to use the QSO* APIs to leverage IOCP concepts in iSeries world and am fairly successful with it except for few roadblocks i faced.

    As I have learned from you the basic idea of using the right solution/tool for the right situation. so i wanted to hear from you and other experts about this. I was also wondering while the world needs Async I/O how iSeries world managed to live without it, IMHO It could be possible people didnt not resort to this solution because RPGLE started supporting "complete" multi-threading in V6R1. But with C and multithreading QSO* APIs were available for long.

    Please share your thoughts.
    I have used async sockets on Windows, but perhaps a bit different than you describe? I simply added the socket data as an additional event in my wndproc by calling WSAAsyncSelect(). Since the main loop of my windows program sits on GetMessage()/DispatchMessage() this allowed my existing event handling code to simply be woken up when data arrived. Never used "completion ports" in that model. Windows is a bit different from other environments, in that you have to handle windows events, and they can come at any time. If you don't, the user will think your application has frozen up.

    In Linux/Unix/BSD, I haven't found any need for async sockets. Calling select() in the main loop works nicely, since all I/O is done through descriptors anyway. FWIW, this is the environment that I've done the most socket coding -- I've written oodles of socket code on Unix, mostly in C. Never even heard of async I/O and "completion ports". The only way I know to do async sockets in Unix is via signals.

    As for IBM i... I just haven't run into the need for them. I'm curious as to what you do while you're waiting for the data to arrive? Are you monitoring for other events to occur (maybe on a data queue) while you wait? Or... why do you want to do them async? Are you handling many simultaenous connections in a single job?
  • Prithiviraj
    Prithiviraj
    60 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-14T09:05:34Z  
    I have used async sockets on Windows, but perhaps a bit different than you describe? I simply added the socket data as an additional event in my wndproc by calling WSAAsyncSelect(). Since the main loop of my windows program sits on GetMessage()/DispatchMessage() this allowed my existing event handling code to simply be woken up when data arrived. Never used "completion ports" in that model. Windows is a bit different from other environments, in that you have to handle windows events, and they can come at any time. If you don't, the user will think your application has frozen up.

    In Linux/Unix/BSD, I haven't found any need for async sockets. Calling select() in the main loop works nicely, since all I/O is done through descriptors anyway. FWIW, this is the environment that I've done the most socket coding -- I've written oodles of socket code on Unix, mostly in C. Never even heard of async I/O and "completion ports". The only way I know to do async sockets in Unix is via signals.

    As for IBM i... I just haven't run into the need for them. I'm curious as to what you do while you're waiting for the data to arrive? Are you monitoring for other events to occur (maybe on a data queue) while you wait? Or... why do you want to do them async? Are you handling many simultaenous connections in a single job?
    1. WSAAsyncSelect is a win32 concept ??
    2. IOCP is very much a windows stuff - "Jeffrey ritcher - Advance Windows programming 2nd or 3rd edition" talks about it if am not wrong.
    As for as what I am doing - One possible scenario i would be dealing is: Slot machines and kiosks interacting with Host systems. There could be roughly 10K clients trying to have millions of "near" concurrent transactions with the host when players play or do some activity
    I need a host system

    1. Which is highly scalable and adoptable for different loads - if required scale upward or scale downward. So this can be resource efficient
    2. Scalability must be automatic, by sensing load and spawning more threads(not jobs) or making the threads sleep when not required
    3. I am looking at a response time in the order of milli seconds.

    What do you suggest?
  • scott_klement
    scott_klement
    244 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-14T13:21:12Z  
    1. WSAAsyncSelect is a win32 concept ??
    2. IOCP is very much a windows stuff - "Jeffrey ritcher - Advance Windows programming 2nd or 3rd edition" talks about it if am not wrong.
    As for as what I am doing - One possible scenario i would be dealing is: Slot machines and kiosks interacting with Host systems. There could be roughly 10K clients trying to have millions of "near" concurrent transactions with the host when players play or do some activity
    I need a host system

    1. Which is highly scalable and adoptable for different loads - if required scale upward or scale downward. So this can be resource efficient
    2. Scalability must be automatic, by sensing load and spawning more threads(not jobs) or making the threads sleep when not required
    3. I am looking at a response time in the order of milli seconds.

    What do you suggest?
    This sounds like a fun challenge. I have never had to support that many simultaneous connections, before. (Or even anything close to that level of volume.)

    I'm just trying to learn from you.
  • Prithiviraj
    Prithiviraj
    60 Posts

    Re: Sockets : Non blocking Vs Asynchronous

    ‏2012-09-16T05:09:56Z  
    This sounds like a fun challenge. I have never had to support that many simultaneous connections, before. (Or even anything close to that level of volume.)

    I'm just trying to learn from you.
    Sure it is and I will complete a minimum viable program and share my design and get your inputs and feedbacks thanks