Honestly, I'm not going to make a case one way or the other. As a general rule, I like my middleware to divorce me, the user, from the underlining implementation. That said, I also want more control over how long the middleware takes to do what I asked for.
As an alternative to exposing OS-provided timeouts or some other timer functionality, would adding a non-blocking/passive open() call be reasonable and plausible for the C++ client? Thanks again? -Lance On Wed, May 8, 2013 at 2:17 PM, Andrew Stitcher <[email protected]>wrote: > 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] > >
