search

dabeaz / curio

Good Curio!
Other
4.02k stars 241 forks source link

Channel.accept signature #237

Closed rapha-opensource closed 6 years ago

rapha-opensource commented 6 years ago

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?

dabeaz commented 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.

rapha-opensource commented 6 years ago

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!

dabeaz commented 6 years ago

Are you thinking about using channels over an open network? Just thinking about the bigger picture of how I might harden the code.

rapha-opensource commented 6 years ago

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?

dabeaz commented 6 years ago

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.