Hi Tommi, Adding a parameter to the function would raise the question whether to return a value indicating the success or failure of the connection or to raise an exception. Would the address than be kept on success and discarded on failure ? The function may become unnecessarily complicated.
On the other hand, having an optional parameter like 'testConnection = 0' would draw the attention of the developer to the problem of the misnomer of the function in the http context. It would be difficult to achieve this by creating a second function with the same body but named something like setConnectionAddress or setConnectionParams, as the other function would still need to be around in order to not break the API. My vote goes to keep it as it is. May be one could add a convenience function to test the connection ( may be named: canConnect() - I also thought of testConnection, but then we would have to check the doc for the meaning of the boolean return value) Having a separate connection timeout would be a great feature. Michael P.S.: +1 for your video on youtube. On 09/26/2013 09:42 PM, Tommi Mäkitalo wrote: > Hi, > > these days we found a problem in our application which was related to > the special behavior of cxxtools::http::Client. Or actually it was > cxxtools::xml::HttpClient but it is the same problem. > > Http is a connectionless protocol. That means, that a the actual > network connection has no state in the context of the http protocol. > Each request is self contained. For a http server it makes no > difference whether 2 requests arrive though the same connection or > over separate connections. Hence the http client in cxxtools builds > the network connection when needed and tries to keep the connection > open as long as possible. It is also prepared, that a existing > connection may be closed by the server and it will reconnect > automatically when needed. > > This is standard http behavior. > > That actually means, that the method cxxtools::http::Client::connect > do not actually connect to the server but just stores the address. The > network connection is build up on the first request. > > In our application the developer did not know about that. He first > wanted to know, if the server is available by calling the connect > method and catching possible exceptions. But it never throws. Hence > the check was useless. > > It is obviously irritating, that connect do not connect to the server. > > So there are several options, what can be done: > > * Keep it as it is - connect do not throw but executing the request > might give a connection refused error. This is not that bad it can > always happen. Even when the client has already a connection but it > do not work any more, it tries to reconnect and might give a > connection refused error > * Add a method "trueConnect()" or something (if you vote for this, > please suggest a good name also). This would really build a > connection to the server. > * Add a optional bool parameter "realConnect" with default to false to > force the caller to do that connect. > > Another problem which we encountered in that context is the connect > timeout. It is possible to set the timeout of the client. But the > timeout is used for connecting and for executing the request. If the > request may take longer, the user is forced to give a quite long > timeout, which is also valid for the connect then. But if the host, we > try to connect is not available at all, this may take long since there > is no host, which will answer the SYN package. > > The idea to solve that is to add separate connect timeout. Then the > user can set a relatively short connect timeout and a longer execute > timeout. > > Any opinions? > > Tommi > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > > _______________________________________________ > Tntnet-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tntnet-general ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
