TDC561 Network Programming - PowerPoint PPT Presentation

Loading...

PPT – TDC561 Network Programming PowerPoint presentation | free to download - id: 3bdf4a-YWQ4M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

TDC561 Network Programming

Description:

Network Programming Week 1: Course Introduction; Socket Application Programming Interface; Examples: C/C++ UNIX/Linux APIs Camelia Zlatea, PhD Email: czlatea_at_cs ... – PowerPoint PPT presentation

Number of Views:127
Avg rating:3.0/5.0
Slides: 76
Provided by: condorDe8
Learn more at: http://condor.depaul.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: TDC561 Network Programming


1
TDC561 Network Programming
Week 1 Course Introduction Socket Application
Programming Interface Examples C/C UNIX/Linux
APIs
  • Camelia Zlatea, PhD
  • Email czlatea_at_cs.depaul.edu

2
TDC561 Course Summary
  • Topics
  • TCP/IP protocol suite
  • Socket programming TCP and UDP sockets Reliable
    UDP Communication
  • Client-Server Models
  • Socket options
  • Threads concurrency locking
  • Select calls
  • Non-Blocking I/O
  • IOCTL
  • ICMP
  • Broadcast/Multicast
  • Programming aspects related to network performance

3
Objectives
  • Upon completion of this course, students will
  • have a good understanding of the TCP/UDP network
    programming interface
  • be able to develop client-server network
    applications on the Internet, based on UNIX/Linux
  • know how to apply methods for measuring and
    tuning the performance of network applications

4
Prerequisites
  • TDC 463, CSC 309
  • C/C will be used to illustrate the concepts
    presented in the lecture material and for the
    implementation of the programming assignments and
    the project.
  • Basic understanding of UNIX / Linux operating
    system and programming environment

5
Texts
  • Douglas Comer, David Stevens, Internetworking
    with TCP/IP Client-Server Programming, Volume
    III (BSD Unix and ANSI C), 2nd edition, 1996
    (ISBN 0-13-260969-X)
  • W. Richard Stevens, Network Programming
    Networking API Sockets and XTI, Volume 1, 2nd
    edition, 1997 (ISBN 0-13-490012-X)

6
Other References
  • L.Peterson, B. Davie. Computer Networks A System
    Approach. Morgan Kaufman, 2000. (ISBN
    1-55860-514-2)
  • W. Stallings. Local and Metropolitan Area
    Networks. Prentice Hall,2000. (ISBN 0130129390)
  • W. Richard Stevens, Network Programming
    Inter-process Communication, Volume 2, 2nd
    edition, 1999 (ISBN 0-13-081081-9)
  • Robertazzi, Thomas G., Computer Networks and
    Systems - Queuing Theory and Performance
    Evaluation, second edition, Springer Verlag, 1994

7
Class Work and Grading
8
Programming Environment
  • All students will get an account on
    hawk.depaul.edu server (running HP-UX).
  • Optional, you can use Linux system
  • Project submissions via COL ( dlweb.cti.depaul.edu
    )
  • use Submit Assignments link
  • Grading will be done on HP-UX or Linux
  • An experimental report is required for each
    programming project
  • The the report should include the program design
    description and the test cases and test
    scenarios for the application.

9
TDC561 Network Programming
  • Instructor Camelia Zlatea, PhD
  • Office Hours T 445-545PM 900-930PM
  • Where Rm. 429, ext. x26149 (during office hours)
  • Email czlatea_at_cs.depaul.edu
  • Web http//condor.depaul.edu/czlatea/TDC561/
    ()
  • Note
  • In addition, course materials will be available
    from dlweb.cti.depaul.edu

10
Class Communication
  • COL (dlweb.cti.depaul.edu) will be used primarily
    for
  • Links to course materials/assignments
  • Grades
  • Announcements
  • Email/Communication
  • Newsgroup
  • Asking questions
  • Send me an email at czlatea_at_cs.depaul.edu
    OR
  • Use dlweb.cti.depaul.edu and post questions to
    class forum
  • Anybody may reply (including your classmates)
  • Everyone benefits from common issues

11
Socket APIs C/C UNIX/Linux Systems Calls (APIs)
12
References
  • Douglas Comer, David Stevens, Internetworking
    with TCP/IP Client-Server Programming, Volume
    III (BSD Unix and ANSI C), 2nd edition, 1996
    (ISBN 0-13-260969-X)
  • Chap. 3,4,5
  • W. Richard Stevens, Network Programming
    Networking API Sockets and XTI, Volume 1, 2nd
    edition, 1998 (ISBN 0-13-490012-X)
  • Chap. 1,2,3,4
  • John Shapley Gray, Interprocess Communications in
    UNIX -- The Nooks and Crannies Prentice Hall PTR,
    NJ, 1998
  • Chap. 10

13
Client Server Communication
  • The transport protocols TCP and UDP were designed
    to enable communication between network
    applications
  • Internet host can have several servers running.
  • usually has only one physical link to the rest
    of the world
  • When packets arrive how does the host identify
    which packets should go to which server?
  • Ports
  • ports are used as logical connections between
    network applications
  • 16 bit number (65536 possible ports)
  • demultiplexing key
  • identify the application/process to receive the
    packet
  • TCP connection
  • source IP address and source port number
  • destination IP address and destination port
    number
  • the combination IP Address Port Number pair is
    called a Socket

14
Client Server Communication
Port
IP
Network Host
Network
122.34.45.67
Network Host
123.45.67.89
SOCKETS
122.34.45.67 65534
123.45.67.8980
15
Client Server Communication
Port
HTTP Server with three active connections
(sockets).
IP Network
Active
Active
Active
Listening
IP Host/ Server
The HTTP server listens for future connections.
16
Ports
  • Port - A 16-bit number that identifies the
    application process that receives an incoming
    message.
  • Port numbers divided into three categories
  • Well Known Ports 0-1023
  • Registered Ports 1024-49151 by the IANA
    (Internet Assigned Numbers Authority), and
    represent second tier common ports (socks (1080),
    WINS (1512), kermit (1649), https (443))
  • Dynamic/Private Ports 49152-65535 ephemeral
    ports, available for temporary client usage
  • Reserved ports or well-known ports (0 to 1023)
  • Standard ports for well-known applications.
  • See /etc/services file on any UNIX machine for
    listing of services on reserved ports.
  • 1 TCP Port Service Multiplexer
  • 20 File Transfer Protocol (FTP) Data
  • 21 FTP Control
  • 23 Telnet
  • 25 Simple Mail Transfer (SMT)
  • 43 Who Is
  • 69 Trivial File Transfer Protocol (TFTP)
  • 80 HTTP

17
Associations
  • A socket address is the triplet
  • protocol, local-IP, local-port
  • example,
  • tcp, 130.245.1.44, 23
  • An association is the 5-tuple that completely
    specifies the two end-points that comprise a
    connection
  • protocol, local-IP, local-port, remote-IP,
    remote-port
  • example
  • tcp, 130.245.1.44, 23, 130.245.1.45, 1024

18
Socket Domain Families
  • There are several significant socket domain
    families
  • Internet Domain Sockets (AF_INET)
  • implemented via IP addresses and port numbers
  • Unix Domain Sockets (AF_UNIX)
  • implemented via filenames (similar to IPC named
    pipe)

19
Creating a Socket
  • include ltsys/types.hgt
  • include ltsys/socket.hgt
  • int socket(int domain, int type, int protocol)
  • domain is one of the Protocol Families (AF_INET,
    AF_UNIX, etc.)
  • type defines the communication protocol
    semantics, usually defines either
  • SOCK_STREAM connection-oriented stream (TCP)
  • SOCK_DGRAM connectionless, unreliable (UDP)
  • protocol specifies a particular protocol, just
    set this to 0 to accept the default

20
The Socket Structure
  • INET Address
  • struct in_addr
  • in_addr_t s_addr / 32-bit IPv4 address /
  • INET Socket
  • Struct sockaddr_in
  • uint8_t sin_len / length of structure (16) /
  • sa_family_t sin_family / AF_INET /
  • in_port_t sin_port / 16-bit TCP/UDP port
    number /
  • struct in_addr sin_addr / 32-bit IPv4 address
    /
  • char sin_zero8 / unused /

21
Setup for an Internet Domain Socket
  • struct sockaddr_in
  • sa_family_t sin_family
  • unsigned short int sin_port
  • struct in_addr sin_addr
  • unsigned char pad...
  • sin_family is set to Address Family AF_INET
  • sin_port is set to the port number you want to
    bind to
  • sin_addr is set to the IP address of the machine
    you are binding to (struct in_addr is a wrapper
    struct for an unsigned long)
  • ignore padding

22
Stream Socket Transaction (TCP Connection)
Server
socket()
Client
bind()
socket()
listen()
3-way handshake
connect()
accept()
write()
data
read()
data
write()
read()
EOF
close()
read()
close()
23
  • Connection-oriented socket connections
  • Client-Server view

24
Server Side Socket Details
25
Client Side Socket Details
26
Reading From and Writing To Stream Sockets
  • Sockets, are inter-process-communication
    mechanism, similar with files
  • low level IO
  • read() system call
  • write() system call
  • higher level IO
  • int recv(int socket, char buf, int len, int
    flags)
  • blocks on read
  • returns 0 when other connection has terminated
  • int send(int socket, char buf, int len, int
    flags)
  • returns the number of bytes actually sent
  • where flags may be one of
  • MSG_DONTROUTE (dont route out of localnet)
  • MSG_OOB (out of band data (causes interruption))
  • MSG_PEEK (examine, but dont remove from stream)

27
Closing a Socket Session
  • int close(int socket)
  • closes read/write IO, closes socket file
    descriptor
  • int shutdown( int socketfd, int mode)
  • where mode is
  • 0 no more receives allowed r
  • 1 no more sends are allowed w
  • 2 disables both receives and sends (but doesnt
    close the socket, use close() for that) rw

28
Byte Ordering
  • Different computer architectures use different
    byte ordering to represent/store multi-byte
    values (such as 16-bit/32-bit integers)
  • 16 bit integer

Little-Endian (Intel)
Big-Endian (RISC-Sparc)
Low Byte
High Byte
Address A
High Byte
Low Byte
Address A1
29
Byte Order and Networking
  • Suppose a Big Endian machine sends a 16 bit
    integer with the value 2
  • A Little Endian machine will understand the
    number as 512
  • How do two machines with different byte-orders
    communicate?
  • Using network byte-order
  • Network byte-order big-endian order

0000000000000010
0000001000000000
30
Network Byte Order
  • Conversion of application-level data is left up
    to the presentation layer.
  • Lower level layers communicate using a fixed byte
    order called network byte order for all control
    data.
  • TCP/IP mandates that big-endian byte ordering be
    used for transmitting protocol information
  • All values stored in a sockaddr_in must be in
    network byte order.
  • sin_port a TCP/IP port number.
  • sin_addr an IP address.

31
Network Byte Order Functions
  • Several functions are provided to allow
    conversion between host and network byte
    ordering,
  • Conversion macros (ltnetinet/in.hgt)
  • to translate 32-bit numbers (i.e. IP addresses)
  • unsigned long htonl(unsigned long hostlong)
  • unsigned long ntohl(unsigned long netlong)
  • to translate 16-bit numbers (i.e. Port numbers)
  • unsigned short htons(unsigned short hostshort)
  • unsigned short ntohs(unsigned short netshort)

32
TCP Sockets Programming Summary
  • Creating a passive mode (server) socket.
  • Establishing an application-level connection.
  • send/receive data.
  • Terminating a connection.

33
Creating a TCP socket
  • int socket(int family,int type,int proto)
  • int mysockfd
  • mysockfd socket( AF_INET, SOCK_STREAM,
  • 0)
  • if (mysockfdlt0) / ERROR /

34
Binding to well known address
  • int mysockfd
  • int err
  • struct sockaddr_in myaddr
  • mysockfd socket(AF_INET,SOCK_STREAM,0)
  • myaddr.sin_family AF_INET
  • myaddr.sin_port htons( 80 )
  • myaddr.sin_addr htonl( INADDR_ANY )
  • err bind(mysockfd, (sockaddr ) myaddr,
    sizeof(myaddr))

35
Bind What Port Number?
  • Clients typically dont care what port they are
    assigned.
  • When you call bind you can tell it to assign you
    any available port
  • myaddr.port htons(0)

36
Bind - What IP address ?
  • How can you find out what your IP address is so
    you can tell bind() ?
  • There is no realistic way for you to know the
    right IP address to give bind() - what if the
    computer has multiple network interfaces?
  • Specify the IP address as INADDR_ANY, this tells
    the OS to handle the IP address specification.

37
Converting Between IP Address formats
  • From ASCII to numeric
  • 130.245.1.44 ? 32-bit network byte ordered
    value
  • inet_aton() with IPv4
  • inet_pton() with IPv4 and IPv6
  • From numeric to ASCII
  • 32-bit value ? 130.245.1.44
  • inet_ntoa() with IPv4
  • inet_ntop() with IPv4 and IPv6
  • Note inet_addr() obsolete
  • cannot handle broadcast address 255.255.255.255
    (0xFFFFFFFF)

38
IPv4 Address Conversion
  • int inet_aton( char , struct in_addr )
  • Convert ASCII dotted-decimal IP address to
    network byte order 32 bit value. Returns 1 on
    success, 0 on failure.
  • char inet_ntoa(struct in_addr)
  • Convert network byte ordered value to ASCII
    dotted-decimal (a string).

39
Establishing a passive mode TCP socket
  • Passive mode
  • Address already determined.
  • Tell the kernel to accept incoming connection
    requests directed at the socket address.
  • 3-way handshake
  • Tell the kernel to queue incoming connections for
    us.

40
listen()
  • int listen( int mysockfd, int backlog)
  • mysockfd is the TCP socket (already bound to an
    address)
  • backlog is the number of incoming connections the
    kernel should be able to keep track of (queue for
    us).
  • listen() returns -1 on error (otherwise 0).

41
Accepting an incoming connection
  • Once we call listen(), the O.S. will queue
    incoming connections
  • Handles the 3-way handshake
  • Queues up multiple connections.
  • When our application is ready to handle a new
    connection, we need to ask the O.S. for the next
    connection.

42
accept()
  • int accept( int mysockfd,
  • struct sockaddr cliaddr,
  • socklen_t addrlen)
  • mysockfd is the passive mode TCP socket.
  • cliaddr is a pointer to allocated space.
  • addrlen is a value-result argument
  • must be set to the size of cliaddr
  • on return, will be set to be the number of used
    bytes in cliaddr.
  • accept() return value
  • accept() returns a new socket descriptor
    (positive integer) or -1 on error.
  • After accept returns a new socket descriptor, I/O
    can be done using the read() and write() system
    calls.

43
Terminating a TCP connection
  • Either end of the connection can call the close()
    system call.
  • If the other end has closed the connection, and
    there is no buffered data, reading from a TCP
    socket returns 0 to indicate EOF.

44
Client Code
  • TCP clients can call connect() which
  • takes care of establishing an endpoint address
    for the client socket.
  • dont need to call bind first, the O.S. will
    take care of assigning the local endpoint address
    (TCP port number, IP address).
  • Attempts to establish a connection to the
    specified server.
  • 3-way handshake

45
connect()
  • int connect( int sockfd,
  • const struct sockaddr server,
  • socklen_t addrlen)
  • sockfd is an already created TCP socket.
  • server contains the address of the server (IP
    Address and TCP port number)
  • connect() returns 0 if OK, -1 on error

46
Reading from a TCP socket
  • int read( int fd, char buf, int max)
  • By default read() will block until data is
    available.
  • reading from a TCP socket may return less than
    max bytes (whatever is available).

47
Writing to a TCP socket
  • int write( int fd, char buf, int num)
  • write might not be able to write all num bytes
    (on a nonblocking socket).
  • Other functions (API)
  • readn(), writen() and readline() - see man pages
    definitions.

48
Example from R. Stevens text
Client Server communication
Server
Client
Network
Machine B
Machine A
  • Web browser and server
  • FTP client and server
  • Telnet client and server

49
Example Daytime Server/Client
Application protocol (end-to-end logical
connection)
Daytime client
Daytime server
Socket API
Socket API
TCP protocol (end-to-end logical connection)
TCP
TCP
IP protocol (physical connection )
IP
IP
MAC-level protocol (physical connection )
MAC driver
MAC driver
Actual data flow
MAC media access control
Network
50
Daytime client
  • include "unp.h"
  • int main(int argc, char argv)
  • int sockfd, n
  • char recvlineMAXLINE 1
  • struct sockaddr_in servaddr
  • if( argc ! 2 )err_quit(usage gettime ltIP
    addressgt)
  • / Create a TCP socket /
  • if ( (sockfd socket(AF_INET, SOCK_STREAM,
    0)) lt 0)
  • err_sys("socket error")
  • / Specify servers IP address and port
    /
  • bzero(servaddr, sizeof(servaddr))
  • servaddr.sin_family AF_INET
  • servaddr.sin_port htons(13) / daytime
    server port /
  • Connects to a daytime server
  • Retrieves the current date and time
  • gettime 130.245.1.44
  • Thu Sept 05 155000 2002

51
Daytime client
  • / Connect to the server /
  • if (connect(sockfd, (SA ) servaddr,
    sizeof(servaddr)) lt 0)
  • err_sys("connect error")
  • / Read the date/time from socket /
  • while ( (n read(sockfd, recvline,
    MAXLINE)) gt 0)
  • recvlinen 0 / null
    terminate /
  • printf(s, recvline)
  • if (n lt 0) err_sys("read error")
  • close(sockfd)

52
Simplifying error-handling R. Stevens
  • int Socket(int family, int type, int protocol)
  • int n
  • if ( (n socket(family, type, protocol)) lt
    0)
  • err_sys("socket error")
  • return n

53
Daytime Server
  • include "unp.h"
  • include lttime.hgt
  • int main(int argc, char argv)
  • int listenfd, connfd
  • struct sockaddr_in servaddr
  • char buffMAXLINE
  • time_t ticks
  • / Create a TCP socket /
  • listenfd Socket(AF_INET, SOCK_STREAM,
    0)
  • / Initialize servers address and
    well-known port /
  • bzero(servaddr, sizeof(servaddr))
  • servaddr.sin_family AF_INET
  • servaddr.sin_addr.s_addr
    htonl(INADDR_ANY)
  • servaddr.sin_port htons(13)
    / daytime server /
  • Waits for requests from Client
  • Accepts client connections
  • Send the current time
  • Terminates connection and goes back waiting for
    more connections.

54
Daytime Server
  • / Convert socket to a listening socket
    /
  • Listen(listenfd, LISTENQ)
  • for ( )
  • / Wait for client connections
    and accept them /
  • connfd Accept(listenfd, (SA )
    NULL, NULL)
  • / Retrieve system time /
  • ticks time(NULL)
  • snprintf(buff, sizeof(buff),
    ".24s\r\n", ctime(ticks))
  • / Write to socket /
  • Write(connfd, buff,
    strlen(buff))
  • / Close the connection /
  • Close(connfd)

55
Background SlidesTCP/IP Protocol Suite - Terms
and Concepts
56
TCP/IP Summary
  • IP network layer protocol
  • unreliable datagram delivery between hosts.
  • UDP transport layer protocol - provides fast /
    unreliable datagram service. Pros Less overhead
    fast and efficient
  • minimal datagram delivery service between
    processes.
  • unreliable, since there is no acknowledgement of
    receipt, there is no way to know to resend a lost
    packet
  • no built-in order of delivery, random delivery
  • connectionless a connection exists only long
    enough to deliver a single packet
  • checksum to guarantee integrity of packet data
  • TCP transport layer protocol . Cons Lots of
    overhead
  • connection-oriented, full-duplex, reliable,
    byte-stream delivery service between processes.
  • guaranteed delivery of packets in order of
    transmission by offering acknowledgement and
    retransmission
  • sequenced delivery to the application layer, by
    adding a sequence number to every packet.
  • checksum to guarantee integrity of packet data

57
End-to-End (Transport) Protocols
  • Underlying best-effort network
  • drops messages
  • re-orders messages
  • delivers duplicate copies of a given message
  • limits messages to some finite size
  • delivers messages after an arbitrarily long delay
  • Common end-to-end services
  • guarantee message delivery
  • deliver messages in the same order they are sent
  • deliver at most one copy of each message
  • support arbitrarily large messages
  • support synchronization
  • allow the receiver to apply flow control to the
    sender
  • support multiple application processes on each
    host

58
UDP
59
UDP
  • Simple Demultiplexor
  • Unreliable and unordered datagram service
  • Adds multiplexing
  • No flow control
  • Endpoints identified by ports
  • servers have well-known ports
  • see /etc/services on Unix
  • Optional checksum
  • pseudo header udp header data
  • UDP Packet Format

60
TCP
  • Reliable Byte-Stream
  • Connection-oriented
  • Byte-stream
  • sending process writes some number of bytes
  • TCP breaks into segments and sends via IP
  • receiving process reads some number of bytes
  • Full duplex
  • Flow control keep sender from overrunning
    receiver
  • Congestion control keep sender from overrunning
    network

61
TCP
  • Connection-oriented protocol
  • logical connection created between two
    communicating processes
  • connection is managed at TCP protocol layer
  • provides reliable and sequential delivery of data
  • receiver acknowledgements sender that data has
    arrived safely
  • sender resends data that has not been
    acknowledged
  • packets contain sequence numbers so they may be
    ordered
  • Bi-directional byte stream
  • both sender and receiver write and read bytes
  • acknowledgements identify received bytes
  • buffers hold data until there is a sent
  • multiple bytes are packaged into a segment when
    sent

62
TCP End-to-End Issues
  • Based on sliding window protocol used at data
    link
  • level, but the situation is very different.
  • Potentially connects many different hosts
  • need explicit connection establishment and
    termination
  • Potentially different RTT (Round Trip Time)
  • need adaptive timeout mechanism
  • Potentially long delay in network
  • need to be prepared for arrival of very old
    packets
  • Potentially different capacity at destination
  • need to accommodate different amounts of
    buffering
  • Potentially different network capacity
  • need to be prepared for network congestion

63
TCP Segment Format
  • Every TCP segment includes a Sequence Number that
    refers to the first byte of data included in the
    segment.
  • Every TCP segment includes an Acknowledgement
    Number that indicates the byte number of the next
    data that is expected to be received.
  • All bytes up through this number have already
    been received.
  • Control flags
  • URG urgent data included.
  • ACK this segment is (among other things) an
    acknowledgement.
  • RST error - abort the session.
  • SYN synchronize Sequence Numbers (setup)
  • FIN polite connection termination.
  • Window
  • Every ACK includes a Window field that tells the
    sender how many bytes it can send before the
    receiver buffer will be in overflow

64
TCP Segment Format
0
16
31
Source Port Number
Destination Port Number
Sequence Number
Acknowledgement
0
Flags
Window
Hdr Len
Checksum
Urgent Pointer
Options/Padding
Data
65
TCP Connection Establishment and Termination
  • When a client requests a connection it sends a
    SYN segment (a special TCP segment) to the
    server port.
  • SYN stands for synchronize. The SYN message
    includes the clients SN.
  • SN is Sequence Number.

66
TCP Connection Creation
Client Active Participant
Server Passive Participant
SYN SNX
1
SYN SNY ACKX1
2
ACKY1
3
67
TCP 3-Way Handshake
  • A client starts by sending a SYN segment with the
    following information
  • Clients SN (generated pseudo-randomly) X
  • Maximum Receive Window for client.
  • Only TCP headers
  • When a waiting server sees a new connection
    request, the server sends back a SYN segment
    with
  • Servers SN (generated pseudo-randomly) Y
  • Acknowledgement Number is Client SN1 X1
  • Maximum Receive Window for server.
  • Only TCP headers
  • When the Servers SYN is received, the client
    sends back an ACK with
  • Acknowledgement Number is Servers SN1 Y1
  • Why 3-way?

1
2
3
68
TCP Data and ACK
  • Once the connection is established, data can be
    sent.
  • Each data segment includes a sequence number
    identifying the first byte in the segment.
  • Each segment (data or empty) includes an
    acknowledgement number indicating what data has
    been received.

69
TCP
  • Reliable Byte-Stream
  • Connection-oriented
  • Byte-stream
  • sending process writes some number of bytes
  • TCP breaks into segments and sends via IP
  • receiving process reads some number of bytes
  • Full duplex
  • Flow control keep sender from overrunning
    receiver
  • Congestion control keep sender from overrunning
    network

70
TCP Buffering
  • The TCP layer doesnt know when the application
    will ask for any received data.
  • TCP buffers incoming data so its ready when we
    ask for it.
  • Client and server allocate buffers to hold
    incoming and outgoing data
  • The TCP layer does this.
  • Client and server announce with every ACK how
    much buffer space remains (the Window field in a
    TCP segment).
  • Most TCP implementations will accept out-of-order
    segments (if there is room in the buffer).
  • Once the missing segments arrive, a single ACK
    can be sent for the whole thing.

71
TCP Buffering
  • Send Buffers
  • The application gives the TCP layer some data to
    send.
  • The data is put in a send buffer, where it stays
    until the data is ACKd.
  • The TCP layer wont accept data from the
    application unless (or until) there is buffer
    space.
  • ACK
  • A receiver doesnt have to ACK every segment (it
    can ACK many segments with a single ACK segment).
  • Each ACK can also contain outgoing data
    (piggybacking).
  • If a sender doesnt get an ACK after some time
    limit it resends the data.

72
Termination
  • The TCP layer can send a RST segment that
    terminates a connection if something is wrong.
  • Usually the application tells TCP to terminate
    the connection gracefully with a FIN segment.
  • FIN
  • Either end of the connection can initiate
    termination.
  • A FIN is sent, which means the application is
    done sending data.
  • The FIN is ACKd.
  • The other end must now send a FIN.
  • That FIN must be ACKd.

73
TCP Connection Termination
App2
App1
FIN SNX
1
ACKX1
2
...
FIN SNY
3
ACKY1
4
74
Stream Sockets
  • Connection-Based, i.e., socket addresses
    established before sending messages between C/S
  • Address Domain AF_UNIX (UNIX pathname) or
    AF_INET (hostport)
  • Virtual Circuit i.e., Data Transmitted
    sequentially in a reliable and non-duplicated
    manner
  • Default Protocol Interface is TCP
  • Checks order, sequence, duplicates
  • No boundaries are imposed on data (its a stream
    of bytes)
  • Slower than UDP
  • Requires more program overhead

75
Datagram Sockets
  • Connectionless sockets, i.e., C/S addresses are
    passed along with each message sent from one
    process to another
  • Peer-to-Peer Communication
  • Provides an interface to the UDP datagram
    services
  • Handles network transmission as independent
    packets
  • Provides no guarantees, although it does include
    a checksum
  • Does not detect duplicates
  • Does not determine sequence
  • ie information can be lost, wrong order or
    duplicated
About PowerShow.com