Patrones de comunicación con sockets
Patrones prácticos sobre sockets TCP: enviar objetos serializados, el protocolo de largo de 4 bytes, servidores concurrentes con threads y arquitecturas multi-servidor y P2P.
data_object
Enviar objetos por un socket
Los sockets solo transmiten bytes. Para enviar estructuras de Python (dicts, objetos) las serializamos antes de enviar y las deserializamos al recibir, combinando lo visto en este curso.
- Con JSON:
json.dumps(...)y luego.encode()para enviar; al recibir,.decode()yjson.loads(...). - Con pickle:
pickle.dumps(...)ya entrega bytes (listos para enviar) ypickle.loads(...)reconstruye.
Echo server
Un echo server recibe datos y los devuelve tal cual. No le importa el formato: solo recibe bytes y los reenvía.
python
# Servidor echo (recibe bytes y los devuelve)import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sock.bind(('localhost', 12345))sock.listen()sock_cliente, _ = sock.accept() while True: data = sock_cliente.recv(4096) if not data: break sock_cliente.sendall(data) # lo enviamos de vueltapython
# Cliente que envia un dict como JSONimport json, socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sock.connect(('localhost', 12345)) mensaje = json.dumps({1: 'Hola', 2: 'Chao'})sock.sendall(mensaje.encode('utf-8')) respuesta = json.loads(sock.recv(4096).decode('utf-8'))print(respuesta)sock.close()Cargando Quiz...
schema
El problema del tamaño: protocolo de largo
Si envías un archivo grande, un solo recv(4096) trae solo una parte. ¿Cómo sabe el receptor cuántos bytes debe leer en total?
La solución es definir un protocolo: antes del mensaje, enviar su largo en un encabezado de 4 bytes (usando to_bytes/from_bytes). Con 4 bytes podemos indicar tamaños de hasta 232 bytes (4 GiB).
Emisor: largo y luego datos
python
# Emisor: primero el largo (4 bytes), luego el contenidowith open('enviar.bin', 'rb') as binfile: datos = binfile.read() largo = len(datos)sock.sendall(largo.to_bytes(4, byteorder='big')) # encabezado bytes_enviados = 0while bytes_enviados < largo: bytes_enviados += sock.send(datos[bytes_enviados:])hub
Servidor concurrente con threads
accept() y recv() bloquean el thread donde se ejecutan. Si el servidor atiende a un cliente, no puede aceptar a otro al mismo tiempo. La solución es usar threads (lo que vimos en la unidad de threading).La estructura típica de un servidor concurrente es:
- Un thread dedicado a aceptar nuevas conexiones en bucle.
- Por cada cliente aceptado, lanzar un thread nuevo que escuche y responda a ese cliente en particular.
python
import socket, threading class Server: def __init__(self, host, port): self.socket_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.socket_server.bind((host, port)) self.socket_server.listen() # Aceptamos en un thread aparte para no bloquear el principal threading.Thread(target=self.accept_loop).start()architecture
Otras arquitecturas: multi-servidor y P2P
El patrón de threads se extiende a otras topologías de red.
Cliente conectado a varios servidores
Un cliente puede conectarse a más de un servidor a la vez. Como el socket lo crea cada conexión, se necesita un socket distinto por servidor y un thread por conexión para escuchar a cada uno. El programa decide a qué servidor enviar según corresponda.
python
self.sockets = { 1: socket.socket(socket.AF_INET, socket.SOCK_STREAM), 2: socket.socket(socket.AF_INET, socket.SOCK_STREAM),}self.sockets[1].connect((host1, port1))self.sockets[2].connect((host2, port2))# Un thread de escucha por cada socketPeer to Peer (P2P)
En una arquitectura P2P no hay un servidor central: todos los nodos son equivalentes. Cada programa actúa a la vez como servidor (abre un socket y acepta conexiones) y como cliente (se conecta a los otros pares). Cada par tiene entonces los métodos de ambos roles y, nuevamente, usa threads para que los sockets no se bloqueen entre sí.