> Excuse my ignorance, but: A case for refactoring?
Certainly, but it is debatable what exactly the best refactorization
is. Abstractly, these fall into two cases
- open a stream connection to some address (aka "client socket")
- open a server socket to wait for incoming clients
Either of these may find that it opens AF_INET, AF_INET6, or AF_UNIX
sockets, depending on the values of host and port, and depending on
what name lookup returns. Also, similar procedures are required for
opening datagram sockets.
In Ruby, this loop is done completely in C code, and there is a number
of wrapper classes to access the various options:
- TCPSocket opens a client stream socket, i.e. does getaddrinfo(),
socket(), connect()
- UDPSocket opens a client datagram socket. Same as TCPSocket, only
that it uses SOCK_DATAGRAM
- TCPServer opens a server stream socket, i.e. does getaddrinfo,
socket, bind, and listen(5)
- UDPServer likewise
- UNIXSocket opens a client AF_UNIX socket
- UNIXServer opens a server AF_UNIX socket
- Socket does socket() only, allowing for subsequent other low-level
calls
There are some base classes: IPSocket is the base for all
{TCP,UDP}{Socket,Server}; BasicSocket is base for UNIX{Socket,Server},
IPSocket, and Socket.
I cannot say that I particularly like this API, but I could not easily
find other/better generalizations. Therefore, no API is defined,
yet. Please note that refactorizing "for internal use only" is not an
acceptable solution: This is the Python library, so any function that
gets defined has to be supported for quite some time.
Any new API probably needs to take the existing SocketServer into
account, also.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4