1. Introduction to Network Programming and Client-Server Design

2. 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)

3. 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)

4. 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

5. 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

6. 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)

7. 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?

8. 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

9. 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

10. 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?

11. 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

12. Locating the service How does the client know where the server is located? –IP –Port number How is this simplified for the user?

13. Efficiency What techniques can be employed to get the fastest response? –Client UDP vs TCP concurrency –Server Iterative Concurrent

14. 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

15. 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