Download Introduction to Network Programming and Client

Introduction to
Network Programming
and
Client-Server Design
Why Distribute?
• Sharing data needs are obvious
• Sharing other resources is nearly as obvious
– hardware resources
– software resources
• Centralize data (resource)
– single copy
• Security
– control access
• Eliminate Synchronization Awkwardness
• (and more)
Clients
• Want to see a quick accurate response
• Want the illusion that no one else is
receiving service or affecting their ability to
obtain the service
• But their design is not as simple (more to
come)
Servers
• Appear to have a lot of responsibility
• Must quickly and reliably serve many
potential clients
• Must not make clients work around other
clients
• Managing many simultaneous clients
appears difficult
• Not as bad as it looks
Fundamental Client-Server Issues
• Timing
– One must start before the other and wait or
initial synchronization will always fail
• Privilege and Complexity
– Authentication verifying the identity of the client
– Authorization determining if a given client is permitted to
use the service
– Data Security data must not be revealed or compromised
– Privacy protecting info about an individual
– Protection guaranteeing network application will not abuse
system resources
• Standard and non-standard software
– be aware of standard apps (mail, ftp, etc)
• Connection-oriented vs Connectionless
– TCP vs. UDP
– Use TCP until more experienced
• Stateless vs. Stateful
– opposite of last semester
•
•
•
•
•
Deadlock
Data Transparency
Efficiency
Data Sharing
Platforms (OS)
Stateful vs Stateless Servers
• Where do we store the “state” of the
interaction?
– Shared between client and server
– Solely in client
– Solely in server
• Types of info in the “state”
– client logged in
– which file was the client reading?
– have all client options been specified?
Problems
•
•
•
•
Messages from client delayed or lost
Duplicate requests, messages out of order
(TCP handles these, not UDP)
Client has state and server has state and one
of the two reboot. Now there exists an
inconsistent state for pair
• Protocols must handle it !
• Idempotent operations always produce same
results (somewhat) and define a stateless
servers
Servers can be clients
• Applications which provide services can in
turn need services from others
• Circular dependencies can exist
– A relies on B and B relies on A
• If state is in the client, then the server can
have state info when acting as a client
• May have a need for commit/rollback
features
Stream versus Datagram
• How is information framed?
• How is the responsibility for framing shared
between the client and server?
• What happens if UDP loses frames?
Data Transparency
• What if two platforms represent data in
different formats?
– Twos complement vs ones complement
– big endian (leftmost/lower byte most
significant)
– varying length strings
– floating point
• n x n problem
Locating the service
• How does the client know where the server
is located?
– IP
– Port number
• How is this simplified for the user?
Efficiency
• What techniques can be employed to get the
fastest response?
– Client
• UDP vs TCP
• concurrency
– Server
• Iterative
• Concurrent
Data Sharing
• Many clients are accessing the data
managed by server(s).
• Who goes first?
• How are the timing problems resolved?
• What are race conditions and how are they
avoided?
• A fundamental issue of concurrent
processing
Platforms/OS
•
•
•
•
What types of approaches are there?
Low-level versus high-level strategies
Various APIs
How does the OS impact approach
– especially for concurrency