Usando Internet Sockets Brian "Beej" Hall Copyright by Brian "Beej" Hall

Transcripción

1 Usando Internet Sockets Brian "Beej" Hall Copyright by Brian "Beej" Hall Historia Revision Version August, 1995 Revised by: beej Initial version. Revision Version January 13, 1999 Revised by: beej Latest HTML version. Revision Version March 6, 2001 Revised by: beej Converted to DocBook XML, corrections, additions. Revision Version April 2, 2001 Revised by: beej inet_aton() return values corrected, selectserver changed, typos fixed, added recvtimeout(). Traducción al español Domingo 22 de Abril de 2001 por: 1

2 Índice 1. INTRODUCCIÓN AUDIENCIA PLATAFORMA Y COMPILADOR PAGINA OFICIAL NOTA PARA SOLARIS/SUNOS NOTA PARA WINDOWS MIRRORS NOTA PARA LOS TRADUCTORES COPYRIGHT Y DISTRIBUCIÓN 6 2. QUÉ ES UN SOCKET? DOS TIPOS DE SOCKETS DE INTERNET COSAS DE BAJO NIVEL Y TEORÍA DE RED 8 3. STRUCTS Y MANEJO DE DATOS CONVIRTIENDO A LOS NATIVOS! DIRECCIONES IP Y COMO LIDIAR CON ELLAS LLAMADAS AL SISTEMA SOCKET() CONSIGUE EL DESCRIPTOR DE ARCHIVO! BIND() - EN QUE PUERTO ESTOY? CONNECT() HEY, TÚ! LISTEN() - ALGUIEN ME LLAMARÍA POR FAVOR? ACCEPT() - GRACIAS POR LLAMAR AL PUERTO SEND() Y RECV() - HÁBLAME, BABY! SENDTO() Y RECVFROM() HÁBLAME, AL ESTILO DGRAM! CLOSE() Y SHUTDOWN() SALE DE MI VISTA! GETPEERNAME() QUIÉN ERES? GETHOSTNAME() QUIÉN DIABLOS SOY? DNS TÚ DICES WHITEHOUSE.GOV, YO DIGO SISTEMA CLIENTE-SERVIDOR UN SIMPLE SERVIDOR DE FLUJO (STREAM) UN SIMPLE CLIENTE DE FLUJO DATAGRAM SOCKETS 30 2

3 6. TÉCNICAS LIGERAMENTE AVANZADAS BLOQUEANDO SELECT() MULTIPLEXAMIENTO SINCRONIZADO DE E/S MANEJANDO ENVÍOS (SEND()S ) PARCIALES HIJO DE LA ENCAPSULACIÓN MÁS REFERENCIAS PÁGINAS MAN LIBROS RFCS PREGUNTAS COMUNES DESLIGAMIENTO DE RESPONSABILIDAD Y PETICIÓN DE AYUDA 49 3

4 1. Introducción Hey! La programación en Socket te tiene bajoneao? Esto es muy difícil para aprenderlo de las páginas man? Quieres hacer un programa genial para Internet, pero no tienes tiempo para gastar tratando de descifrar si tienes que llamar bind() antes de connect(), etc, etc. Bueno, adivina! Yo ya he hecho este asqueroso trabajo, y me muero por compartir la información con todos! Has llegado al lugar indicado. Este documento debería darle al programador(a) C el apoyo que necesita para dedicarse a la programación en red Audiencia Este documento ha sido escrito como un tutorial, no como una referencia. Será de mejor ayuda a quienes están empezando en la programación con Sockets y están buscando un puntapié. Realmente no es la guía definitiva para programación, pero todo vale. Espero, fuertemente, que sea suficiente para que esas páginas man empiecen a tener sentido Plataforma y Compilador Los ejemplos que contiene este documentos fueron compilados en un PC Linux usando el compilador GNU gcc. Deberían, de todas maneras, poder ser construidos en cualquier sistema que use gcc. Naturalmente, esto no se aplica si estás programando en Windows (ve la sección de Windows, abajo) Pagina Oficial La dirección oficial de este documento es: La dirección de la traducción es español es: Nota para Solaris/SunOs Cuando se compila para Solaris o SunOS, necesitas especificar algunas líneas extras de comandos para linkear las librerías apropiadas. Para hacer esto, simplemente añade: - lnsl -lsocket -lresolv al final del comando para compilar, más o menos así: $ cc o server server.c -lnsl -lsocket -lresolv Si sigues teniendo errores, podrías tratar agregando -lxnet al final de la línea. Yo no sé que hace eso, exactamente, pero algunas personas parecen necesitarlo. 4

5 1.5 Nota para Windows Tengo un particular disgusto por Windows, y te recomiendo que pruebes Linux, BSD o Unix. Que quede dicho, tú aun puedes usar esto bajo Windows. Primero, ignora casi todos los encabezados que menciono en este documento. Todo lo que necesitas incluir es: #include <winsock.h> Espera! Además tienes que hacer una llamada a WSAStartup() antes de hacer algo con la librería de Sockets. El código para hacer eso, es mas o menos: #include <winsock.h> { WSAData wsadata; If (WSAStartup{MAKEWORD(1, 1), &wsadata!= 0) { Fprintf(stderr, WSAStartup failed.\n ); Exit(1); Una vez hecho esto, el resto de los ejemplos en este tutorial deberían funcionar, con unas pocas excepciones. Por un lado, no puedes usar close() para cerrar un socket, necesitas usar closesocket(), en vez. Además, select() sólo trabaja con descriptores de socket, no con descriptores de archivo (como 0 para stdin). Para más información sobre Winsock, lee el FAQ de Winsock Mirrors Eres bienvenido si deseas hacer un mirror de este sitio. Ya sea público o privado. Si es público y deseas que yo lo linkee desde la página oficial, tírame un mail a beej@piratehaven.org Nota para los Traductores Si deseas traducir esta guía a otro lenguaje, escríbeme y yo pondré la dirección en mi página. Siéntete libre de agregar tu nombre e a la traducción. 5

6 1.8. Copyright y Distribución Beej s Guide to Network Programming es Copyright Brian Beej Hall. Esta guía puede ser reimpresa libremente, siempre que no sea alterada, y se mantengan los derechos de autor intactos. Se recomienda a los educadores que provean esta guía a sus estudiantes. Esta guía puede ser traducida libremente en cualquier lenguaje, y debe ser enteramente traducida. La traducción puede incluir el nombre y la manera de contactar al traductor. El código C presentado en este documento es dado al dominio público. Contactar a beej@piratehaven.org para más información. Contactar a kaosk@hotpop.com para más información (traductor). 6

7 2. Qué es un Socket? Tú escuchas sobre Sockets todo el tiempo, y quizás te está preguntado que son exactamente. Bueno, son esto: una manera de habla a otro programa usando descriptores de archivos Unix estándar. Qué!? Ok, tu debes haber escuchado que todo en Unix es un archivo. Lo que esto quiere decir es que cuando un programa Unix realiza cualquier tipo de E/S, lo hacen leyendo o escribiendo a un descriptor de archivo. Un descriptor de archivo es simplemente un numero entero asociado a un archivo abierto. Pero (y aquí está la conexión), ese archivo puede ser una conexión de red, un FIFO, un terminal, un archivo real en el disco, o cualquier otra cosa. Todo en Unix es un archivo. Así que cuando deseas comunicarte con otro programa por Internet, vas a tener que hacerlo a través de un descriptor de archivo, mejor que lo creas. Donde consigo este descriptor de archivo para comunicación de Red, Mr. Capo? es probablemente la última pregunta en tu cerebro, pero la voy a responder igual: Haces una llamada a la rutina de sistema socket(). Ésta devuelve el descriptor del socket, y te comunicas a través de el usando las funciones especializadas send() y recv(). Pero, oye!,debes estar gritando ahora, Si es un descriptor, porque en el nombre de Linus no puedo usar las llamadas read() y write() para comunicarme a través del socket? La respuesta simple es: Sí puedes! La respuesta real sería: Puedes, pero send() y recv() ofrecen un mejor control sobre tu transmisión de datos. Qué sigue? Que tal esto: hay todo tipo de sockets. Están las direcciones de Internet DARPA (sockets de Internet), nombres de ruta en un nodo local (sockets de Unix), direcciones CCITT X.25 (sockets X.25 que se pueden ignorar), y probablemente muchos otros dependiendo en que sabor de Unix estás. Este documento trabaja con el primero: Sockets de Internet Dos tipos de Sockets de Internet Qué es esto? Hay dos tipos de socket en Internet? Si. Bueno... no. Estoy mintiendo. Hay más, pero no quiero asustarte. Sólo voy a hablar de dos tipos aquí. Pero debo decirte que los Raw Sockects son muy poderosos y deberías echarle una ojeada. Todo bien hasta ahora. Pero cuales son los dos tipos? Uno es Stream Sockets (Sockets de Flujo) y el otro Datagram Sockets, a los que nos referiremos como SOCK_STREAM Y SOCK_DGRAM, respectivamente. Los SOCK_DGRAM son a veces llamados sockets sin conenxion. Los stream sockets son flujos confiables de comunicación de dos-vías. Si mandas dos ítem por el socket en el orden 1, 2, ellos llegarán en el orden 1, 2 al otro lado. También estarán libres de error. Cualquier error que encuentres son producidos por tu propia mano, y no serán discutidos aquí. 7

8 Porqué usar stream sockets? Bueno, debes haber escuchado de las aplicaciones telnet, si?... Ocupa stream sockets. Todos los caracteres que tipeas necesitan llegar en el mismo orden en que los mandaste, correcto? Además, los navegadores web usan el protocolo HTTP el que usa stream sockets para obtener las páginas. De hecho, si tu haces telnet a un sitio en el puerto 80, y tipeas GET /, te arrojará el código html. Cómo los stream sockets mantienen la alta calidad de esta transmisión de datos? Ellos usan un protocolo llamado Protocolo de Control de Transmisión, conocido como TCP (ve RFC-793 para detalles). TCP se asegura de que tus datos lleguen secuencialmente y libre de errores. Debes haber escuchado acerca de TCP antes en TCP/IP donde IP es Protocolo de Internet (RFC-791). IP trata primeramente el rutamiento en Internet y no se responsabiliza por la integridad de los datos. Cool. Que pasa con los Datagram sockets? Por qué son llamados sockets sin conexión? Qué onda? Por qué no son confiables? Bueno, he aquí algunos hechos: si envías un datagram, puede que llegue. Puede llegar desordenado. Si llega, los datos del paquete estarán libres de errores. Datagram sockets también usan IP para el rutamiento, pero ellos no usan TCP; ellos usan Protocolo de Datagramas de Usuario o UDP (RFC-768). Por qué sin conexión? Bueno, básicamente, es porque no tienes que mantener una conexión abierta como con stream sockets. Tu sólo construyes un paquete, le pegas un encabezado IP con la información del destino, y lo mandas. Son generalmente usados para transferencia de información paquete por paquete. Algunas aplicaciones son: tftp, bootp, etc. Suficiente! puedes gritar. Como van a funcionar estos programas si los datagramas se pierden? Bueno, amigo mortal, cada uno tiene su propio protocolo en la cima del UDP. Por ejemplo, el protocolo tftp dice que por cada paquete enviado, el receptor debe enviar un paquete de vuelta que diga, Lo tengo (un paquete ACK ). Si el que envía el paquete original no tiene respuesta en, digamos, 5 segundos, el retransmitirá el paquete hasta que finalmente le llegue un ACK. Este conocido procedimiento es muy importante cuando implementamos aplicaciones SOCK_DGRAM Cosas de Bajo Nivel y Teoría de Red Ya que hemos nombrados los protocolos, es hora de hablar de cómo funciona realmente un red, y mostrar algunos ejemplos de cómo los paquetes SOCK_DGRAM son construidos. Seguramente te podrías saltar esta sección, pero nunca está de más aprender. Hey, niños, es hora de aprender sobre Encapsulación de datos! Esto es muy importante. Es tan importante que podrías encontrar una carrera entera sobre esto aquí en el Estado de Chico. Básicamente dice esto: un paquete nace, el paquete es envuelto ( encapsulado ) en un encabezado (y raramente al final) por el primer protocolo (digamos, TFTP), 8

9 Figura 1. Encapsulación de Datos luego todo (el encabezado TFTP incluido) es encapsulado de nuevo por el siguiente protocolo (UDP, digamos), luego nuevamente por el siguiente (IP), luego de nuevo por el protocolo final el capa (física) de hardware (sea Ethernet). Cuando la otra computadora recibe el paquete, el hardware extrae el encabezado Ethernet, el kernel hace lo mismo con los encabezados UDP e IP, el programa TFTP extrae el encabezado TFTP, y al final sólo queda el dato. Ahora por fin puedo hablar de la infame Capa de modelo de Red. Esta describe un sistema de red que tiene muchas ventajas sobre otros modelos. Por ejemplo, tu puedes escribir programas de sockets que son exactamente iguales sin preocuparte de cómo se transfieren los datos físicamente (serial, thin Ethernet, AUI, como sea), ya que programas en niveles inferiores hacen el trabajo por ti. El hardware y la topología de red actuales son transparentes para el programador de sockets. Sin entrar en más, te presento las capas del hablado modelo. Recuerda esto para tu examen de Redes: Capa Física Capa de enlace Capa de Red Capa de Transporte Capa de Sesión Capa de Presentación Capa de Aplicación La Capa Física es el Hardware (serial, Ethernet, etc.). La Capa de Aplicación esta los más lejos de la Física, y como te puedes imaginar es el lugar donde los usuarios interactúan con la Red. Ahora, este modelo es tan general que lo podrías emplear para repara autos si quisieras.... Un modelo de capas más consistente con Unix sería más o menos: Capa de Aplicación (telnet, ftp, etc.) Capa de Transporte Host-to-Host (TCP, UDP) Capa de Internet (IP y rutamiento) Capa de Acceso a la Red (Ethernet, ATM, etc). En este punto, probablemente puedas ver como estas capas actúan en la encapsulación del dato original. Ves cuanto trabajo requiere construir un simple paquete? Y tienes que tipearlos tu mismo usando cat!.... No. Todo lo que tienes que hacer para los STREAM SOCKETS es 9

10 send() (enviar) los datos. El kernel construye la Capa de Transporte y de Internet por ti y el hardware se encarga de la Capa de Acceso de Red. OH!! Tecnología Moderna. Así termina nuestra corta expedición dentro de la Teoría de Red. Oh!, sí, se me olvido decirles todo lo que quería acerca del enrutamiento: nada! Así es, no voy a hablar para nada de ello. El router (ruteador) extrae el paquete del encabezado IP, consulta su tabla de ruteo, blah blah blah. Mira el IP RFC si realmente te interesa. Si nunca aprendes sobre eso, bueno, sobrevivirás. 10

11 3. STRUCTS y Manejo de Datos Por fin estamos aquí. Es tiempo de hablar sobre programación. En esta sección, cubriré varios tipos de datos ocupados por la interfaz de sockets, ya que algunos son muy difíciles de deducir. Primero el fácil: un descriptor de socket. Un descriptor de socket es el siguiente: int Un regular int. Las cosas se pondrán raras ahora, así que lee todo y aguanta conmigo. Aprende esto: hay dos tipos de orden de byte: byte más importante primero (llamado a veces un octeto ), o el menos importante primero. Esta forma es llamada Red de Orden de Byte (Network Byte Order). Algunas máquinas guardan sus números internamente en este tipo de Red, otras no. Cuando digo que algo tiene que estar en Network Byte Order, tienes que llamar a una función (como htons() ) para cambiar de Host Byte Order. Si no digo nada, entonces debes dejar en Host Byte Order. (Para los curiosos Network Byte Order también se conoce como "Big-Endian Byte Order ). Mi primera estructura (Struct ) STRUCT SOCKADDR. Esta estructura mantiene información de las direcciones de sockets para varios tipos de estos: struct sockaddr { unsigned short sa_family; // dirección de familia, AF_xxx char sa_data[14]; // 14 bytes de protocolo de dirección ; sa_family puede ser una variedad de cosas, pero será AF_INET para todo lo que hagamos en este documento. sa_data contiene una dirección de destino y un número de puerto para el socket. Esto mas bien es poco manejable, ya que no querrás empaquetar la dirección en sa_data a mano. Para trabajar con STRUCT SOCKADDR, los programadores crearon una estructura paralela: STRUCT SOCKADDR_IN ( IN por Internet ). struct sockaddr_in { short int sin_family; // Familia de dirección unsigned short int sin_port; // Número de Puerto struct in_addr sin_addr; // Dirección de internet ; unsigned char sin_zero[8]; // Mismo tamaño que struct sockaddr Esta estructura facilita la referencia a elemento de dirección de socket. Nota que sin_zero (el cual es incluido para acomodar la estructura al largo de STRUCT SOCKADDR) debería ser establecido a todos los ceros (zeros) con la función memset(). Además, y este es un dato importante, un apuntador a STRUCT SOCKADDR_IN puede lanzar un puntero a STRUCT SOCKADDR y vise-versa. Así que incluso si socket() necesita un STRUCT SOCKADDR*, puedes aún usar STRUCT SOCKADDR_ IN y ponerlo en el último minuto! Además, nota que 11

12 SIN_FAMILY corresponde a sa_family en STRUCT SOCKADDR_IN y debería tomar el valor de AF_INET. Finalmente, SIN_PORT y SIN_ADDR deben ser Network Byte Order! Pero, dices. Como toda la estructura, STRUCC IN_ADRR SIN_ADDR, puede estar en NBT (Network Byte Order)? Esta pregunta requiere un profundo análisis de la estructura STRUCC IN_ADRR, una de las peores uniones vivas: // Internet address (una estructura de razonos históricas) struct in_addr { unsigned long s_addr; ; Bueno, solían estar unidos, pero en estos días parece que ha desaparecido. Una buena pérdida. Así que si has declara ina del tipo STRUCT SOCKADDR_ IN, luego ina.sin_addr.s_addr hace referencia a la dirección IP de 4 byte (en NBT). Nota que si tu sistema aun usara STRUCC IN_ADRR, igual puede indicar la dirección IP de 4 byte exactamente de la misma forma que lo hicimos arriba (gracias a #defne) Convirtiendo a los Nativos! Hemos sido conducidos justo a la próxima sección. Se ha hablado mucho acerca de la conversión de NBO a HBO (Host Byte Order), ahora es tiempo de actuar. Bien. Hay dos tipos que puedes convertir: short (2 bytes) y long (4 bytes). Estas funciones también funcionan para la variante unsigned. Digamos que quieres convertir un short de HBO a NBO. Comienza con h por host, sigue con to, luego n de network, y s de short : h-to-n-s, o htons() (se lee: Host to Network Short, Short de Host a Red). Es casi demasiado fácil. Puedes hacer cualquier combinación que quieras usando: n, h, s y l, exceptuando las estúpidas. Por ejemplo, no existe la función stolh() ( Short to Long Host ), hasta ahora. Pero están: htons() Host a Red Short. htonl() Host a Red Long. ntohs() Red a Hosto Short. ntohl() Red a Host Long. Ahora debes creer que te estás poniendo al tanto. Puedes pensar, Qué hago si tengo que cambiar el orden de los bytes en un char? Luego dices, Uh, no importa. También puedes creer que como tu máquina ya usa NBT, no tienes que llamar a htonl() en tu dirección IP. Deberías estar en lo correcto, pero si tratas de portar un programa a una máquina que tiene un NBT inverso, tu programa fallará. Se portable! Este es un mundo Unix! (Por más que Bill Gates quiera pensar de otra manera). Recuerda: Pone tus bytes en NBT antes de ponerlos en la Red. Un punto final: por qué SIN_ADDR y SIN_PORT necesitan estar en NBT en STRUCT SOCKADDR_IN, pero SIN_FAMILY no? La respuesta es: SIN_ADDR y SIN_PORT son 12

13 encapsulados en el paquete en las capas IP y UDP, respectivamente. Por eso, ellos necesitan estar en NBT. Por otro lado, el campo SIN_FAMILY es sólo usado por el kernel para determinar que tipo de dirección contiene la estructura, así que debe estar en HBO. Además, ya que SIN_FAMILY nos es enviada a la red, puede estar en HBO Direcciones IP y como lidiar con ellas Afortunadamente para ti, hay un montón de funciones que permiten manipular direcciones IP. No hay que deducirlas a mano y embutirlas en un long con el operador «. Primero, digamos que tienes una estructura STRUCT SOCKADDR_IN INA, y la dirección IP de deseas guardar en ella. La función que deseas usar, inet_adrr(), convierta la dirección una dirección IP en la forma números-y-puntos a la forma de un entero largo (long) sin firmar. La transformación se puede hacer como sigue: ina.sin_addr.s_addr = inet_addr(" "); Fíjate que inet_addr() devuelve la dirección en NBT lista, no tienes que llamar a htonl(). Genial! Ahora, el código de arriba no es muy robusto porque no hay comprobación de errores. Mira, inet_addr() devuelve 1 en error. Te acuerda de los binarios? (unsigned) -1 sucede que corresponde a la dirección IP ! Esa es la dirección de transmisión! Mal, mal. Recuerda hacer tu comprobación de errores como corresponde. En realidad, hay una manera más fácil en vez de usar inet_addr():, se llama inet_aton() ( aton significa ASCII a Red ): #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> int inet_aton(const char *cp, struct in_addr *inp); He aquí un ejemplo de su uso al empaquetar un STRUCT SOCKADDR_IN (este ejemplo tendrá mucho más sentido cuando llegues a la sección de bind() y connect()). STRUCT SOCKADDR_in my_addr; my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = htons(myport); // short, network byte order inet_aton(" ", &(my_addr.sin_addr)); memset(&(my_addr.sin_zero), \0, 8); // zero the rest of the struct inet_aton(), en contraste con las otras funciones de sockets, devuelve un valor no cero cuando es exitosa, y cero cuando falla. (Si alguien sabe porque, por favor dígame). Y la dirección es devuelta en inp. Desafortunadamente, no todas las plataformas implementan inet_aton(), aunque es preferible usarlo. Pero en esta guía ocuparemos inet_addr(). 13

14 Ok, ahora puedes convertir cadenas de direcciones IP en su representación binaria. Pero como lo hacemos al revés? Qué tal si tenemos un struct IN_ADDR y lo queremos escribir en notación de números-y-puntos? En este caso, tu querrás usar la función inet_ntoa() ( ntoa significa red a ascii ), como sigue: printf("%s", inet_ntoa(ina.sin_addr)); Eso escribirá la dirección IP. Nota que inet_ntoa() toma STRUCT IN_ADDR como un argumento, no como long. Además hay que destacar que devuelve un puntero a un char. Este apunta a un arreglo char que contiene inet_ntoa(), así que cada vez que llames a inet_ntoa(), este borrará la ultima dirección IP por la que preguntaste. Por ejemplo: char *a1, *a2;.. a1 = inet_ntoa(ina1.sin_addr); // this is a2 = inet_ntoa(ina2.sin_addr); // this is printf("address 1: %s\n",a1); printf("address 2: %s\n",a2); Esto imprimirá: address 1: address 2: Si necesitas guardar las direcciones, haz tu propio arreglo. Eso es todo por ahora. Más tarde, aprenderás a convertir una cadena del tipo whitehouse.gov a su dirección IP correspondiente. (busca sobre DNS, más abajo). 14

15 4. Llamadas al sistema. Esta es la sección donde nos meteremos en las llamadas de sistema que permiten acceder a la funcionalidad de la Red en una máquina Unix. Cuando llamas a una de estas funciones, el kernel toma el control y hace todo el trabajo por ti automagicamente. El lugar donde la mayoría de la gente queda atorada es en saber en que orden hacer las llamadas. En esto, las páginas man no son útiles, como debes haber descubierto. Bueno, en orden de ayudarlos, en las siguientes secciones las llamadas han sido hechas en exactamente (aproximadamente) el mismo orden que tú necesitarás llamarlas en tus programas. Eso, acompañado con unos pocos códigos de ejemplo por aquí y allá, algo de leche y galletas (lo cual confío que puedes obtener por ti solo(a)), y un poco de agallas y coraje, y estarás irradiando mensajes por Internet como el hijo de Juan Cartero! 4.1. socket() Consigue el Descriptor de Archivo! Supongo que no puedo atrasarlo más, tengo que hablar sobre la llamada a sistema socket(). He aquí: #include <sys/types.h> #include <sys/socket.h> int socket(int domain, int type, int protocol); Pero, que son esos argumentos? Primero, domain debería ser "AF_INET", justo como en STRUCT SOCKADDR_in (arriba). El siguiente, el argumento type, le dice al kernel que tipo de socket es: SOCK_STREAM o SOCK_DGRAM. Finalmente, sólo dele el valor 0 a protocol para que socket() escoja el protocolo correcto basado type. (Observación: hay muchos más domains y también hay mas types de los que he nombrado. Mira la página man socket(). Además hay una mejor manera de dar valor a protocol. Ve la página man getprotobyname() ). socket() simplemente te devuelve un descriptor de socket que puedes usar en llamadas a sistemas posteriores, o -1 en error. La variable global errno toma el valor del error (ve la página man de perror() ). Bien, pero, en qué ayuda esto? La respuesta es que por si solo no ayuda en nada, y necesitas leer más y hacer más llamadas a sistema para que tome sentido bind() - En que puerto estoy? Una vez que tienes un socket, deberías tener que asociarlo a algún puerto en tu máquina local. (Esto se hace comúnmente si vas a escuchar (listen() ) por conexiones entrantes en un puerto específico, cuando te hagan telnet a x.y.z puerto 6969 ). El número del puerto es usado por el kernel para asociar un paquete entrante con algún proceso descriptor de 15

16 socket. Si sólo te vas a conectar (connect() ), esto puede se innecesario. Léelo de todas maneras. Esta es un avance de la llamada al sistema bind(): #include <sys/types.h> #include <sys/socket.h> int bind(int sockfd, struct sockaddr *my_addr, int addrlen); sockfd es descriptor de archivo de socket devuelto por socket(). my_addr es un puntero a STRUCT SOCKADDR que contiene información sobre tu dirección, es decir, puerto y dirección IP. addrlen puede ser sizeof (STRUCT SOCKADDR). Uf! Es mucho que tragar de una mascada. Veamos un ejemplo: #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #define MYPORT 3490 main() { int sockfd; struct sockaddr_in my_addr; sockfd = socket(af_inet, SOCK_STREAM, 0); // haz un poco de correción de error! my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = htons(myport); // short, network byte order my_addr.sin_addr.s_addr = inet_addr(" "); memset(&(my_addr.sin_zero), \0, 8); // zero the rest of the struct // don t forget your error checking for bind(): bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr));... De esto hay que decir unas pocas cosas: my_addr.sin_port está en NBO. También my_addr.sin_addr.s_addr. Otra cosa que debemos chequear es que los encabezados del programa pueden variar de sistema a sistema. Para estar seguro, deberías mirar tus páginas man. Por último, sobre bind(), debería mencionar que algunos procesos para identificar tu propia dirección IP y / o puerto, pueden ser automatizados: my_addr.sin_port = 0; my_addr.sin_addr.s_addr = INADDR_ANY; // escoge un puerto libre al azar // usa mi dirección IP Mira, al setear SETTING MY_ADDR.SIN_PORT a cero, le estas diciendo a bind() que escoja el puerto por ti. De la misma manera, al setear my_addr.sin_addr.s_addr a INADDR_ANY, le estás diciendo que automáticamente llene la dirección IP con la que tiene tu PC. Si eres minucioso, puede que te hallas dado cuenta que un puse INADDR_ANY en NBO! Que pillo soy. Como sea, tengo que INADDR_ANY es realmente cero! Cero tendrá cero bits aun cuando reordenes los bytes. Aunque, los cuáticos dirán que podría haber una 16

17 dimensión paralela donde INADDR_ANY es, digamos, 12 y mi código no funcionaría. Esta bien para mi: my_addr.sin_port = htons(0); // escoge un puerto libre al azar my_addr.sin_addr.s_addr = htonl(inaddr_any); // usa mi dirección IP Ahora somos tan portables que probablemente no lo creas. Sólo quería señalar eso, ya que en la mayoría del código que encontrarás no importa correr INADDR_ANY a través de htonl(). Además bind() devuelve -1 en error y setea errno con el valor de error. Otra cosa que resaltar cuando se llama a bind(): no ocupes números de puerto muy pequeños. Todos los puertos hasta 1024 están reservados (a menos que seas el súperusuario)! Puedes ocupar cualquier puerto sobre ése, hasta (si no están siendo ocupados por otro programa). Algunas veces, algunas, quieras reiniciar un programa servidor (server) y bind() falla, reclamando la dirección ya se esta usando. Qué significa eso? Bueno, un bit de un socket que estaba conectado anda dando vueltas por el kernel, y está ocupando el puerto. Puedes hacer dos cosas: esperar a que se desocupe (un minuto más o menos), o añadir un código a tu programa para que se pueda reutilizar el puerto, así: int yes=1; // lose the pesky "Address already in use" error message if (setsockopt(listener,sol_socket,so_reuseaddr,&yes,sizeof(int)) == -1) { perror("setsockopt"); exit(1); Una pequeña nota final sobre bind(): habrán veces en que no lo llamarás para nada. Si te esta conectando (connect() ) a una máquina remota y no te importa cual es tu puerto local (este es el caso con telnet cuando sólo importa el puerto remoto), tu simplemente puedes llamar a connect(), éste chequeará si el socket está disponible, y hará bind() a un puerto libre si es necesario connect() Hey, tú! Pretendamos por algunos minutos que eres una aplicación del telnet. Tu usuario te ordena (como en la película Tron ) que adquieras un descriptor de archivo de socket. Tú cumples y llamas a socket(). Luego, el usuario te dice que te conectes a en el puerto 23 (el estándar para telnet). Yow! Qué haces ahora? Por suerte para ti, programa, tu estas ahora en la sección connect() como conectar con un host remoto. Así que lee furiosamente. No hay tiempo que perder! La llamada a connect() es como sigue: #include <sys/types.h> #include <sys/socket.h> int connect(int sockfd, struct sockaddr *serv_addr, int addrlen); 17

18 sockfd es nuestro amistoso vecino descriptor de archivo de socket, como devuelve la llamada socket(), serv_addr es un STRUCT SOCKADDR que contiene la dirección IP y puerto destino, y addrlen puede setearse a sizeof (STRUCT SOCKADDR). No empieza a tener más sentido? Veamos un ejemplo: #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #define DEST_IP " " #define DEST_PORT 23 main() { int sockfd; struct sockaddr_in dest_addr; // contendrá la dirección de destino sockfd = socket(af_inet, SOCK_STREAM, 0); // do some error checking! dest_addr.sin_family = AF_INET; // host byte order dest_addr.sin_port = htons(dest_port); // short, network byte order dest_addr.sin_addr.s_addr = inet_addr(dest_ip); memset(&(dest_addr.sin_zero), \0, 8); // zero the rest of the struct // don t forget to error check the connect()! connect(sockfd, (struct sockaddr *)&dest_addr, sizeof(struct sockaddr));... Nuevamente, asegúrate de chequear el valor devuelto por connect() este devolverá un -1 en error y fijará la variable errno. Además, hay que decir que no llamamos a bind(). Básicamente, no nos preocupamos del número del puerto local; sólo nos interesa hacia donde vamos (el puerto remoto). El kernel escogerá el puerto local por nosotros, y el lugar donde nos conectamos recibirá automáticamente esta información de nosotros. No hay que preocuparse listen() - Alguien me llamaría por favor? Ok, tiempo para un cambio de lugar. Qué tal si no deseas conectarte a un host remoto. Digamos, sólo por decir, que deseas esperar una conexión entrante y manejarla de alguna manera. El consta de dos pasos: primero tu escuchas (listen() ), luego tu aceptas (accept() ). La llamada para escuchar es bastante simple, pero requiere una pequeña explicación: int listen(int sockfd, int backlog); sockfd es el descriptor de archivo de socket usual de la llamada al sistema socket(). backlog es el número de conexiones permitidas en la fila (como fila para el pan) entrante. Qué significa esto? Bueno, la conexiones entrantes van a esperar en esta fila hasta que las aceptes (accept() - mira abajo), y este es el límite de cuantas pueden estar en la fila. La mayoría de los sistemas limitan este número a 20; puedes salir del paso con 5 o

19 Nuevamente, como es usual, listen() devolverá un -1 en error y fijará la variable errno. Bueno, como seguramente imaginas, necesitamos llamar a bind() antes de listen() o el kernel nos tendrá escuchando en in puerto al azar. Entonces, si vas ha estar escuchando por llamadas entrantes, la secuencia de llamadas a sistema sería: socket(); bind(); listen(); /* accept() goes here */ Dejaré hasta aquí el código de ejemplo, ya que se explica casi solo. (El código de la sección accept() que sigue, es más completo). La parte realmente importante aquí es la llamada a accept() accept() - Gracias por llamar al puerto Prepárate la llamada accept() es un tanto rara! Lo que va a pasar es esto: alguien de bien, bien lejos tratará de connect() (conectarse) a tú máquina con un puerto que este escuchando (listen() ). La conexión del otro quedará en la fila esperando a ser aceptada (accept() ). Tu llamas a accept() y le dices que se comunique con la conexión pendiente. Éste te devolverá un descriptor de archivo de socket nuevecito para ocupar solamente en esta conexión! Así es, de pronto tienes dos descriptores de archivo de socket por el precio de uno! Él original todavía está escuchando en tu puerto y el nuevo está finalmente listo para send() (enviar) y recv() (recibir). Estamos listos! La llamada es como sigue: #include <sys/socket.h> int accept(int sockfd, void *addr, int *addrlen); sockfd es el descriptor de socket que escucha (listen() ). Suficientemente fácil. addr usualmente será un puntero a STRUCT SOCKADDR_IN. Aquí es donde la información de la conexión entrante irá (y con ella tu puedes determinar que host esta llamándote y de que puerto). addrl es una variable local entera que deberá tomar el valor de sizeof (STRUCT SOCKADDR_in) antes su dirección es pasada a accept(). accept no pondrá más bytes de lo que tiene en addr. Si pone menos, cambiará el valor de addrlen para reflejar el cambio. Adivina qué? accept() devolverá un 1 en error y fijará la variable errno. Apuesto a que no lo habías pensado. Como antes, esto es mucho que tragar de una sola mascada, así que aquí hay un código de ejemplo para tu estudio: #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #define MYPORT 3490 // the port users will be connecting to 19

20 #define BACKLOG 10 // how many pending connections queue will hold main() { int sockfd, new_fd; // escu7cha en sock_fd, nueva conexión en on new_fd struct sockaddr_in my_addr; // información de mi dirección struct sockaddr_in their_addr; // información de la dirección del otro int sin_size; sockfd = socket(af_inet, SOCK_STREAM, 0); // do some error checking! my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = htons(myport); // short, network byte order my_addr.sin_addr.s_addr = INADDR_ANY; // se llena con mi IP memset(&(my_addr.sin_zero), \0, 8); // zero the rest of the struct // don t forget your error checking for these calls: bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)); listen(sockfd, BACKLOG); sin_size = sizeof(struct sockaddr_in); new_fd = accept(sockfd, &their_addr, &sin_size);... Nuevamente, fíjate que usaremos el descriptor de socket new_fd para todas las llamadas send() y recv(). Si casi siempre solamente tienes una conexión, puedes close() (cerrar) el sockfd que está escuchando en orden de prevenir más llamadas al mismo puerto, si lo deseas send() y recv() - Háblame, baby! Estas dos funciones son para comunicarse sobre stream socket o datagram sockets conectados. Si desean usar datagran sockets desconectados, necesitarás ver la sección siguiente de sendto() y recvfrom(). La llamada send(): int send(int sockfd, const void *msg, int len, int flags); sockfd es el descriptor de socket donde deseas enviar data (ya sea el que es devuelto por socket() o el que obtienes con accept() ). msg es un puntero al dato que deseas enviar, y len sería el largo del dato en bytes. Sólo setea flags a 0. (Ve la página man de send() para más información concerniente a flags). Este puede ser un código de ejemplo: char *msg = "Beej was here!"; int len, bytes_sent;.. len = strlen(msg); 20

21 bytes_sent = send(sockfd, msg, len, 0);... send() devuelve el número de bytes que en realidad salieron puede ser menos que el número que le indicaste que enviara! Mira, algunas veces le ordenas que envié un monton de datos que simplemente no puede controlar. El lanzará la mayor cantidad de data que pueda, y confiará en que tú enviarás el resto después. Recuerda, que si el valor devuelto por send() no concuerda con el valor de len, depende de ti enviar el resto de la cadena. La buena noticia es esta: si el paquete es pequeño (menos de 1K) probablemente será enviado en un solo paso. Nuevamente, devolverá un 1 en error y fijará la variable errno con el número de error. La llamada recv() es similar en muchos aspectos: int recv(int sockfd, void *buf, int len, unsigned int flags); sockfd es el descriptor de socket del cual leeremos, buf es el buffer (espacio de memoria para almacenamiento temporal de datos) para leer la información, len es el largo máximo del buffer, y flags nuevamente puede tomar el valor 0. recv() devuelve el número de bytes que realmente se leen en el buffer, o -1 en error (con errno seteado, como corresponde). Espera! recv() puede devolver 0. Esto puede significar sólo una cosa: el lado remoto ha cerrado la conexión contigo! Recibir un valor 0 es como dejarte saber que esto ha ocurrido. Eso fue fácil, o no? Ahora puedes pasar data de ida y vuelta en stream sockets! Bien! Eres un programador de Redes Unix! 4.7. sendto() y recvfrom() Háblame, al estilo DGRAM! Esto está bacán. Estas diciendo. Pero donde me deja con los datagram sockets desconectados?. No hay problema, amigo. Tenemos la manera. Ya que los datagram sockets no están conectados a un host remoto, adivina que pieza de información debemos dar antes de enviar el paquete? Eso es correcto! La dirección de destino! He aquí la cuchara: int sendto(int sockfd, const void *msg, int len, unsigned int flags, const struct sockaddr *to, int tolen); Como puedes ver, esta llamada es básicamente igual a send() con la adición de dos piezas de información. to es un puntero a STRUCT SOCKADDR (el cual probablemente tendrás como STRUCT SOCKADDR_in y llamarás en el último minuto) que contiene la dirección IP y el puerto de destino. tolen puede ser simplemente seteado a sizeof (STRUCT SOCKADDR). 21

22 Igual que con send(), sendto() devuelve el número de bytes que se envían en realidad (el cual, nuevamente, puede ser menor que el número de bytes que habías indicado!), o -1 en error. Igualmente similares son recv() y recvfrom(). La forma de recvform() es: int recvfrom(int sockfd, void *buf, int len, unsigned int flags, struct sockaddr *from, int *fromlen); Nuevamente, esto es como recv() con la adición de una pareja de campos. from es puntero a un STRUCT SOCKADDR local que será llenado con la dirección IP y el puerto de la máquina de origen. fromlen es un puntero a un int (variable entera) local que debería ser iniciada en sizeof(struct SOCKADDR). Cuando la función vuelva, fromlen contendrá el largo de la dirección actualmente guardad en from. recvfrom() devuelve el número de bytes recibido, o -1 en error (con errno evaluado acordemente). Recuerda, si tu connect() un datagram socket, puedes simplemente usar send() y recv() para todas tus transacciones. El socket en si es aún un datagram socket y los paquetes aún usarán UDP, pero la interfaz de socket añadirá automáticamente el destino y fuente de información, por ti close() y shutdown() Sale de mi vista! Bien! Has estado send()ing (enviando) y recv()ing (recibiendo) datos durante todo el día, y te has cansado de ello. Entonces estás listo para cerrar la conexión de tu descriptor de socket. Esto es fácil. Puedes usar el descriptor Unix: la función close(). close(sockfd); Esto no permitirá que se escriba o lea en el socket. Cualquiera que intente leer o escribir remotamente en el socket recibirá un error. Sólo en el caso de que desees un poco más de control sobre como cerrar el socket, puedes usar la función shutdown(). Ésta te permite cortar la comunicación en cierta dirección, o en ambas (igual que close() ). Y es: int shutdown(int sockfd, int how); sockfd es el descriptor de archivo de socket que deseas apagar (shutdown), y how puede tomar los siguientes valores: 0 Recibir está deshabilitado. 1 Enviar está deshabilitado. 2 Enviar y Recibir están deshabilitados (como close() ) shutdown() devolverá 0 cuando sea exitoso, y -1 en error (con errno ajustado acordemente). 22

23 Si tratas de usar shutdown() en datagram sockets desconectados, simplemente hará que el socket esté indispuesto para las llamadas send() (enviar) y recv() (recibir) (recuerda que puedes usar esto si connect() tus datagram socket). Es importante notar que shutdown() en realidad no cierra el descriptor de archivo solamente cambia su disponibilidad. Para liberar un descriptor de socket, necesitas usar close(). Nada más getpeername() Quién eres? Esta función es muy fácil. Están fácil que casi no le doy una sección. Pero aquí está de todas maneras. Las función getpeername() te dirá quien esta conectado al final del stream socket. Es así: #include <sys/socket.h> int getpeername(int sockfd, struct sockaddr *addr, int *addrlen); sockfd es el descriptor del stream socket conectado, addr es el puntero a STRUCT SOCKADDR (o STRUCT SOCKADDR_in) que contendrá la información acerca del otro lado de la conexión, y addrlen es un puntero a un int, que debería ser inicializado a sizeof(struct SOCKADDR). La función devuelve -1en error y registra errno adecuadamente. Una vez que tienes su dirección, puedes usar inet_ntoa() o gethostbyaddr() para escribir u obtener más información. No, no puedes obtener su nombre de usuario. (Ok, ok. Si la otra computadora está corriendo un demonio ident, es posible. Esto, de todas maneras, no es parte de este documento. Chequea el RFC para más información) gethostname() Quién diablos soy? Incluso más fácil que getpeername() es la función gethostname(). Ésta devuelve el nombre de la computadora donde está corriendo tu programa. El nombre puede ser usado por gethostbyname(), abajo, para determinar la IP de tu máquina local. Qué puede ser más entretenido? Bueno, hay algunas cosas, pero no tienen que ver con la programación de sockets. Ok, así se hace: #include <unistd.h> int gethostname(char *hostname, size_t size); Los argumentos son simples: hostname es un puntero a un arreglo que contendrá el nombre del host que devolvió la función, y size es el largo en bytes del arreglo hostname. 23

24 La función devuelve 0 cuando se completa bien, y -1 en error, seteando errno como es usual DNS Tú dices whitehouse.gov, Yo digo En caso que no sepas que es DNS, quiere decir Servicio de Nombre de Dominio ( Domain Name Service, por sus siglas en inglés). De modo fácil, tu le das la dirección humanamente legible de un sitio, y él (DNS) te da la dirección IP (para que las uses con bind(), connect(), sendto(), o para lo que sea que la necesites). De esta manera, cuando alguien escriba: $ telnet whitehouse.gov telnet podrá encontrar la manera para conectarse a Pero, cómo funciona? Estarás usando la función gethostbyname(): #include <netdb.h> struct hostent *gethostbyname(const char *name); Como ves, devuelve un puntero a STRUCT HOSTENT. A continuación se muestra como es: struct hostent { char *h_name; char **h_aliases; int h_addrtype; int h_length; char **h_addr_list; ; #define h_addr h_addr_list[0] Siguiendo se muestra la descripción de los campos en struct hostent: h_name Nombre oficial de Host. h_aliases Un arreglo NULL de nombres alternativos para el host. h_addrtype El tipo de dirección que se devuelve; usualmente AF_INET. h_length El largo de la dirección en bytes. h_addr_list Un arreglo terminado en cero de las direcciones para el host. Las direcciones del host están en NBO. h_addr La primera dirección en h_addr_list. gethostbyname() devuelve un puntero al ocupado struct hostent, o NULL en error (Pero errno no toma valor, h_errno lo hace en su lugar. Ve herror(), más abajo). Pero cómo se usa esto? Algunas veces (como encontramos cuando leemos manual de computador), lanzar información al lector no es suficiente. Esta función es mucho más fácil de lo que parece. He aquí un programa de ejemplo 10 : 24

25 /* ** getip.c - a hostname lookup demo */ #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <netdb.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> int main(int argc, char *argv[]) { struct hostent *h; if (argc!= 2) { // error check the command line fprintf(stderr,"usage: getip address\n"); exit(1); if ((h=gethostbyname(argv[1])) == NULL) { // get the host info herror("gethostbyname"); exit(1); printf("host name : %s\n", h->h_name); printf("ip Address : %s\n", inet_ntoa(*((struct in_addr *)h->h_addr))); return 0; Con gethostbyname(), no puedes usar perror() para imprimir un mensaje de error (ya que errno no se usa). En vez, llama a herror(). Es bastante directo. Simplemente le pasas la cadena que contiene el nombre del host ( whitehouse.gov ) a gethostbyname(), y luego pesca la información que es devuelta por struct hostent. Lo único que podría resultar extraño es la escritura de la dirección IP. h->h_addr es un char*, pero inet_ntoa() requiere STRUCT IN_ADDR PASSED. Así que yo pongo h->h_addr en STRUCT IN_ADDR*, luego le hago deferencia para conseguir los datos. 25

26 5. Sistema Cliente-Servidor Este es un mundo Cliente-Servidor, baby. Casi todo lo que envuelve a la Red tiene que con procesos de cliente hablando con procesos de servidor, y vise-versa. Toma a telnet, por ejemplo. Cuando te conectas (tú cliente) con un host remoto al puerto 23, 26

27 #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <sys/wait.h> #include <signal.h> #define MYPORT 3490 // the port users will be connecting to #define BACKLOG 10 // how many pending connections queue will hold void sigchld_handler(int s) { wait(null); int main(void) { int sockfd, new_fd; // listen on sock_fd, new connection on new_fd STRUCT SOCKADDR_in my_addr; // my address information STRUCT SOCKADDR_in their_addr; // connector s address information int sin_size; struct sigaction sa; int yes=1; if ((sockfd = socket(af_inet, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); if (setsockopt(sockfd,sol_socket,so_reuseaddr,&yes,sizeof(int)) == -1) { perror("setsockopt"); exit(1); my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = htons(myport); // short, network byte order my_addr.sin_addr.s_addr = INADDR_ANY; // automatically fill with my IP bzero(&(my_addr.sin_zero), 8); // zero the rest of the struct if (bind(sockfd, (STRUCT SOCKADDR *)&my_addr, sizeof(struct SOCKADDR)) == -1) { perror("bind"); exit(1); if (listen(sockfd, BACKLOG) == -1) { perror("listen"); exit(1); sa.sa_handler = sigchld_handler; // reap all dead processes sigemptyset(&sa.sa_mask); 27

28 sa.sa_flags = SA_RESTART; if (sigaction(sigchld, &sa, NULL) == -1) { perror("sigaction"); exit(1); while(1) { // main accept() loop sin_size = sizeof(struct SOCKADDR_in); if ((new_fd = accept(sockfd, (STRUCT SOCKADDR *)&their_addr, &sin_size)) == -1) { perror("accept"); continue; printf("server: got connection from %s\n", inet_ntoa(their_addr.sin_addr)); if (!fork()) { // this is the child process close(sockfd); // child doesn t need the listener if (send(new_fd, "Hello, world!\n", 14, 0) == -1) perror("send"); close(new_fd); exit(0); close(new_fd); // parent doesn t need this return 0; En caso de que sean curiosos, yo tengo este código en una función main() bien grande para (por lo que a mi respecta) mantener la claridad de la sintaxis. Considérate libre de dividirla en funciones más pequeñas si te hace sentir mejor. (Además, todo esto de sigaction() puede ser nuevo para ti - lo cual está bien. El código presentado es responsable de recoger todos los procesos zombis que aparecen cuando el proceso hijo de fork() existe. Si haces un montón de procesos zombis y no los recojes, tu administrador de sistema se estremecerá.) Puedes obtener datos de este servidor usando el cliente mostrado en la próxima sección Un simple Cliente de flujo Esto es más fácil que el servidor. Todo lo que estos clientes hacen es conectarse con el host que especificas en la línea de comando, puerto Y recibe la cadena que envía el servidor. 28

29 La fuente del cliente 12 : /* ** client.c - a stream socket client demo */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <netdb.h> #include <sys/types.h> #include <netinet/in.h> #include <sys/socket.h> #define PORT 3490 // the port client will be connecting to #define MAXDATASIZE 100 // max number of bytes we can get at once int main(int argc, char *argv[]) { int sockfd, numbytes; char buf[maxdatasize]; struct hostent *he; STRUCT SOCKADDR_in their_addr; // connector s address information if (argc!= 2) { fprintf(stderr,"usage: client hostname\n"); exit(1); if ((he=gethostbyname(argv[1])) == NULL) { // get the host info perror("gethostbyname"); exit(1); if ((sockfd = socket(af_inet, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); their_addr.sin_family = AF_INET; // host byte order their_addr.sin_port = htons(port); // short, network byte order their_addr.sin_addr= *((struct in_addr *)he->h_addr); bzero(&(their_addr.sin_zero), 8); // zero the rest of the struct if (connect(sockfd, (STRUCT SOCKADDR *)&their_addr, sizeof(struct SOCKADDR)) == -1) { perror("connect"); exit(1); 29

30 if ((numbytes=recv(sockfd, buf, MAXDATASIZE, 0)) == -1) { perror("recv"); exit(1); buf[numbytes] = \0 ; printf("received: %s",buf); close(sockfd); return 0; Observa que si no corres en servidor antes que el cliente, connect() devolverá Connection refused. Muy útil Datagram Sockets Realmente no tengo mucho de que hablar aquí, por ende sólo presentaré algunos programas de ejemplo: talker.c y lintener.c. listener se estanca en una máquina esperando por un paquete entrante en el puerto talker envía un paquete a ese puerto, en la máquina especificada, que contiene lo que sea que el usuario tipee en la línea de comando. Este es el código de listener.c 13 : /* ** listener.c - a datagram sockets "server" demo */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #define MYPORT 4950 // the port users will be connecting to #define MAXBUFLEN 100 int main(void) { 30