CS 596: Client Server Programming
Client Algorithms Revisited

San Diego State University -- This page last updated March 30, 1995

Table of Contents

• Client Algorithms Revisited
  • Protocol State
  • POP Example
  • POP Example (continued)
  • Another POP example
  • Another Pop Example (continued)
  • Concurrency
  • Concurrency solutions
  • Multi Protocol Support
  • User Interfaces vs complexity
  • Graphical User Interfaces

Client Algorithms Revisited

Clients can be complex

Some factors that increase client complexity:

• Protocol State
• Multiple Protocol Support
• User Interface

Protocol State

Examples:

• POP
• SMTP

POP example:

USER joe

PASS secret

LIST

RETR 1

DELE 1

QUIT

POP Example

One could write the following (braindead) POP client:

if (SendSimpleCommand("USER joe") == OK)
if (SendSimpleCommand("PASS secret") == OK)
if (SendMultiCommand("LIST")  == OK)
.
.
.
if (SendSimpleCommand("QUIT") == OK)	
DoneReading();

POP Example (continued)

Problems with this example:

• Username and password are hardcoded
• Flow is hardcoded
• No error recovery

We need to gather information like username, password and actions to be performed from the user.

State has to be remembered between user interactions.

State determines which actions are allowed and which are not. (Menus)

Another POP example

Better braindead code:

SendSimpleCommand("USER", username);
SendSimpleCommand("PASS", password);
while (1) {	
    action = GetUserAction();	
    switch (action) {		
        case LIST:			
            SendMultiCommand("LIST");			
            ReadListResult();			
            DisplayList();  break;		
        case READ:			
            n = GetMessageIndex();			
            SendMultiCommand("RETR", n);			
            ReadMessage();			
            DisplayMessage();  break;
...

Another Pop Example (continued)

Problems with this:

• No error recovery
• Dependencies in flow

Concurrency

What about asynchrnous events?

• Checking for new mail
• Server connection timeout or other errors
• User moves mouse

Checking for new mail depends on other things:

• Username/Password
• Not currently doing other POP commands

Concurrency solutions

In a server we would just fork()

Clients rarely have that option

The only real solution:

select()

Control flow will generally be driven by user input.

In general, I/O events should start/stop/continue state machines.

Multi Protocol Support

A pop client also needs to send mail:

SMTP

Lookup people:

ph, finger, whois

Check if other people have mail:

finger

Support for these adds lots of complexity!

State machines for each...

User Interfaces vs complexity

Issues:

• Interactive vs. non-interactive
• User friendly
• Graphical vs text

Prompting

examples:

• /usr/ucb/Mail
• lynx

Features:

• Flow of control is known beforehand
• One thing at a time
• Easy to implement

Example Prompting User Interface

% Mail andrew@sdsu.edu
Subject: Test message
Gosh, you are tall
.
%
% chfn
Changing finger information for turtle on ender.
Default values are printed inside '[]'.
To accept the default, type <return>.
To have a blank entry, type the word 'none'.
Name [Andrew Scherpbier]:
Finger information unchanged.
%

Graphical User Interfaces

Once a client has to use a GUI, the structure of the client becomes complex.

Flow of control is defined by user actions

Multiple things can happen simultaneously

Different levels of asynchronicity.

In general:The more asynchronous actions are done, the more user friendly it is.

Example: mosaic vs netscape

Features that make netscape more usable:

• Multiple downloads
• Rendering of HTML while still downloading
• Scrolling while downloading

GUI complexity

What complexities does a GUI add?

• Screen painting
• Out of order flow of control