133 lines
4.3 KiB
Markdown
133 lines
4.3 KiB
Markdown
Title: Introduction To TCP Sockets
|
|
|
|
Client Sockets
|
|
--------------
|
|
|
|
Sockets are sort of like PBX phone systems, where the IP address is
|
|
the phone number, and the port is the extension. Every paired
|
|
(connected) socket has a source IP/port and a destination IP/port.
|
|
|
|
|
|
When you want to hook up to a listening server, first you have to
|
|
request a socket from the kernel. You use the socket() call. In
|
|
Python, that'd be:
|
|
|
|
<pre>
|
|
import socket
|
|
s = socket.socket(socket.PF_INET, socket.SOCK_STREAM)
|
|
</pre>
|
|
|
|
That tells Python that you want a socket in the Internet class (as
|
|
opposed to, say Appletalk), and that it should be a streaming
|
|
socket (TCP, as opposed to a datagram socket, which would be UDP).
|
|
|
|
The next thing you can do is tell the kernel what IP/port you'd like to
|
|
use as the source port (think of this as the number that will show
|
|
up on caller ID when you make your connection). You can do this
|
|
with the bind() call, like this:
|
|
|
|
<pre>
|
|
s.bind(("192.168.4.216", 9234))
|
|
</pre>
|
|
|
|
This tells the kernel to use the IP/port of 192.168.4.216 and 9234. When
|
|
you make an outbound connection, it will come from that IP and that
|
|
port. You can use 0 for the IP and 0 for the port, in which case
|
|
the kernel picks one for you. Or you can skip the bind call
|
|
entirely, which is the same as binding to `('', 0)`.
|
|
|
|
So you've got a socket and it's bound to something, now all you
|
|
have to do is connect it (make your phone call). In Python:
|
|
|
|
<pre>
|
|
s.connect(("192.168.4.12", 80))
|
|
</pre>
|
|
|
|
That'll hook you up to port 80 (the HTTP port) of 192.168.4.12.
|
|
|
|
From then on you can use s just like it was a file, with read and
|
|
write replaced with send and recv (I think you can actually use
|
|
read and write on sockets, but traditionally send and recv are used):
|
|
|
|
<pre>
|
|
s.send("GET / HTTP/1.0\n\n")
|
|
print s.recv(8192)
|
|
</pre>
|
|
|
|
When you're done, just close it:
|
|
|
|
<pre>
|
|
s.close()
|
|
</pre>
|
|
|
|
|
|
Server Sockets
|
|
--------------
|
|
|
|
Since a server operates on a IP/port combination too, you still do the
|
|
socket and bind calls (and you can skip the bind if you want any random
|
|
port, but I've never heard of a server that doesn't care what port it's
|
|
listening to). Then the next thing you have to do for a server, instead
|
|
of connecting, is listen. In Python:
|
|
|
|
<pre>
|
|
s.listen()
|
|
</pre>
|
|
|
|
That tells the kernel to start listening for incoming connections
|
|
to the IP/Port you got with bind.
|
|
|
|
Once you get a connection set up in the kernel, you have to ask the
|
|
kernel for that connection. That conenction will be a different file
|
|
descriptor than the one you had listening, so that you can have multiple
|
|
connections plugged in to the same ip/port and keep them all distinct.
|
|
The call you make to the kernel is "accept" and by default it will block
|
|
(that is, the kernel won't return control to your program) until there's
|
|
a new socket established. So you'll see loops like this:
|
|
|
|
<pre>
|
|
while 1:
|
|
c = s.accept()
|
|
cli_sock, cli_addr = c
|
|
|
|
cli_sock.send("Hello, person from %s" % cli_addr)
|
|
</pre>
|
|
|
|
So there, you are accepting from s, it puts the new socket in c. Python
|
|
does a little trick here, in that it actually returns a tuple (like a
|
|
list) with the first value the actual socket, and the second value the
|
|
address (ip/port) of the incoming connection. So you don't have to ask
|
|
again to find out who just connected to you, get get it with the accept
|
|
call. The C library does this in a slightly different way, but you
|
|
still get the same information. And at that point, you can start
|
|
treating the client socket just like you would any other connected
|
|
socket.
|
|
|
|
|
|
Forking for fun and profit
|
|
--------------------------
|
|
|
|
The code above is the serializing (FIFO) model, but you'd need to
|
|
fork to handle multiple requests simultaneously. In practice,
|
|
hardly anything serializes requests, what's more common is
|
|
something like this:
|
|
|
|
<pre>
|
|
while 1:
|
|
c = s.accept()
|
|
if os.fork():
|
|
c.close()
|
|
else:
|
|
do_client_stuff(c)
|
|
c.close()
|
|
exit(0)
|
|
</pre>
|
|
|
|
If you're just learning sockets, do a serialized socket first. It'll be
|
|
easier to understand what's going on that way. But forks are easy too.
|
|
You call fork() and then you get a new process that starts with the same
|
|
everything (all the variables are the same and it starts running right
|
|
after the fork() call). After the fork, both are running as if the fork
|
|
has just completed, but the parent's fork returned the PID of the new
|
|
process, and the child's fork returned 0.
|