Closed rapha-opensource closed 6 years ago
I never really envisioned Channels as being a replacement for sockets so I hadn't thought this facet of the API (it was modeled more after the multiprocessing module or maybe parts of ZMQ). I'm somewhat more inclined to make the address an attribute of the resulting Connection object instead of returning it as a second value.
On a trusted network, it makes message passing so easy it's liberating. From a theoretical viewpoint, I'd love the consistency, as it elevates the api to the level of a protocol and I wouldn't even have to read the docs :) Granted this would break everyone's code. At the end of the day, if I can get my client address, even as an attribute, I'm a happy guy!
Are you thinking about using channels over an open network? Just thinking about the bigger picture of how I might harden the code.
yes, I'm toying with that idea, with SSL layered in, so not strictly open. Any reason why this wouldn't be a good idea?
Channels have a new method check_address()
that can be used to check the address of incoming connections. Right now, it can be overridden via inheritance of the Channel
class. I'm not sure I'll keep it this way, but it's a starting point.
https://github.com/dabeaz/curio/blob/bd0e2cb7741278d1d9288780127dc0807b1aa5b1/curio/channel.py#L225
It returns the client connection instead of (connection, addr). Shouldn't we try to match Python's Socket.accept signature? Also, how do I retrieve the client's address then?