On 09/29/2013 12:44 PM, Tommi Mäkitalo wrote: > Am 28.09.2013 17:21, schrieb Michael Gius: >> 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. > Failure is always reported by exceptions in cxxtools. And it is a > exception, when the connection could not be established. So the decision > is easy. You are right, my bad. (An old COM programming deformation, hresult anybody?) > The implementation is also easy. I have to pass the boolean parameter to > the impl. In the impl class it is just 2 more lines: > > if (!realConnect) > _socket.connect(_addr, _port); > > Or actually another line to set the timeout before calling connect. > > _socket.connect already throws a exception if it do connect. > > I would expect when connect raised an exception, that the client is in > no good state. So it would be ok, to just accept the ip address and > port. The user have to call connect again to get the client into good > state. Or he may start the server and start using the client. > > Currently we have > Client::connect(const std::string& addr, unsigned short port). > > This would change into > Client::connect(const std::string& addr, unsigned short port, bool > realConnect = false). > > Although the signature of the method changes, it will be API compatible. > So no change in user code is needed. > Easier than I thought. Speaks for efficient design and exceptions put to good use. It makes sense to do it that way and it's useful, but I think it goes only half way to address the problem. Documentation is key here.
Please correct me if I am wrong, but the problem seems to be that the function name, a verb, implies an action that the function does not execute. On a higher level, for those that did some network programming, connect implies the 3-way TCP handshake. I think the best way to avoid the problem in the future, is to document this function thoroughly, as it's workings are, to some degree, open to interpretation. In that regard this problem raises other questions for me, as I am just about to start digging into cxxtools. For instance a quick grep into the source shows me that there is support for keepalive. But without digging into the source I cannot know how this is handled in cxxtools::http::client. Will there be keep alive after the initial request - or with the planned modified function after connect, if realConnect was true - until the instance of Client is destructed ? Not seeing any hint in the API would suggest that no keep alive is done. Another example: There is no close() function and the socket is not exposed in the interface, so I assume that the Client class is thought to be instantiated on the go, when needed, and not to be kept around for reuse. But is this assumption correct ? A short comment on the class level could easily shed light on the philosophy behind the code. If you agree, I will suggest comments for functions/classes (via github pull request) as I progress and stumble upon questions I cannot solve without digging deeper into the library. Proposed skeleton of a comment for connect() : /** * connect() sets the host address and port for the socket used. * By default no connection is opened. This is done upon the first request. * Setting realConnect to true will actually connect. On failure to connect an x exception will be thrown, but the host address and port will be kept. * keepalive behaviour: (may be better to comment on class level) * exceptions raised: ... */ >> Having a separate connection timeout would be a great feature. > I just implemented that. You can find the code in git. Great! Thank you. I sincerely hope the above does not sound like a rant. It is meant purely as an advocacy for commenting the source. Tntnet and cxxtools have great features and potential, which is why anybody will invest time into it. The examples give a really good headstart. With some added documentation on the API it could be even easier to get going. How did I end up here ? Talking too much, sorry. Cheers, Michael ------------------------------------------------------------------------------ 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
