https://docs.python.org/ja/3/howto/sockets.html This is a memo when I read this. Since it is a dump of the brain while reading, it is recommended that those who simply want to know the contents read the document directly. python3.8.2
――I want to read the document here and know the functions that are actually useful to use without knowing it. ――It's been about 8 years since I started using python, but I'm doing it in an atmosphere, so there are still some features I don't know. ――I use flask ・ django and zmq occasionally, but I have lived while looking away from the internal socket programming. ――Anyway, I want to know what a socket is doing.
--General socket programming, especially INET STREAM (that is, IPv4 TCP), will be explained briefly by writing in python. ――I have no idea what you are saying at this point ――Neither socket programming nor how to write in python is explained in detail.
You should be able to get enough information to be able to use it without embarrassment
And that
--Sockets were invented by Berkeley as part of BSD Unix and became very popular.
--There are sockets for client side and server side respectively. ――Since this is the same with zmq, it seems that the interface will be conscious of the socket level. ――So I will read it while imagining it with zmq
client side
client_socket.py
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("qiita.com", 80))
only this. Easy
server side
server_side.py
#Make a server socket
serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.bind((socket.gethostname(), 80))
serversocket.listen(5)
# serving
while True:
clientsocket, address = serversocket.accept()
# threaded server
ct = client_thread(clientsocket)
ct.run()
It's a little more, but it's pretty simple.
--In the first line, the variable name is serversocket, but what you are doing is exactly the same as clientsocket. --A server socket is a guy who creates a client socket that talks (= sends) to a listening port when something connects () to it. ――If you make it, you will continue to listen -In the context of descriptor read yesterday, for example, bounding a function to an object always assigns itself to the default first argument of the function. Was that --Bind here was also interpreted as the same'binding' ――In other words, first you created an anonymous server socket and registered socket.gethostname () as the host to go to listen to. --By analogy with the descriptor example, there seems to be something in the world that dynamically adjusts the listening destination without binding. --Also, clientsocket.connect passes the host and port, but I imagine that serversocket is supposed to pass it to the more primitive name used here by default.
――I explain with a more concrete example --The client socket generated on the server side is the same as the one purified on the client side --The above-mentioned flow of connecting from client to server → server generates client socket → client sockets talk to each other is a one-level abstract design, not the specifications of the socket itself. --The code example is an easy-to-understand example of sending and receiving messages with socket. --You have to worry about whether you have sent all the messages or if they are still in the network buffer. ――The rest is similar to zmq? ――It is difficult to receive multiple messages, and the breaks are not trivial --Several solutions and their problems are shown ――It seems a good solution to send the length at the beginning, but even if you indicate the data length with a 5-digit number, for example, it is not always possible to receive 5 characters at once on a high-load network.
--Conversion is required for different endianness ――When sending a large number of longs, 0 is 4 bytes for long but 2 bytes for ASCII. ――Let's look carefully at the data and make a selection
--When disconnecting, originally shutdown () and close ()
--The python library does shutdown (); close (); with only close ()
--Moreover, python automatically closes when GC is done.
――But if the socket dies unintentionally, the opponent may hang, so it is better not to rely on this
--Non-blocking with socket.setblocking (0)
--Unlike blocking sockets, send, recv, connect, accept may come back without doing anything
--Option 1: Handle return value and error → Seems to go crazy
--Option 2: Use select
--If you pass a list of sockets to select.select, only those that are readable / writable will be returned, so you can use the above verbs with them.
I took a quick look at the implementation because it was a big deal https://github.com/python/cpython/blob/3.8/Lib/socket.py#L213 --If you use it with with syntax, it seems to call you to close when you leave the context --When used by humans, it would be better to use SocketIO or create_server.
――I think it's better to look at other than INET and STREAM to understand more deeply. ――I will never use it directly, but I realized that zmq is a pretty good abstraction.
Recommended Posts