in the old version of tornadio, we used to use the _protocol (private, i know) attribute on a SocketConnection object to check whether a connection was websockets or flashsocket or xhr-polling or whatever.
We can't find a similar way of doing it in the new API. Any suggestions?
Due to way socket.io 0.7+ works, on_open is called during handshake phase and there's no transport yet. After handshake was completed, socket.io will try to probe transports and establish data connection. So, there's no way to tell which transport is used in on_open handler. Unfortunately, I can not move on_open to the later stage, because tornadio2 might refuse client connection and it should be done before socket.io client will attempt to establish data connection.
If it is desired functionality, I can add "last used transport" to the session, so you can access it via self.session.last_transport, but it won't be available in on_open anyway. Another possibility, I can add a callback to the connection class, which will be triggered when active data connection was established (data protocol connected), so you will have chance to react to the protocol changes. Obviously, for polling transports, this callback will be fired more than once for the session.
Right now you can check if there's active client connection by checking self.session.handler != None. If it is not None, you can get its name: self.session.handler.name.
self.session.handler != None
we're trying to get to it during an on_message, so it's not a problem that it's not available in on_open.
self.session.handler.name seems to work OK for websockets, not so much for other protocols?
We're getting self.session.handler = None pretty much whenever we try to query it in a polling connection inside on_message... self.session.last_transport sounds like it would be a good solution - unless you can think of anything else, using the current API?
self.session.handler = None
I work with hjwp and we've decided that the only thing we're interested in is distinguishing between socket connections and polling connections. The current API provides that perfectly well. Thanks for your help.