-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Websockets are automatically closed after response #691
Comments
It is intended to use in loop. Something like this:
|
So I can't use the websocket outside that coroutine? Quite unhandy. |
Strictly speaking you should use the single task for receiving data from websocket. |
both client and web implementation are higher level api on top of aiohttp.websoket implementation,
|
It seems to me counterintuitive to have a loop only to maintain the websocket opened, since they are usually created to have a persistent connection channel between client and server, and not a disposable one. What's the advantage from 0.14.4? |
It is possible to use synchronous approach instead of callbacks like twisted and friends. That's why |
I can be wrong, but I think you could do this also before. The only difference is that if the coroutine exists, the websocket is closed, even if the object still exists. Please see the modified example:
Ok, it's not good to have a global, but do you see the problem? The object still live, so why it must be closed? |
Mentally replace Is it intuitive that response is finished and should not be used after finishing web-handler even if you have stored it in global list? |
This all is to be able to work in synchronous manner: def wshandler(request):
msg = "Hello"
ws = web.WebSocketResponse()
print("before start")
ws.start(request)
ws.send_str(msg)
a.append(ws)
while True:
try:
msg = yield from ws.receive()
except aiohttp.errors.ClientDisconnectedError:
LOG.info("Disconnected %s" % ws)
if msg.tp == web.MsgType.close:
break
a.remove(ws) # <- see
return ws As for me, using protocol instances with all this methods like It is not better or worst, it just another. |
@asvetlov: because "special cases aren't special enough to break the rules"? The problem is you're reasoning in terms of http connection. Websocket is a different protocol, and its connection is intended to be persistent, more similar to "classical" sockets. Indeed you have not to The other problem is naming it "reponse". That object is not a response, IMHO. Websockets are a persistent full-duplex connection, so the same connection can be used to get "requests" and send "responses" until not explicitly closed or garbage-collected because not used anymore. See WHATWG spec: https://html.spec.whatwg.org/multipage/comms.html#network Lastly, the way you're implementing it impose people to listen for client messages. But in theory I could use websockets only for sending messages to the client. By the way, that's what the code I'm working on is actually doing. The fact you have to do this or die it's not only counterintuitive, it's cucumbersome. I can live with it and code this way, since I do not have to work with aiohttp very much. But I strongly encourage you to rethink about your decision. |
@MarcoSulla that ship has sailed. BTW
|
Steps to reproduce:
Substitute
yield from ws.prepare(request)
withws.start(request)
for older versions.RESULT:
In console is logged:
WEBSOCKET OPENED
Hello
WEBSOCKET CLOSED
EXPECTED:
In console should be logged
WEBSOCKET OPENED
Hello
The text was updated successfully, but these errors were encountered: