TLS Support

[zaphoyd]

is required by the spec

see section 10.6

[ljackson]

Really like your websocketpp implementation, Using the client for a proof of concept for a project i am working on, need/require the TLS support so I am in the process of implementing, I belive I have got it in there but I think that I have a problem with having both m_socket and my new m_ssl_socket (asio ssl stream wrapper over tcp::socket) in the same io_service loop? What were your design thoughts on this extend the session again to be either ssl or non-ssl and move m_socket from the websocket_session to a derived class for either TLS or non TLS ?

Thanks for your work!

[zaphoyd]

I am currently in the process of a major refactoring now that the protocol spec has been frozen at Hybi 17. The current focus is on the following:

• Finalizing (hopefully) the client application facing APIs
• Moving protocol spec specific logic out of the asio/network logic so that I can more easily support both Hybi 00 and Hybi 17
• Thread safety
• write queueing / write flow control / Preventing overlapping writes
• HTTP pass through

It would probably be good to look at what the structural SSL needs are at this point as well. If you can push what you have so far to your github fork I will take a look at see if I can incorporate it into my newer build.

[ljackson]

Understand that, what I have doesn't work so I am going to try and move the session's socket member to a boost shared pointer for a socket_base that will either have a socket_plain or socket_ssl object in it, and will be decided at runtime when the set_uri is called in connect, this will then create the new socket object and setup the correct socket type with the io_service. What do you think about that aproach for the client ? I am stuck rushing something for a proof of concept, my client code works great with socket.io (i have a parser and other parts for socket.io on top of your transport) without ssl but just hangs with ssl due to I belive having both a regualar socket (not used in ssl mode) and a asio ssl stream socket on the io service at the same time?

Thanks,
Leif

[ljackson]

looks like you have implemented the socket/plain and socket/ssl, you still want how I did it or are you happy with your refactoring branch? I am running some load testing on the server with current master as having handshake invalid method issues with large number of new client connections, have you tested the new ssl/plain sockets with lots of connections?
Thanks,
Leif

[zaphoyd]

Can you be more specific about the sort of errors you are getting? How many connections before you are seeing errors? They are definitely only showing up when SSL is in use?

I have SSL working now in the policy refactor branch as a template policy unless something else goes horribly wrong that will probably be the method I go with. I have only tested it with small numbers of connections and local self signed certificates so far. What are you using to test large numbers of connections? Tobias (from the Autobahn WS library) has been experimenting with a 50000 connection test harness that I will try and test against soon.

[ljackson]

Will retest on the errors once your policy refactor branch settles down, just starts throwing handshake expection when you try to connect more than say 1000 at a time with master branch + my socket.io parser and packet code on top of it so it could likely be my own addititions :) Yeah sounds good was wanting to go with template, like I said needed to hack something together so I used base class and casting in my test code so if yours works thats cool! Looking to try to load test at 225k+ per instance with 4 to 8 instances running on a server.... fun fun.

[zaphoyd]

Are you at all interested in ASIO running in one thread/core pool mode rather than one single threaded process per core?

[ljackson]

Possibly whatever is going to help scale :)
On Nov 17, 2011 5:18 PM, "Peter Thorson" <
reply@reply.github.com>
wrote:

Are you at all interested in ASIO running in one thread/core pool mode
rather than one single threaded process per core?

---

Reply to this email directly or view it on GitHub:
#26 (comment)

[zaphoyd]

policy-refactor branch now has fully working TLS support for the server side. Client side should be done shortly.

[ljackson]

Very cool!
On Nov 29, 2011 7:44 PM, "Peter Thorson" <
reply@reply.github.com>
wrote:

policy-refactor branch now has fully working TLS support for the server
side. Client side should be done shortly.

---

Reply to this email directly or view it on GitHub:
#26 (comment)

[zaphoyd]

TLS support has been working for awhile. Only outstanding issue is to write an example TLS enabled client.