MCSE Lab, NTUT, TAIWAN 1
Mobile Computing & Software Engineering Lab
The Client Server Model and Software Design
Prof. Chuan-Ming LiuComputer Science and Information Engineering
National Taipei University of TechnologyTaipei, TAIWAN
NTUT, TAIWAN 2
Mobile Computing & Software Engineering Lab
IntroductionShort review for OSI modelPeer-to-peer communication
Client-server paradigm
NTUT, TAIWAN 3
Mobile Computing & Software Engineering Lab
LayeringDivide a task into pieces and then solve each piece independently (or nearly so).Establishing a well-defined interface between layers makes porting easier. Major Advantages:♦Code Reuse♦Extensibility
NTUT, TAIWAN 4
Mobile Computing & Software Engineering Lab
Layering Example: Federal ExpressLetter in envelope, address on outsideFedX guy adds addressing information, barcode.Local office drives to airport and delivers to hub.Sent via airplane to nearest city.Delivered to right officeDelivered to right person
NTUT, TAIWAN 5
Mobile Computing & Software Engineering Lab
FedX LayersLetter Addressed
Envelope
Letter Addressed Envelope
NTUT, TAIWAN 6
Mobile Computing & Software Engineering Lab
Layered Software SystemsNetwork software
Operating systems
Windowing systems
NTUT, TAIWAN 7
Mobile Computing & Software Engineering Lab
Unix is a Layered SystemApplications
Libraries
System Calls
Kernel
NTUT, TAIWAN 8
Mobile Computing & Software Engineering Lab
OSI Reference ModelThe International Standards Organization(ISO) proposal for the standardization of the various protocols used in computer networks (specifically those networks used to connect open systems) is called the Open Systems Interconnection Reference Model(1984), or simply the OSI model.
NTUT, TAIWAN 9
Mobile Computing & Software Engineering Lab
OSI Model Although the OSI model is a just a model (not a specification), it is generally regarded as the most complete model (as well it should be - nearly all of the popular network protocol suites in use today were developed before the OSI model was defined).
NTUT, TAIWAN 10
Mobile Computing & Software Engineering Lab
OSI <-> Network SoftwareAlthough this course is about network programming (and not about networking in general), an understanding of a complete network model is essential.
NTUT, TAIWAN 11
Mobile Computing & Software Engineering Lab
OSI 7 Layer Model:7 Application6 Presentation5 Session4 Transport3 Network2 Data-Link1 Physical
High level protocols
Low level protocols
NTUT, TAIWAN 12
Mobile Computing & Software Engineering Lab
Simplified Network ModelProcess
Transport
Network
Data Link
Process
Transport
Network
Data Link
Peer-to-peerProtocols
Interface Protocols
NTUT, TAIWAN 13
Mobile Computing & Software Engineering Lab
What’s a Protocol?An agreed upon convention for communication.
both endpoints need to understand the protocol.
Protocols must be formally defined and unambiguous! We will study lots of existing protocols and perhaps develop a few of our own.
NTUT, TAIWAN 14
Mobile Computing & Software Engineering Lab
Interface andPeer-to-peer
Protocols
Interface protocols describe the communication between layers on the same endpoint.Peer-to-peer protocols describe communication between peers at the same layer.
Process
Transport
Network
Data Link
Process
Transport
Network
Data Link
Interface Protocols
Peer-to-peerProtocols
NTUT, TAIWAN 15
Mobile Computing & Software Engineering Lab
Physical LayerCoordinates the functions required to transmit a bit stream over a physical mediumConcerns
Physical characteristics of interfaces and mediumRepresentation of bitsData rate (Transmission rate): bits/secSynchronization of bits
NTUT, TAIWAN 16
Mobile Computing & Software Engineering Lab
Physical LayerLine configuration
Point-to-pointMultipoint
Physical topologymesh, star, ring, or bus.Transmission modesimplex, half-duplex, or full-duplex
NTUT, TAIWAN 17
Mobile Computing & Software Engineering Lab
Physical Layer
NTUT, TAIWAN 18
Mobile Computing & Software Engineering Lab
Data Link LayerTransforms the physical layer to a reliable linkMakes the physical layer appear error free to upper layerResponsible for
FramingframesPhysical addressing (physical address)
Header defines the sender and/or receiverReceiver is the device connected to the next
NTUT, TAIWAN 19
Mobile Computing & Software Engineering Lab
Data Link LayerFlow controlError controlAccess controlMulti-home: computer having two or more NICs
NTUT, TAIWAN 20
Mobile Computing & Software Engineering Lab
Data Link Layer
NTUT, TAIWAN 21
Mobile Computing & Software Engineering Lab
Node-to-node Delivery
NTUT, TAIWAN 22
Mobile Computing & Software Engineering Lab
Network LayerResponsible for the source-to-destination delivery of a packetResponsibilities:
Logical addressing (IP address)Routing
NTUT, TAIWAN 23
Mobile Computing & Software Engineering Lab
Network Layer
NTUT, TAIWAN 24
Mobile Computing & Software Engineering Lab
End-to-end Delivery
NTUT, TAIWAN 25
Mobile Computing & Software Engineering Lab
Transport LayerSource-to-destination (end-to-end) delivery of the entire messageFunctions include:
Service-point addressing (port)Segmentation and reassemblyConnection controlconnectionless v.s. connection-orientedFlow controlError control
NTUT, TAIWAN 26
Mobile Computing & Software Engineering Lab
Transport Layer
NTUT, TAIWAN 27
Mobile Computing & Software Engineering Lab
Reliable end-to-end delivery of a message
NTUT, TAIWAN 28
Mobile Computing & Software Engineering Lab
Session LayerNetwork dialog controller
establishes, maintains, and synchronizes the interaction between communicating systems
Functions include:Dialog controlSynchronization (checkpoint)
NTUT, TAIWAN 29
Mobile Computing & Software Engineering Lab
Session Layer
NTUT, TAIWAN 30
Mobile Computing & Software Engineering Lab
Presentation LayerConcerned with the syntax an semantics of the information exchanged between two systemsResponsibilities include
TranslationEncryptionCompression
NTUT, TAIWAN 31
Mobile Computing & Software Engineering Lab
Presentation Layer
NTUT, TAIWAN 32
Mobile Computing & Software Engineering Lab
Application LayerInterface for users to access the networkServices include
Network virtual terminalFile transfer, access, and management (FTAM)Mail servicesDirectory services
NTUT, TAIWAN 33
Mobile Computing & Software Engineering Lab
Application Layer
NTUT, TAIWAN 34
Mobile Computing & Software Engineering Lab
Summary of Layers
NTUT, TAIWAN 35
Mobile Computing & Software Engineering Lab
TCP/IP Protocol SuitePhysical LayerData link LayerNetwork LayerTransport LayerApplication Layer
No specific protocol defined in physical and data link layers in TCP/IP
Correspond to OSI model
Last three layers in OSI
NTUT, TAIWAN 36
Mobile Computing & Software Engineering Lab
TCP/IP and OSI model
NTUT, TAIWAN 37
Mobile Computing & Software Engineering Lab
Network LayerInternetwork layerSupport
IP: Internetworking ProtocolARP: Address Resolution ProtocolRARP: Reverse Address Resolution ProtocolICMP: Internet Control Message ProtocolIGMP: Internet Group Message protocol
NTUT, TAIWAN 38
Mobile Computing & Software Engineering Lab
Internetworking Protocol (IP)Transmission mechanismDatagram: data unit to be sent in IPUnreliable and connectionlessBest-effort delivery serviceHost-to-host protocol
NTUT, TAIWAN 39
Mobile Computing & Software Engineering Lab
Transport LayerTCP and UDP: delivery of a message from a process to another process
User Datagram Protocol (UDP)Transmission Control Protocol (TCP)
NTUT, TAIWAN 40
Mobile Computing & Software Engineering Lab
TCP/IP Provides basic mechanisms used to transfer dataAllows a programmer to establish communication between applicationsProvides peer-to-peer communicationOne organizational method to use TCP/IP is the client-server paradigm
NTUT, TAIWAN 41
Mobile Computing & Software Engineering Lab
MotivationScenario: A user tries to start two programs on separate machines and have them communicate.
Program 1 startsSend message to its peer
Not running; RefuseNo response; exit
Program 2 starts
No connection can be set up
NTUT, TAIWAN 42
Mobile Computing & Software Engineering Lab
Client-Server ModelOne side in any pair of communicating application must start execution and wait for the other side to contact it.Since the client-server model places responsibility for rendezvous problem on application, TCP/IP does not need to provide mechanisms that automatically create a running program when a message arrives. Instead, a program must be waiting to accept communication before any request arrive.
NTUT, TAIWAN 43
Mobile Computing & Software Engineering Lab
Terminology and ConceptsClients and ServersPrivilege and ComplexityStandard v.s. Nonstandard Client SoftwareParameterization of ClientsConnectionless v.s. Connection-oriented ServersStateless v.s. Stateful ServersIdentifying a Client
NTUT, TAIWAN 44
Mobile Computing & Software Engineering Lab
Clients and ServersClient* An application that initiates peer-to-peer communication, e.g. web browser* Easier to build than servers* System privileges usually unnecessary ServerProgram that waits for incoming communication requests from a client
NTUT, TAIWAN 45
Mobile Computing & Software Engineering Lab
Privilege and ComplexityServer software often needs to access to objects that OS protectsServer can not rely on the usual OS checksince its privilege status allow to access any fileSecurity issues:
AuthenticationAuthorizationData SecurityPrivacyProtection
NTUT, TAIWAN 46
Mobile Computing & Software Engineering Lab
Privilege and ComplexityThe combination of special privileges and concurrent operation usually makes servers more difficult to design and implementation
NTUT, TAIWAN 47
Mobile Computing & Software Engineering Lab
Standard v.s. Nonstandard Client Software
Standard application servicesDefined by TCP/IPAssigned well-known, universally recognized protocol port
Non-standard application servicesAll other services which is not standardOr, locally-defined application services
NTUT, TAIWAN 48
Mobile Computing & Software Engineering Lab
Standard v.s. Nonstandard Client Software
Be aware of the standard when outside the local environmentStandard application service examples
Remote login, TELNET protocolE-mail client, SMTP or POP protocolFile transfer client, FTP protocolWeb browser, HTTP protocol
NTUT, TAIWAN 49
Mobile Computing & Software Engineering Lab
Standard v.s. Nonstandard Client Software
Non-standard application service examples
Music or video transferVoice communicationDistributed database access
NTUT, TAIWAN 50
Mobile Computing & Software Engineering Lab
Parameterization of ClientsGenerality for client softwaree.g. TELNET protocol using port numberFully parameterized clientapplication allows more input parameters
NTUT, TAIWAN 51
Mobile Computing & Software Engineering Lab
Parameterization of ClientsWhen designing client application, include parameters that allow the user to fully specify the destination machine and port number.
NTUT, TAIWAN 52
Mobile Computing & Software Engineering Lab
Connectionless v.s. Connection-Oriented Servers
TCP/IP provides two types of interaction between client and server:
Connectionless styleConnection-oriented style
The distinction is critical TCP
UDP
NTUT, TAIWAN 53
Mobile Computing & Software Engineering Lab
Connection-Oriented ServersTCP:* full reliability* verifying the data arrives* automatically retransmits segments* checksum over the data* data arriving in order* no duplicated packets* control the flow* reporting the underlying network problem to sender
NTUT, TAIWAN 54
Mobile Computing & Software Engineering Lab
Connectionless ServersUDP* no guarantees about reliable delivery* software contains code to detect and correct errors occurred by transmission* work well when the underlying network running well* aware of testing when using UDP
NTUT, TAIWAN 55
Mobile Computing & Software Engineering Lab
Connectionless v.s.Connection-Oriented Servers
TCP is preferable to UDPTCP simplifies programmingTCP relieves the programmers of responsibility for detecting and correcting errorsAdding reliability to UDP is a nontrivial work
NTUT, TAIWAN 56
Mobile Computing & Software Engineering Lab
Connectionless v.s.Connection-Oriented Servers
Application programs use UDP only ifApplication protocol specifies the UDP must be usedApplication protocol relies on hardware broadcast or multicast for deliveryOverhead for reliability is unnecessary
NTUT, TAIWAN 57
Mobile Computing & Software Engineering Lab
Stateless v.s. Stateful ServersState informationA server maintains about the status of ongoing interaction with clientsServers that do not keep any state information are called stateless servers; otherwise, called stateful servers.
NTUT, TAIWAN 58
Mobile Computing & Software Engineering Lab
Stateless v.s. Stateful ServersKeeping a small amount of information in a server can reduce the size of messages that the client and server exchange and allow the server to response quicklyThe point for statefulness is efficiencyThe motivation for statelessness lies in protocol reliability
NTUT, TAIWAN 59
Mobile Computing & Software Engineering Lab
Stateless File Server Example
disk
File server
client
Waits for client to access
stores or extracts data from the server
message
Operation (read or write)Name of the filePosition in the fileNumber of bytes to transferPresent only in write operation
opnamepossizedata
DescriptionItem
NTUT, TAIWAN 60
Mobile Computing & Software Engineering Lab
Stateful File Server Example
disk
File server
client
Waits for client to access
stores or extracts data from the server
reads
Operation (read or write)Name of the filePosition in the fileNumber of bytes to transferPresent only in write operation
opnamepossizedata
DescriptionItem
NTUT, TAIWAN 61
Mobile Computing & Software Engineering Lab
Stateful File Server Example
readreadwriteread
045638
125
test.program.ctcp.book.text
dept.budget.txtteris.txt
1234
Last Operation
Current Position
File NameClient
State information table
NTUT, TAIWAN 62
Mobile Computing & Software Engineering Lab
Identifying a ClientStateful servers use two general approaches to identify clients
EndpointsHandles
Endpoint identificationOperate automaticallyRelies on transport protocol, not application protocolEndpoint information may change
NTUT, TAIWAN 63
Mobile Computing & Software Engineering Lab
Identifying a Client
server
Transport protocol
IP address and port number
using the endpointinformation to look up the state table
NTUT, TAIWAN 64
Mobile Computing & Software Engineering Lab
Identifying a ClientHandles
remains constant across multiple transport connectionsA small integerIndependent of the underlying transport protocol
Change of transport connection does not invalidate handlesVisibility to the application – drawback
NTUT, TAIWAN 65
Mobile Computing & Software Engineering Lab
Identifying a ClientBack to stateful server
Can not retain state forever and application protocol requires terminationUsing endpoint identification can be confused by a crash
NTUT, TAIWAN 66
Mobile Computing & Software Engineering Lab
Identifying a Client
The point of state is efficientReducing the amount of data transferredIntuitive designDifficulty
Maintain the correctness when delay, duplication allowedState information may be incorrect when computer restarts
NTUT, TAIWAN 67
Mobile Computing & Software Engineering Lab
Identifying a Client
In general, in a real internet, where machines crash and reboot, and messages can be lost, delayed, duplicated, or delivered out of order, stateful designs lead to complex application protocols that are difficult to design , understand, and implement correctly.
NTUT, TAIWAN 68
Mobile Computing & Software Engineering Lab
Statelessness is a Protocol Issues
Statelessness or not centers on the application protocol more than implementationThe issue of statelessness focuses on whether the application protocol assumes the responsibility for reliable deliveryIdempotent – design issue for statelessness operation always has the same result
NTUT, TAIWAN 69
Mobile Computing & Software Engineering Lab
Servers as Clients
Programs do not fit exactly into the definition of client or server
Avoid circular dependencies among servers
Internetclient
time server
file server