Connection.hpp termination handler

[mald]

Hi Peter,

I notice in connection.hpp, there is a termination handler (typedef lib::function<void(ptr)> termination_handler;). Could you please provide an explanation when it's called?

Is it called when every connection is closed? And also called when attempting to establish new connections? I see in the connection_impl.hpp terminate is called (this->terminate(ec);).

Thank you

[Peter Thorson]

Short answer: An internal library system not accessible by users of the library. Library users should use the close/fail handlers instead.

Details:

A connection has an internal state machine that is started via connection::start_accept (server connections) or connection::connect (client connections). Once either of these methods is called the state machine will proceed until the connection ends naturally or in an error. The termination state is the final state before the connection is considered closed and ready to be deallocated. The terminate handler is called during the termination phase. It’s purpose is to provide a way for an endpoint to be called back by a connection before it gets deallocated for any last minute cleanup. It is only used internally and cannot be triggered or set by programs that use the library. The reason it exists is that endpoints and connections are loosely coupled enough that connections do not retain a pointer to the endpoint that created them and endpoints do not retain pointers to their own outstanding connections.

Presently no endpoint implementations require the use of a termination handler so no termination handler is ever set or called. This has not and may not always be the case. Certain types of optimizations (for example a message buffer pool shared with all connections of one endpoint) require more communication between endpoints and connections. The termination handler is present to allow that sort of communication without requiring tight coupling for use cases that don’t need it.

--
You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mald]

Thank you Peter for the detailed response. I have a follow up question.

I have made a retry-client-endpoint (header only).

I structured this endpoint similar to your /roles/client_endpoint.hpp. I handle the retry attempts by checking if an error occurred in the callback (type::handle_connect) method. Now the problem I'm encountering is here:

with example4.hpp

1. If I run the command
   example4 ws://echo.websocket.org
   it works fine. No retry needs to be made because it establishes a connection on the first attempt
   
   
2. If I run the command
   example4 ws://some.non.existant.address
   it also works. It attempts 3 retries (as configured with con->m_max_attempts = 3), and then exits
   
   
3. If I run the command
   example4 ws://asdf.websocket.org
   It doesn't work. It does one attempt then exits. This is because in the handle_connect, the if(ec) is false. So it doesn't attempt to reconnect. looking at the log from websocketpp it has this:
   
   [connect] Successful connection
   [error] Server handshake response error: websocketpp.processor:20 (Invalid HTTP status.)
   [disconnect] Failed: Invalid HTTP status.

So I started looking at adding a handler to terminate, because it appears that terminate is called for all three examples, and I need some alternative to detect that the 3rd case above also needs to retry a connection attempt. Would it be safe for this helper class I made to use terminate handler, or have I gone about this the wrong way?

Thanks again for your input/help.