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
