Customising the connection class

[edwardbr]

Hi I love your library. I would however like to be able to override your websocketpp::role::server::connection class to support additional fields in an effort to cache session id's etc.

Unfortunately if I use something like this my compiler complains of templatitis:

template class new_server : public websocketpp::role::server { public: // Connection specific details template class connection : public websocketpp::role::server::connection

Do you have any suggestions? I would prefer to not have to hack your solution each time you pring out a great new version.

Another question is if I have my own boost::http implementation based on say the http::server3 example is there a way that you can pass callbacks between each easily? The reason being I have a long poll implementation already, and I would like to use your solution as a separate plugin.

Edward

[zaphoyd]

Regarding passing callbacks between io_services, I would look at version 0.3.x in the experimental branch. This version includes the ability for WebSocket++ to use an asio io_service object managed by your application rather than one managed internally. With this you could create an io_service for your long polling server and then ask WebSocket++ to register its callbacks with that same io_service. Do note though, that WebSocket++ does not officially support using asio in thread pool mode the way the http::server3 example does. The preferred concurrency method for 0.3.x is to use a separate, independent, io_service per core, as in example http::server2.

Regarding connection specific values, I would recommend storing these values in a hash table with the connection_ptr (or connection_hdl for 0.3.x) as the key and look them up as needed in handlers. Subclassing connections and roles in 0.2.x is pretty hairy and I would not recommend it. 0.3.x is a lot cleaner and could pretty easily support adding custom fields and methods to connections if there was demand for that.

[edwardbr]

Many thanks for the reply I will look at http2 again. I have been using a single io_service as a cheap task scheduler for other units of work such as handling timeouts when a session has expired. I have avoided this way of working due to my concern that that having a multiple io_service solution would be harder to distribute tasks in a fair manner, unless I added some form of mpmc queue.

The reason why I would like to add something to the connection class is so that I do not have to do a lookup in a hash table as that requires some form of locking for every event lookup, perhaps you could put in an optional template parameter e.g. a tuple to add user defined types?

I'll check out the experimental branch, what I really like to be able to do, is to be able to inspect the initial packet of a connection to work out which http extension to use e.g. long poll, websockets, CGI etc.

Regards

Edward

[zaphoyd]

Multiple io_services may result in potentially unfair scheduling, this is true. Unfortunately, unlike HTTP servers and timers, WebSocket connections share significant state across requests that needs to be carefully synchronized. This makes implementing something like http::server3 for WebSocket significantly more complicated. I've drawn up some guidelines for multi-threaded usage of WebSocket++ here: http://www.zaphoyd.com/websocketpp/manual/reference/thread-safety. I do intend to offer an ASIO transport method similar to the http::server3 example at some point, but that will be a much more complicated feature for a future version.

Adding a user defined template policy to WebSocket++ 0.3.x to allow adding data types and methods for this purpose should be trivial, so I'll plan on doing that. I'll reference this issue when that is done.

WebSocket++ can be used to multiplex websocket requests and standard HTTP requests. Look at the http handler callback. Depending on how you use the WebSocket connections, WebSocket++ 0.3.x could also be used with the iostream transport where it doesn't use ASIO at all and just accepts bytes as a stream and calls handlers as appropriate. This would allow websocket connections to be processed behind another system that handles the network and pipes the bytes. Alternatively, you can use something like nginx to proxy connections to separate backends or run long poll and websocket on different ports/IPs.

[edwardbr]

Many thanks for the reply I look forward to your planned enhancements. I am interested also in being able to connect WebSocket++ via a frames or an iostream connection do you have any examples that do this? Regards

Edward

On 02/03/2013 19:00, Peter Thorson wrote:

Multiple io_services may result in potentially unfair scheduling, this is true. Unfortunately, unlike HTTP servers and timers, WebSocket connections share significant state across requests that needs to be carefully synchronized. This makes implementing something like http::server3 for WebSocket significantly more complicated. I've drawn up some guidelines for multi-threaded usage of WebSocket++ here: http://www.zaphoyd.com/websocketpp/manual/reference/thread-safety. I do intend to offer an ASIO transport method similar to the http::server3 example at some point, but that will be a much more complicated feature for a future version.

Adding a user defined template policy to WebSocket++ 0.3.x to allow adding data types and methods for this purpose should be trivial, so I'll plan on doing that. I'll reference this issue when that is done.

WebSocket++ can be used to multiplex websocket requests and standard HTTP requests. Look at the http handler callback. Depending on how you use the WebSocket connections, WebSocket++ 0.3.x could also be used with the iostream transport where it doesn't use ASIO at all and just accepts bytes as a stream and calls handlers as appropriate. This would allow websocket connections to be processed behind another system that handles the network and pipes the bytes. Alternatively, you can use something like nginx to proxy connections to separate backends or run long poll and websocket on different ports/IPs.

— Reply to this email directly or view it on GitHub https://github.com/zaphoyd/websocketpp/issues/185#issuecomment-14333331.

[zaphoyd]

The latest build of 0.3.x introduces the ability to add custom base classes to endpoints and connections. This allows storing data and methods inside the connection or endpoint objects themselves. Some examples and documentation for this have been added to the manual at http://www.zaphoyd.com/websocketpp/manual/common-patterns/storing-connection-specificsession-information

[edwardbr]

Read your link really cool, I will have fun with this!

Regards

Edward

On 10/03/2013 18:48, Peter Thorson wrote:

The latest build of 0.3.x introduces the ability to add custom base classes to endpoints and connections. This allows storing data and methods inside the connection object itself. Some examples and documentation for this have been added to the manual as well. http://www.zaphoyd.com/websocketpp/manual/common-patterns/storing-connection-specificsession-information

— Reply to this email directly or view it on GitHub https://github.com/zaphoyd/websocketpp/issues/185#issuecomment-14686639.

[zaphoyd]

Going to close this as most of the issues have been addressed by the latest builds of 0.3.x. I will open a separate issue for multithreaded io_service support issue which is not yet addressed.

[edwardbr]

Cool thanks On 01/04/2013 03:47, Peter Thorson wrote:

Going to close this as most of the issues have been addressed by the latest builds of 0.3.x. I will open a separate issue for multithreaded io_service support issue which is not yet addressed.

— Reply to this email directly or view it on GitHub https://github.com/zaphoyd/websocketpp/issues/185#issuecomment-15702420.