1 / 20

CS162B: IPv4 Socketing

CS162B: IPv4 Socketing. Jacob T. Chan. Socketing in the Real World. Most computer games are multiplayer in nature or have multiplayer components DotA , LoL , HoN , WoW and all those acronym-related games There are some useful applications that do use socketing too

noe
Download Presentation

CS162B: IPv4 Socketing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS162B: IPv4 Socketing Jacob T. Chan

  2. Socketing in the Real World • Most computer games are multiplayer in nature or have multiplayer components • DotA, LoL, HoN, WoW and all those acronym-related games • There are some useful applications that do use socketing too • Garena, Yahoo Messenger (if it still exists)

  3. Sockets • Header files • #include <sys/types.h> • #include <sys/socket.h> //VERY important • #include <arpa/inet..h> • #include <netdb.h> • Not required anymore to link any library

  4. Accessing Sockets • Sockets are just like files • They are identified using file descriptors, which are just pointers, which are just ints • Applies to both client and server • Sockets allow data to be exchanged between applications that may be running on different computers connected by a network • Both server and client need a socket! Otherwise, there will be no connection • The server must then bind its socket to a well-known address which the client can locate in case of connection to server

  5. int socket(int domain, int type, int protocol) • Domain specifies communication domain • Value is usually AF_INET (since we will use IPv4) • Type can either be two values: SOCK_STREAM or SOCK_DGRAM • Difference: connectivity. TCP or UDP • Illustration: mailbox vs direct • There are other values available, which you can research on your own, but these two are popular • Protocol is the protocol to be used in the socket • Value is usually 0 because we use SOCK_STREAM and SOCK_DGRAM

  6. Setting Up Connections • Client Side: structsockaddr_in destination; structhostent *host; destination.sin_family = AF_INET; destination.sin_port = htons(DESTINATION_PORT); host = gethostbyname(hostname); //hostname = IP address or host name • Returns NULL on error destination.sin_addr.s_addr = inet_addr(inet_ntoa(*((structin_addr *)host->h_addr))); • inet_addrreturns -1 on error

  7. Setting Up Connections • Server Side: structsockaddr_inmy_addr; my_addr.sin_family= AF_INET; my_addr.sin_port= htons(LISTENING_PORT); • Setting LISTENING_PORT to 0 means that any port can be chosen by the system, but the dilemma is that how is the client supposed to know which port is being used? • LISTENING_PORT for server is equal to DESTINATION_PORT of client my_addr.sin_addr.s_addr= INADDR_ANY; • INADDR_ANY means that your local IP address will be used

  8. So far… • Server and client are just prepared to connect to one another • What we did so far is to provide necessary information for establishing a connection to the network • Client can now make connection requests • Server can now listen to requests

  9. Client: int connect(intsockfd, conststructsockaddr *addr, socklen_taddrlen) • Returns -1 on eror • If successful, client connects to the server and can now read() and write(), or send() and recv() data • Read-write is the standard with the file descriptors • Send-recv system calls are for socket-specific I/O system calls • They provide additional socket-specific functionality • NOTE: Ports less than 1024 are RESERVED, so make sure that you choose from ports 1024 – 65536 to be safe

  10. Server: int bind(intsockfd, conststructsockaddr *addr, socklen_taddrlen) • Fills in information regarding IP address and port number • Informs system that the port will be used by socket • Error will occur if another program is already using the port • Returns -1 on errror • sockfd is open file descriptor corresponding to the socket • sockaddr holds address information • addrlen specifies the size of the structure address

  11. Server: int listen(intsockfd, int backlog) • Marks stream socket referred to by file descriptor as passive • Passive sockets ALLOW incoming connections • Backlog specifies the number of connection requests that can be placed on queue if server is currently busy • Usually 10-20 • Tells socket to begin listening for connections • Returns -1 on error

  12. Accepting Connections structsockaddr_inclientAddress; int size = sizeofclientAddress; intclientfd; clientfd= accept(sockfd, (structsockaddr*)&clientAddress, &size); • accept() will take the first connection in the queue prepared by listen() and create a dedicated socket for that connection. If the queue is empty, accept() will BLOCK until a connection is present, NOT listen() • If the server still has to do something while waiting for connections, you will need to use concurrent processes or use the select() or poll() function, which is not covered here. • accept() is the one that blocks, NOT listen()! • The clientAddress will be filled ONLY during accept() is called and after there is a listen() called before it

  13. Sending Data int send (intfd, char *buffer, int size, int flag) • fd is your file descriptor (for server, you need the client’s file descriptor, and for client, you need the socket file descriptor) • buffer is a pointer to whatever you need to send • Arrays are pointers, so you can make it work even if you declared buffer[N} • size is the buffer size in BYTES • flag is the set flags, which is usually 0 (to note of no flags) • Returns -1 on error

  14. Sending Data • BUT, send() returns the number of bytes sent out • Which can be less than the number of bytes you told it to send • This case usually happens if your data is too big, so you send the rest later • Solution: loop send() • But no need to do this if you don’t really need or want to

  15. Receiving Data intrecv(intfd, char *buffer, int size, int flag) • fdis your file descriptor (for server, you need the client’s file descriptor, and for client, you need the socket file descriptor) • buffer is the character array that recv() will write to • size is the true size of the buffer in BYTES • flag is the flag set, which is usually 0 (to indicate no flags) • Returns -1 on error

  16. Receiving Data • BUT, calling recv() can receive contents of more than 1 call of send() • Which implies that most programsthat send() variable-length data must be red separately • Solution: send a fixed-length data before actually sending X: sprintf(limiter, "%08d\0", strlen(x)); send(sockfd, limiter, 8, 0); send(sockfd, x, strlen(x), 0); printf("Sent message: %s (%d chars)\n", x, strlen(x)-1);

  17. Closing everything • Close all socket descriptors • So that the socket can be reused by other programs • Otherwise, not cleaning will result into the unreusability of the socket • Rebooting is the only way to restore that socket! • Client close(sockfd); • Server close(sockfd); close(clientfd);

  18. Lab 11: server.c and client.c • Create two programs server.c and client.c that does the following: • The server should accept ANY number of connections from multiple clients. • When a client connects to the server, the server should be able to spawn a new process that handles a connection with this client • The server, once connected to a client, should be able to continue to listen for new incoming requests • As for the client side, it should display the line “input string to search: “ on the console. Each time a query string is provided, the client sends this to the server • The server then searches for the word in the text file. If the phrase is found, the server should return the lines with that phrase to the client • Otherwise, return a “NOT FOUND: <string _to_be_searched>” • The client will continue looping until the phrase “/EXIT” is encountered • Guaranteed that in the text file, there is no string “/EXIT”

  19. Lab 11: server.c and client.c • Create two programs server.c and client.c that does the following: • Upon exiting, the client should inform the server that it is disconnecting. But that does not mean server should already exit. • You do this so that it will tell the process on the server side to stop processing that client. • The server will run a file, which will be its basis of searching • The server and client need not to run on the same machine, though they need to be connected to the same IPv4 network. • Server and client will run as follows: ./server <port> <file> ./client <server_ip> <port> • NOTE: This works like a remote search bar.

  20. Lab 11: server.c and client.c • Of course, errors should still be handled (like errors on wrong arguments, wrong IP address format, and other connection function-related errors) • Legalities • Certificate of Authorship, along with your server.c and client.c programs • Filename: CS162B_Lab11_<Section>_<Surname>_<ID_Number>.tar • Deadline: Next weekmidnight • Tuesday for Section A • Thursday for Section B

More Related