Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to figure out the current transport type / protocol? #16

Open
hjwp opened this issue Jan 9, 2012 · 5 comments
Open

how to figure out the current transport type / protocol? #16

hjwp opened this issue Jan 9, 2012 · 5 comments

Comments

@hjwp
Copy link

hjwp commented Jan 9, 2012

Hey,

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?

@mrjoes
Copy link
Owner

mrjoes commented Jan 9, 2012

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.

@hjwp
Copy link
Author

hjwp commented Jan 9, 2012

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?

@mrjoes
Copy link
Owner

mrjoes commented Jan 9, 2012

If there's no active running connection (you queried in between polling
phases), there won't be running connection. But this is highly unlikely, as
socket.io reconnects as soon as possible. Anyway, this will work as a
temporary solution and I will add data connection callback soon.

On Mon, Jan 9, 2012 at 7:04 PM, Harry Percival <
[email protected]

wrote:

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?


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

@hjwp
Copy link
Author

hjwp commented Jan 10, 2012

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?

@pythonanywhere
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants