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?