[asio-users] async_receive hangs

[Яков Каабак]

My problem is similar to that described here: http://sourceforge.net/p/asio/mailman/message/23297553/.
I am using boost.asio 1.57.
There are two programs, say, client and server. Client sends messages to the server, the server sends the replies. All is done via asynchronous calls.
After the client sends the third message to the server, the server fails to receive it, that is its receive handler is never called.

Also I have a timer which is used to detect broken connections. The timer fires every min.
With that timer, the async_receive works – but only after the timer expires. I disabled the timer to diagnose the situation and found that the async_receive hangs.

I tried to look into the boost.asio internals with debugger to see what is going on, but didn’t succeed.

What else can I do?

[Gruenke,Matt]

Season’s Greetings!

Do you ever make a call to async_receive(), before the previous one on that socket completed?

The typical approach is to maintain an outstanding async_receive() at all times, by having its completion handler issue the next one. This completion handler should queue up the responses, and initiate a state machine to drain the queue, whenever the queue transitions from empty to nonempty.

The state machine to send the response initiates an async_write(). The completion handler for that should issue another async_write(), if the queue is nonempty.

You can synchronize access to the queue either with a mutex, or by using one strand per connection, to which both send & receive handlers (and any other function interacting with that connection) should be dispatched.

I hope that helps.


Matt


From: ЯкПв Каабак [mailto:***@gmail.com]
Sent: December 24, 2014 17:39
To: asio-***@lists.sourceforge.net
Subject: [asio-users] async_receive hangs

My problem is similar to that described here: http://sourceforge.net/p/asio/mailman/message/23297553/<http://cp.mcafee.com/d/FZsSd20Q86Qm4jhOMVssqenPtPqtT3hOYMMY-UrjKehhpphoodFTsd7bP33PXNJeUV4seoshKrl8Nr-1nMlcJqIEjVsTcJqIEjVsTF2X10QsIfZvC4hOryvnKnjpp7sUqeknAhTbnhIyCGyyDOEuvkzaT0QSyrhdTV5MQsFIT7e6zBcTsS03FlKdLt00_MdNrdFaK2qKMNnWkQz-9IFCzAs--PxLqiGnrFYq5O5mUm-wafBiteFlKdLt00_MddzxPdPpFrSAGBSWv6xFtd46QbgIaN-TOc-q82uM8QdIFCQOGAfO7qo-31>.
I am using boost.asio 1.57.
There are two programs, say, client and server. Client sends messages to the server, the server sends the replies. All is done via asynchronous calls.
After the client sends the third message to the server, the server fails to receive it, that is its receive handler is never called.

Also I have a timer which is used to detect broken connections. The timer fires every min.
With that timer, the async_receive works – but only after the timer expires. I disabled the timer to diagnose the situation and found that the async_receive hangs.

I tried to look into the boost.asio internals with debugger to see what is going on, but didn’t succeed.

What else can I do?


________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

[Яков Каабак]

A little fix:
4. server receives this message;
5. server receives the message from #2 (without delays).
is incorrect. Actually, the order is preserved.

but the delay is still present with no obvious reason.

From: ЯкПв Каабак
Sent: Thursday, December 25, 2014 12:30 PM
To: asio-***@lists.sourceforge.net
Subject: Fw: [asio-users] async_receive hangs

Thank you for response.
First I would like to add something to description of my situation:
1. All that takes place in Windows 7;
2. I use SSL via boost::asio::ssl::stream (maybe that matters). Therefore, all the async_receive are called by SSL engine, not by my code. What I use is async_read function. To read the message I use two calls to async_read: first read the 4 byte “header” that contains the length of the message, second (in the completion handler) I read the message body.

I was a bit incorrect about timer. There are two timers: on server side and on client side. Server-side timer is currently disabled. One min timer is client timer. Its work is simple: I use async_wait on this timer; hanlder sends a dummy message to the server and sets the timer again. (To be exact, the order is opposite: first set the timer, then send the message.)

And now the order of events is as follows:
1. server issues the async_read to the boost::asio::ssl::stream; the handler tracker shows that the async_receive is active;
2. client sends the (actual) message; server doesn’t receive it – still waits in async_receive;
3. 1 min timer fires; client sends the dummy message;
4. server receives this message;
5. server receives the message from #2 (without delays).

[Яков Каабак]

A little fix:
4. server receives this message;
5. server receives the message from #2 (without delays).
is incorrect. Actually, the order is preserved.

but the delay is still present with no obvious reason.

From: ЯкПв Каабак
Sent: Thursday, December 25, 2014 12:30 PM
To: asio-***@lists.sourceforge.net
Subject: Fw: [asio-users] async_receive hangs

Thank you for response.
First I would like to add something to description of my situation:
1. All that takes place in Windows 7;
2. I use SSL via boost::asio::ssl::stream (maybe that matters). Therefore, all the async_receive are called by SSL engine, not by my code. What I use is async_read function. To read the message I use two calls to async_read: first read the 4 byte “header” that contains the length of the message, second (in the completion handler) I read the message body.

I was a bit incorrect about timer. There are two timers: on server side and on client side. Server-side timer is currently disabled. One min timer is client timer. Its work is simple: I use async_wait on this timer; hanlder sends a dummy message to the server and sets the timer again. (To be exact, the order is opposite: first set the timer, then send the message.)

And now the order of events is as follows:
1. server issues the async_read to the boost::asio::ssl::stream; the handler tracker shows that the async_receive is active;
2. client sends the (actual) message; server doesn’t receive it – still waits in async_receive;
3. 1 min timer fires; client sends the dummy message;
4. server receives this message;
5. server receives the message from #2 (without delays).

[Яков Каабак]

From: ЯкПв Каабак
Sent: Thursday, December 25, 2014 4:05 PM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] async_receive hangs

A little fix:
4. server receives this message;
5. server receives the message from #2 (without delays).
is incorrect. Actually, the order is preserved.

but the delay is still present with no obvious reason.

From: ЯкПв Каабак
Sent: Thursday, December 25, 2014 12:30 PM
To: asio-***@lists.sourceforge.net
Subject: Fw: [asio-users] async_receive hangs

Thank you for response.
First I would like to add something to description of my situation:
1. All that takes place in Windows 7;
2. I use SSL via boost::asio::ssl::stream (maybe that matters). Therefore, all the async_receive are called by SSL engine, not by my code. What I use is async_read function. To read the message I use two calls to async_read: first read the 4 byte “header” that contains the length of the message, second (in the completion handler) I read the message body.

I was a bit incorrect about timer. There are two timers: on server side and on client side. Server-side timer is currently disabled. One min timer is client timer. Its work is simple: I use async_wait on this timer; hanlder sends a dummy message to the server and sets the timer again. (To be exact, the order is opposite: first set the timer, then send the message.)

And now the order of events is as follows:
1. server issues the async_read to the boost::asio::ssl::stream; the handler tracker shows that the async_receive is active;
2. client sends the (actual) message; server doesn’t receive it – still waits in async_receive;
3. 1 min timer fires; client sends the dummy message;
4. server receives this message;
5. server receives the message from #2 (without delays).