Best method for making synchronous call from async handler
Good evening, Currently I have an application running on boost asio working very well. To simplify the heck out of it, it takes requests via tcp and passes back binary information stored on disk. However, I now need to add an extra step to processing. If the data is not available on the local disk, the server needs to contact one or more peer servers it knows about, send a query to each one via UDP asking if it has the data, and then use an existing TCP connection to that server to retrieve the asset. This step must be completed before any more processing can be done for the current client even though the client may be sending even more requests while we process. My question is, what is the best method for me to achieve the goal? Should I set up another io_service for the UDP query step along with retrieving the data from the other server? Is there a good wait to wait on that io_service to complete? Also in the case that one of the servers has gone away, can I use a deadline timer to cancel the UDP recvfrom if I don't get a response in time from one or more servers? I should also probably keep this second io_service alive throughout the lifetime of the application? Thank you in advance for advice on tackling this problem the right way with asio. -- David Daeschler
[Disclaimer: I don't know asio and can't answer your question, sorry. But I want to better understand what you're asking.] David Daeschler wrote:
If the data is not available on the local disk, the server needs to contact one or more peer servers it knows about, send a query to each one via UDP asking if it has the data, and then use an existing TCP connection to that server to retrieve the asset.
Silly question: if you already have a TCP connection to each other server of interest, why not send the query over that connection? One of the key characteristics of UDP is that a packet might be silently lost. If you find yourself adding packet sequence numbers and retry logic, you're starting down the path of a bad partial imitation of TCP. (Been there, done that...)
This step must be completed before any more processing can be done for the current client even though the client may be sending even more requests while we process.
Your subject line implies that you're thinking of doing this with synchronous calls, but your questions about io_service objects imply that you mean *logically* synchronous calls (you don't reply to the original request until some number of complete round trips to these other servers) using asynchronous asio operations. Am I correct that you intend asynchronous operations?
Hello Nat, Silly question: if you already have a TCP connection to each other server of
interest, why not send the query over that connection?
UDP will be used only for the queries and this will be running on a LAN. The majority of the answers from other servers will be negative, so I'm trying to keep the level of traffic down. There is already heartbeat information transmitted this way and it works pretty well. A small amount of packet loss in this scenario is acceptable, it is more important these queries be fast. If you find yourself adding packet sequence numbers and retry logic, you're
starting down the path of a bad partial imitation of TCP. (Been there, done that...)
Yes sir, definitely not going down that road. you mean *logically* synchronous calls (you don't reply to the original
request until some number of complete round trips to these other servers) using asynchronous asio operations. Am I correct that you intend asynchronous operations?
Yes. Meaning no matter how I implement this the initiating call from the client can not return until this part has been completed. Thank you for your time. On Mon, Aug 23, 2010 at 12:02 PM, Nat Goodspeed <nat@lindenlab.com> wrote:
[Disclaimer: I don't know asio and can't answer your question, sorry. But I want to better understand what you're asking.]
David Daeschler wrote:
If the data is not available on the local disk, the server needs to
contact one or more peer servers it knows about, send a query to each one via UDP asking if it has the data, and then use an existing TCP connection to that server to retrieve the asset.
Silly question: if you already have a TCP connection to each other server of interest, why not send the query over that connection?
One of the key characteristics of UDP is that a packet might be silently lost. If you find yourself adding packet sequence numbers and retry logic, you're starting down the path of a bad partial imitation of TCP. (Been there, done that...)
This step must be completed before any more processing can be done for the
current client even though the client may be sending even more requests while we process.
Your subject line implies that you're thinking of doing this with synchronous calls, but your questions about io_service objects imply that you mean *logically* synchronous calls (you don't reply to the original request until some number of complete round trips to these other servers) using asynchronous asio operations. Am I correct that you intend asynchronous operations?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
David Daeschler -
Nat Goodspeed