On Mon, 2013-05-06 at 20:26 -0400, Lance D. wrote: > Thanks all for that advice. You all are exploring the same paths that I've > explored in some manner. I've got requirements that force my code to have > traceable paths, which makes multi-threading within the application > difficult. Right now, the option I like the best is probably the heartbeat > option solution.
Note that the heartbeat solution is the way that you are supposed to do this, although it may not be adequately documented. > > On a side note, what are the chances that we could update the API to expose > the underlying socket and/or provide the ability to tweak the socket > options. The API already exposes the Nagle option, so I don't see that it > would be that blasphemous to add in other, similar options. There is a low chance you could persuade me it would be a good idea to do this! I might be persuaded that doing the opposite makes some sense though (in other words importing an existing socket and using that). The reason for this is that the underlying code uses an abstraction over sockets and that is purely internal - there may not always be a socket to expose and trying to do so would just make things hard for not a huge gain in my opinion. However importing an existing socket would work within the existing code structure to some extent. BTW exposing the tcp-nodelay setting was intended to allow the user to trade off latency against throughput, rather than to expose a socket option specifically. I originally suggested a naming along those lines, but tcp-nodelay stuck. In the tests we've run, we found that tcp-nodelay is the better setting in nearly every circumstance. So we've now made that the default setting for the C++ code on trunk. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
