Skip to content
This repository has been archived by the owner on Nov 23, 2017. It is now read-only.

UNIX domain sockets #81

Closed
GoogleCodeExporter opened this issue Apr 10, 2015 · 13 comments
Closed

UNIX domain sockets #81

GoogleCodeExporter opened this issue Apr 10, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link

Both Glyph and Ben want a UNIX domain socket API. We agree that this shouldn't 
be rolled into create_connection() -- although the reference implementation 
could probably share plenty of code.

Original issue reported on code.google.com by gvanrossum@gmail.com on 24 Oct 2013 at 11:51

@GoogleCodeExporter
Copy link
Author

Would this warrant a module namespace? Or just an extra set of functions? (i.e 
any opinions on where it should be located?)

Original comment by teh....@gmail.com on 6 Nov 2013 at 9:07

@GoogleCodeExporter
Copy link
Author

I was envisioning it as siblings of create_connection() and create_server(). 
Maybe create_local_connection() and create_local_server() (echoing the now 
outmoded AF_LOCAL alias for AF_UNIX). There could be some shared code at the 
transport layer.

Original comment by gvanrossum@gmail.com on 6 Nov 2013 at 3:58

@GoogleCodeExporter
Copy link
Author

I wasn't aware of AF_LOCAL alias and I guess I'm not the only one.
That is why I would prefer create_unix_server() and create_unix_connection() 
better (more explicit and widely recognized).

Original comment by g.rodola on 6 Nov 2013 at 4:23

@GoogleCodeExporter
Copy link
Author

Sure, that works too.

Original comment by gvanrossum@gmail.com on 6 Nov 2013 at 4:24

@GoogleCodeExporter
Copy link
Author

What's the status of this? Can we still push it in 3.4?

Original comment by yseliva...@gmail.com on 11 Feb 2014 at 12:48

@GoogleCodeExporter
Copy link
Author

If it's a clean new feature that doesn't break working code we could push it in 
RC2 (RC1 is already being finalized). But I haven't received any contributions. 
It shouldn't be hard to write this as a 3rd party add-on though, either 
subclassing or copying some existing code.

Original comment by gvanrossum@gmail.com on 11 Feb 2014 at 12:52

@GoogleCodeExporter
Copy link
Author

> But I haven't received any contributions.
I'll try to find some time for this then

Original comment by yseliva...@gmail.com on 11 Feb 2014 at 12:54

@GoogleCodeExporter
Copy link
Author

Should we add a 'open_unix_connection' function too? (I'm +1)

Original comment by yseliva...@gmail.com on 11 Feb 2014 at 11:06

@GoogleCodeExporter
Copy link
Author

> Should we add a 'open_unix_connection' function too? (I'm +1)

I suppose, though perhaps this could be done using a hack in open_connection() 
/ start_server() by passing a host that starts with '/' and no port?

Original comment by gvanrossum@gmail.com on 12 Feb 2014 at 12:06

@GoogleCodeExporter
Copy link
Author

> I suppose, though perhaps this could be done using a hack in 
open_connection() / start_server() by passing a host that starts with '/' and 
no port?

open_connection, start_server and open_connection all accept two parameters for 
address - host and port. If instead of two parameters they would accept one -- 
tuple (like socket.bind) of host and port, then your suggestion would work. If 
a user passes a tuple -- then we have AF_INET, if str - AF_UNIX. Guessing if 
it's a UNIX socket just by the hostname is IMHO error prone.  What is 
'localhost'? A hostname, or a filename in the current directory?

Changing signatures of these three methods is not an option at this stage 
(right?) too.

Original comment by yseliva...@gmail.com on 12 Feb 2014 at 3:33

@GoogleCodeExporter
Copy link
Author

> Can we still push it in 3.4?

It's hard to say, it's risky to push anything new in Python 3.4 after the RC1 
:-/

I would be easier to vote with a patch to review.

Original comment by victor.s...@gmail.com on 12 Feb 2014 at 5:55

@GoogleCodeExporter
Copy link
Author

Here's a patch for review: https://codereview.appspot.com/62350043
Most changes are in unit-tests, so I really hope we can still include this in 
3.4

Original comment by yseliva...@gmail.com on 12 Feb 2014 at 7:45

@GoogleCodeExporter
Copy link
Author

This issue was closed by revision aaf0a37e3e54.

Original comment by yseliva...@gmail.com on 18 Feb 2014 at 5:09

  • Changed state: Fixed

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

No branches or pull requests

1 participant