Network Applications Network Applications There are many network - PDF document

Network Applications Network Applications � There are many network applications – Network applications involve the cooperation Client Server Programming Client Server Programming of processes running on different hosts connected by a network � Applications may be “standard” or custom Srinidhi Varadarajan applications – Internet applications are typically defined in one or more Request for Comments (RFCs) • HTTP defined in RFC 1945 – May be standard, drafts, or informational Port Assignment Port Assignment Sample From /etc/services Sample From /etc/services � UDP and TCP ports are used to distinguish echo 7/tcp echo 7/udp between multiple applications on one host discard 9/tcp sink null � Standard numbering for “well-known port discard 9/udp sink null numbers” systat 11/tcp – Defined in RFC 1700 for “standard” Internet systat 11/tcp users applications daytime 13/tcp daytime 13/udp – Configured in various places specific to the netstat 15/tcp operating system and in the application itself qotd 17/tcp quote • Windows 95/98: \Windows\services qotd 17/udp quote • NT: Systemroot\System32\Drivers\Etc\services chargen 19/tcp ttytst source • UNIX: /etc/services chargen 19/udp ttytst source Service User Versus Service Provider Service User Versus Service Provider Concurrency at the Server Concurrency at the Server CLIENT SERVER � Many servers provide concurrent Request operation User Provider – Apparent concurrency using asynchronous socket I/O Response – True (program-level) concurrency using � Server runs awaiting multithreaded design requests and responds � Concurrency adds complexity! when requests are � When is concurrency justified? User User received – Need to simultaneously handle multiple � Client issues requests There may be multiple requests to server and accepts users of one provider – Need to increase performance response Application Layer 1

TELNET to Access Alternative Services TELNET to Access Alternative Services Example Standard Service: TELNET Example Standard Service: TELNET � TELNET is a standard application protocol � A TELNET client can be used to for remote login access alternative servers – Defines format of data sent by application – Simple text transfer -- so can access program to remote machine and by remote general text based services machine to the application – Defines character encoding – Typical TELNET clients can be – Defines special messages to control the configured to access different remote session ports � telnetd is server running on the remote – Of course, other clients are designed to host (at port 23) provide a better user interface � Client is the application program on the local host, e.g. CRT or other TELNET client Application-Level Model Application Level Model Peer Peer-to to-Peer Communication Model Peer Communication Model � Higher level model needed to implement � TCP/IP suite supports peer-to-peer networked applications communication � TCP and UDP require that a program be � Peer-to-peer communication is symmetric available to accept a connection request – Any node can initiate or terminate communication (TCP) or a datagram (UDP) – Communication can occur in either direction � Client-server model is widely used to � There are no implications of … provide a workable structure – When applications should interact – Meaning of data -- they’re just bytes Connection Request Client Server – Structure of a networked application Datagram Client Client-Server Model Server Model Clients Versus Servers Clients Versus Servers � Client initiates peer-to-peer communication (at TCP- or UDP-level) � Clients � Server waits for incoming request – Relatively simple (with respect to network communication) CLIENT SERVER – User-level programs that require no special privileges Request � Servers – More complex than servers due to Response performance and security requirements – Often require special system privileges – May run all the time or be started on-demand by operating system mechanisms, e.g. inetd in UNIX Application Layer 2

Privilege Privilege Client Parameterization Client Parameterization � Server often runs in a privileged mode, so � Parameterized clients lead to generality, must protect improper use of privileges by e.g. as in TELNET client being able to a client access other services � Parameters – Authentication : verify identity of the client – Authorization : verify permission to access – Destination host service • Host name: vtopus .cs.v t.edu – Data security and privacy : prevent • IP address: 128.173.40.24 unauthorized viewing or altering of data – Port number (not just default) – Protection : protect system resources from – Protocol- or application-specific information, misuse e.g. block size – Protocol itself, e.g. FTP, HTTP, or Gopher Universal Resource Locators (1) Universal Resource Locators (1) Universal Resource Locators (2) Universal Resource Locators (2) � URLs integrate many parameters ftp://ftp.cs.purdue.edu/pub/comer/ http://khg.redhat.com:8080/LDP/kernel.html protocol protocol host host (default FTP port) port resource resource Connectionless/Connection Connectionless/Connection-oriented (2) oriented (2) Connectionless/Connection Connectionless/Connection-oriented (1) oriented (1) � Connectionless servers � Connection-oriented servers – Data can be sent by clients immediately – Client must first connect to the server – Based on UDP (usually) -- no prior to any data transfer connection overhead, but no benefits – Based on TCP (usually) -- reliable at the • Data may not arrive expense of connection overhead • Data may be incorrect, although unlikely • Data arrives correctly • Duplicates may arrive, although unlikely • Data ordering is maintained • May arrive out of order, although unlikely • Data is not duplicated Application Layer 3

Connectionless/Connection Connectionless/Connection-oriented (3) oriented (3) Stateless/ Stateless/Stateful Stateful � Connectionless vs. connection-oriented � State information is any information about design issues ongoing interactions – Inherent reliability? � Stateful servers maintain state information – Reliability needed? � Stateless servers keep no state – Reliability is already very high (LAN vs. WAN)? information – Real-time operation gives no time for error � Examples -- stateful or stateless? correction (retransmission)? – Need for broadcast or multicast? – Finger? � Need to test in a variety of environments – TELNET? – HTTP? – Packet delay – FTP? – Packet loss – NFS? File Server Example File Server Example File Server Example: Stateless File Server Example: Stateless � Consider a file server that supports � Stateless version -- identify all information with each request four operations � Example – OPEN -- identify file and operation, e.g. – OPEN(/tmp/test.txt, “r”) read or write – READ(/tmp/test.txt, 0, 200) – READ -- identify file, location in file, – READ(/tmp/test.txt, 200, 200) number of bytes to read � Redundant information is provided with – WRITE -- identify file, location in file, subsequent requests number of bytes, data to write – Inefficient with respect to information transfer – CLOSE -- identify file – Server operation is simplified File Server Example: Stateful File Server Example: Stateful (2) (2) File Server Example: File Server Example: Stateful Stateful (1) (1) � What if there is a duplicate request? � Stateful version -- server provides handle – READ(32, 200) sent once, but received twice to access state at the server – Client and server lose synchronization -- server thinks that 400 bytes have been read, � File open client thinks it has read just 200 bytes – Request: OPEN(/tmp/test.txt, “r”) � Stateful servers are more complex than – Reply: OPEN(ok, 32) -- handle = 32 stateless servers since they must deal – State: 32: /tmp/test.txt, 0, read with synchronization � File read � State is implied by the protocol, not the – Request: READ(32, 200) implementation – Reply: READ(ok, data) – TCP is a stateful protocol – State: 32: /tmp/test.txt, 200, read – Synchronization required with byte numbers Application Layer 4