Download
cs162b ipv4 socketing n.
Skip this Video
Loading SlideShow in 5 Seconds..
CS162B: IPv4 Socketing PowerPoint Presentation
Download Presentation
CS162B: IPv4 Socketing

CS162B: IPv4 Socketing

133 Vues Download Presentation
Télécharger la présentation

CS162B: IPv4 Socketing

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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