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

Implement aiohttp.web websockets #220

Merged
merged 21 commits into from
Jan 3, 2015
Merged

Implement aiohttp.web websockets #220

merged 21 commits into from
Jan 3, 2015

Conversation

asvetlov
Copy link
Member

@asvetlov asvetlov commented Jan 2, 2015

Hi.
I've made websockets support in aiohttp.web.

The code still has no full test coverage but basic tests are passed.

Please review.

@asvetlov
Copy link
Member Author

asvetlov commented Jan 2, 2015

The code is fully covered!

try:
msg = yield from self._reader.read()
except Exception as exc:
raise WebSocketClosed(code=None, message=str(exc)) from exc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think we should catch this exception, or we should make distinction

  • protocol violation, like binary format errs
  • client disconnection exception, i think this exception should be re-raised.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't exception.__cause__ enouth?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't matter, up to you. i think it should act similar to ClientDisconnectedError exception from normal http handler.

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 2, 2015

i like implementation! we just need better closing procedure.

@asvetlov
Copy link
Member Author

asvetlov commented Jan 2, 2015

Please take a look: I've chosen GeneratorExit as base class for WebSocketClosed exception.

You can override it by catching error directly but if you don't do this RequestHandler will close HTTP connection.

Do you agree with GeneratorExit design?

@asvetlov
Copy link
Member Author

asvetlov commented Jan 2, 2015

i think this is unsafe. it is high likely GeneratorExit raises on GC (i.e. process exit)

Sorry, I don't follow

@asvetlov
Copy link
Member Author

asvetlov commented Jan 2, 2015

Yet another issue: what if web handler will create tasks those will wait for .receive()?
I can forbid the case by pinning Task.current_task() on WebSocketResponse.start()

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 2, 2015

whenever i get GeneratorExit, it happens during process termination. during normal work we should never get GeneratorExit, in most cases it is indicator of something totally wrong.
i just think that explicit GeneratorExit catch is wrong.

On Jan 2, 2015, at 10:09 AM, Andrew Svetlov notifications@github.com wrote:

i think this is unsafe. it is high likely GeneratorExit raises on GC (i.e. process exit)
Sorry, I dont' follow


Reply to this email directly or view it on GitHub #220 (comment).

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 2, 2015

i think we need WebSocketDisconnected exception and it should be DisconnectedError.

On Jan 2, 2015, at 10:02 AM, Andrew Svetlov notifications@github.com wrote:

Please take a look: I've chosen GeneratorExit as base class for WebSocketClosed exception.

You can override it by catching error directly but if you don't do this RequestHandler will close HTTP connection.

Do you agree with GeneratorExit design?


Reply to this email directly or view it on GitHub #220 (comment).

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 2, 2015

i don’t think it is good idea. from my experience with websockets, it is usually require 2 tasks one for reading and one for writing.

On Jan 2, 2015, at 10:30 AM, Andrew Svetlov notifications@github.com wrote:

Yet another issue: what if web handler will create tasks those will wait for .receive()?
I can forbid the case by pinning Task.current_task() on WebSocketResponse.start()


Reply to this email directly or view it on GitHub #220 (comment).

@asvetlov
Copy link
Member Author

asvetlov commented Jan 3, 2015

@fafhrd91 please review again.
I hope I've fixed discussed problems.

@asvetlov
Copy link
Member Author

asvetlov commented Jan 3, 2015

Server should have the single task for reading websocket messages.
Also it may tasks for writing ones.
If server calls .close() from reading task it should wait for handshake by .receive().
If it calls .close() from writing ones may call .wait_closed() for waiting for closing -- the handshake will be done in .receive() by reading task.
send_* and ping are forbidden after .close(), any received messages after the call are ignored.


# log access
self.log_access(message, None, resp_msg, self._loop.time() - now)
except DisconnectedError:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. this will catch disconnects from aiohttp.client
  2. ServerHttpProtocol.start() already handles ClientDisconnectedError, change start()

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 3, 2015

lgtm, except two notes regarding exceptions.

…, get rid of checking for disconnection in web.RequestHandler
@asvetlov
Copy link
Member Author

asvetlov commented Jan 3, 2015

Exceptions are fixed.

On Sat, Jan 3, 2015 at 8:49 PM, Nikolay Kim notifications@github.com
wrote:

lgtm, except two notes regarding exceptions.


Reply to this email directly or view it on GitHub
#220 (comment).

Thanks,
Andrew Svetlov

@asvetlov
Copy link
Member Author

asvetlov commented Jan 3, 2015

Please review again.

@fafhrd91
Copy link
Member

fafhrd91 commented Jan 3, 2015

awesome! :)

lgtm

asvetlov added a commit that referenced this pull request Jan 3, 2015
Implement aiohttp.web websockets
@asvetlov asvetlov merged commit 04e9620 into master Jan 3, 2015
@asvetlov asvetlov deleted the websockets branch January 3, 2015 18:59
@asvetlov
Copy link
Member Author

asvetlov commented Jan 3, 2015

@fafhrd91 thanks for reviews

@fafhrd91 fafhrd91 mentioned this pull request Jan 3, 2015
@lock
Copy link

lock bot commented Oct 30, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 30, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants