Demo - Postal Code Client

This demo is a client for a postal code lookup protocol. The protocol is very simple and for now the server is assumed to be predefined. The postal code lookup server is not covered in this section, only the client.

The purpose of the postal code lookup is to provide the city and state for a given postal code (Zip code for American readers). The sample data included with the server contains data for US postal codes. US postal codes (called zip codes) are 5 digits and numeric.

The server for this demo is covered later.

6.5.1 Postal Code Protocol

The postal code protocol is very simple. It consists of only two commands:

· Lookup <post code 1> <post code 2> ...

· Quit

A sample conversation looks like this:

Server: 204 Post Code Server Ready.

Client: lookup 16412

Server: 37642: CHURCH HILL, TN Server: 77056: HOUSTON, TX Server: .

Client: quit Server: 201-Paka!

Server: 201 4 requests processed.

The server responds with a greeting when the client connects. Greetings and replies to commands typically contain a 3 digit number specifying status. This will be covered more in detail in later

Indy in Depth 41

(C) 2003 Atozed Computer Software Ltd.

This book is registered to Constantinos Pitsakis

sections.

After the greeting the server is ready to accept commands from the client. If a Lookup command is received the server will respond with a list of post codes followed by the associated location. The response is terminated by a . on a line by itself. The client can issue as many commands as it likes until the client specifies it is ready to disconnect by issuing the Quit comand.

6.5.2 Code Explanation

The postal code client consists of two buttons, a listbox, and a memo. One button is used to clear results, and the other is used to take values from the memo and request information from the server.

The results are displayed in the listbox.

In a normal application the user would have options to specify the host, port and possibly even proxy configuration information. However for the purposes of demonstration the host has been set at design time to 127.0.0.1 (Self) and the port to 6000.

When the user clicks on the Lookup button the following event will be executed:

procedure TformMain.butnLookupClick(Sender: TObject);

var

i: integer;

begin

butnLookup.Enabled := true; try lboxResults.Clear;

with Client do begin Connect; try

// Read the welcome message GetResponse(204);

lboxResults.Items.AddStrings(LastCmdResult.Text);

lboxResults.Items.Add('');

finally butnLookup.Enabled := True; end;

end;

The Indy methods used here will be explained only briefly as they are covered in more detail in other sections.

The code starts by disabling the button so that the user cannot try to perform another lookup while one is in progress. You might think that this is not possible because button click events are processed using messages. However this demo has a TIdAntiFreeze which calls Application.ProcessMessages and allows paint events as well as other click events to occur. Because of this you need to take extra care to protect the state of the user's actions.

Using a TIdTCPClient (Client) dropped on the form at design time the demo then connects to the server and waits for the greeting. GetResponse reads the response and returns the response as the result. In this case the result is discarded, but GetResult is instructed to verify that the numeric response is 204. If the server responds with a different code an exception will be raised. A server may respond with a different code if it is too busy, under maintenance, etc.

For each postal code that the user enters, the demo sends a lookup command to the server and expects a 200 reply, followed by a response. SendCmd sends the command, then calls GetResponse

Introduction to Clients 42

passing the second parameter (in this case 200). If SendCmd succeeds, the demo calls Capture which reads a response until a . is found on a line by itself. Since the demo is only submitting one postal code per command, it expects only one line for a reply, or none if the postal code is invalid.

Finally the demo sends the Quit command, waits for a 201 reply which acknowledges that the server agrees and disconnects. It is always a good idea to use a Quit command so that both sides know a disconnect is about to occur.

Section

VII

UDP

UDP 44

7 UDP

7.1 Overview

UDP (User Datagram Protocol) is for datagrams and is connectionless. UDP allows lightweight packets to be sent to a host without having to first connect to another host. UDP packets are not guaranteed to arrive at their destination, and may not arrive in the same order they were sent. When sending a UDP packet, it is sent in one block. Therefore, you must not exceed the maximum packet size specified by your TCP/IP stack.

Because of these factors, many people assume UDP is nearly useless. This is not the case. Many streaming protocols, such as Real Audio, use UDP.

Note: The term "streaming" can be easily confused with "stream" connection, which is TCP. When you see these terms, you need to determine the context in which they are used to determine their proper meaning.

7.2 Reliability

The reliability of UDP packets depends on the reliability and the saturation of the network. UDP packets are often used on applications that run on a LAN, as the LAN is very reliable. UDP packets across the Internet are generally reliable as well and can be used with error correction or more often interpolation. Interpolation is when an educated guess is made about missing data based on packets received before and / or after. Delivery however cannot be guaranteed on any network - so do not assume your data will always arrive at your destination.

Because UDP does not have delivery confirmation, its not guaranteed to arrive. If you send a UDP packet to another host, you have no way of knowing if it actually arrived at its destination. The stack will not - and cannot - determine this, and thus will not provide an error if the packet did not reach its destination. If you need this information, you need to send some sort of return notification back from the remote host.

UDP is like sending someone a message on a traditional pager. You know you sent it, but you do not know if they received it. The pager may not exist, may be out of the service area, may not be on, or may not be functioning. In addition, the pager network may lose the page. Unless the person pages you back, you do not know if your message was delivered. In addition, if you send multiple pages, it is possible for them to arrive out of order.

Another real world example that is similar to UDP, is the postal service. You can send it, but you cannot guarantee it will be delivered to the destination. It may be lost anywhere along the way, or delivered, but mutilated before delivery.

7.3 Broadcasts

UDP has a unique ability that is often the feature that makes it desirable. This ability is the ability to be broadcasted. Broadcasting means that a single message can be sent, but can be received by many recipients. This is not the same as multicasting. Multicasting is a subscription model where recipients subscribe and are added to a distribution list. With broadcasting, a message is sent across the network and anyone listening can receive without the need to subscribe.

Multicasting is similar to a newspaper delivery. Only people who subscribe to the newspaper receive it. Broadcasting is similar to a radio signal. Anyone with a receiver can tune to a specific radio station

Indy in Depth 45

(C) 2003 Atozed Computer Software Ltd.

This book is registered to Constantinos Pitsakis

and receive it. The user does not need to notify the radio station that they wish to listen.

A specific broadcast IP can be calculated based on the IP of the sender and a subnet mask. However in most cases it is easiest to use 255.255.255.255 which will broadcast as far as possible.

Nearly all routers however are programmed to filter out broadcast messages by default. This means that messages will not pass across bridges or external routes, and the broadcast will be limited to the local LAN network.