1 / 12

Unix Sockets

Unix Sockets. You may regard a socket as being a communication endpoint. For two processes to communicate, both must create their own socket. Communication is within a single machine or between two machines i.e. communication between unrelated processes.

tate-ball
Download Presentation

Unix Sockets

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. Unix Sockets • You may regard a socket as being a communication endpoint. • For two processes to communicate, both must create their own socket. • Communication is within a single machine or between two machines • i.e. communication between unrelated processes. • In either case, two sockets must be connected before they can transfer data. • There are two kinds of sockets: • Stream • Datagram

  2. Socket Communication Sending Process Socket } User Space } Kernel Space Connection Network Receiving Process

  3. Socket Addresses • A socket will have an address bound to it. • The address format depends on the communication domain. • There are three domains (or Address formats): • AF_UNIX • The Unix domain • AF_NS • XEROX Network Services (NS). • AF_INET • Internet sockets • TCP/IP Internet Addresses (Transmission Control Protocol, Internet Protocol) • Originated by DARPA

  4. Socket Addresses (cont.) • The UNIX address domain: • uses an ordinary file path name as an address • Example: • bind(s, “. / mySocket”) • connect(s, “. / mySocket”) • These are only valid with a single machine. • The Internet address domain: • TCP (for stream sockets) • UDP (for datagram sockets) • The address is a pair (machineID, port_#) • machineID is an IP address (e.g.: 129.97.114.12) • port_# is an integer uniquely identifying a port on that machine. • Issue: The problem of finding out the address of the other party • Within a single machine we use conventional file system mechanisms • For inter-machine communication we use symbolic names and name servers. • (a hierarchy of name servers actually).

  5. Socket Types • Stream Sockets • duplex • several naming schemes • connection oriented • no message boundaries • reliable and ordered. • Done by TCP in the Internet domain • Pipes in the Unix domain can be implemented in terms of 2 sockets. • Datagram sockets • duplex • several naming schemes • datagram-oriented • unreliable and unordered. • Raw Sockets • provide very low level access to protocols supporting the other types.

  6. Flowchart for Datagram Sockets socket bind sendto recvfrom close

  7. The Unix Datagram Socket Interface • This is a description of how process 1 would receive data from process 2. • somewhat simplified Process 1: sd = socket(addressDomain, SOCK_DGRAM); • addressDomain: Unix or IP • the call creates a socket descriptor • Same name space as the file descriptors. bind(sd, myAddress, length); • associates a name with the socket so that another process can communicate with it recvfrom(sd, buf, buflength, sourceAddress); • the address of the sender is returned in sourceAddress • this syscall will block if there is no message waiting.

  8. The Unix Datagram Socket Interface(cont.) Process 2: sd = socket(addressDomain, SOCK_DGRAM); sendto(sd, buf, buflength, targetAddress); • the send causes an address to be assigned so a reply can be addressed or the sender may explicitly bind before the sendto • targetAddress is the name supplied as myAddress by process 1 • sendto will block if the receiving socket has no space for the message. • There is a sample of working datagram code on the CS354 website.

  9. Flowcharts for Stream Sockets Passive Active socket socket bind bind connect listen send recv accept shutdown send recv close shutdown close

  10. Client-Server & Stream Sockets • The socket s2 is the “new” sd generated after the accept. • A fork will then be used to generate a child to handle the new socket. S Queue of connection requests S S 2 Process 2 S 3 Process 1 Socket Process 3

  11. The Unix Stream Socket Interface • This is a description of how process 1 would receive data from process 2. Process 1 (the passive process): sd = socket(addressDomain, SOCK_STREAM); bind(sd, myAddress); • associates a name with the socket so that another process can communicate with it listen(sd, backlog); • establish a queue of pending connections • tells the kernel it is ready to accept connections • backlog represents the max number of connections to queue nsd = accept(sd, sourceAddress); • accept blocks if there are no connection requests queued • the address of the sender is returned in sourceAddress • accept creates a new socket • processes may use read and write on a socket descriptor after the connection has been established recv(nsd, buf, buflength); • this syscall will block if there is no message waiting send(nsd, buf, bufLength); • send blocks if the receiver has no space

  12. The Unix Stream Socket Interface(cont.) Process 2 (the active process): sd = socket(addressDomain, SOCK_STREAM); connect(sd, targetAddress); • connect to an existing bound socket send(sd, buf, bufLength); recv(sd, buf, buflength); • the active process may also execute bind, but if not, sender’s socket is assigned an address when the send occurs shutdown(sd, whichDirOrBoth); • inhibits further sends, receives, or both close(sd); • releases the socket descriptor connect() and accept() block until the partner executes • the active and passive processes rendezvous when both a connect and a listen have occurred • There is a sample of working stream code on the CS354 website.

More Related