Networking in DrScheme

1. Introduction
This tutorial covers networking in DrScheme/MzScheme via the TCP (Transmission
Control Protocol) protocol. TCP offers the possibility to transfer data between
programs running on different computers.
We begin by describing Peer-to-Peer connections and continue with the Client-
Server Model.

2. Conventions
The following conventions are used throughout this document.
For description of procedure headers, brackets ([ ]) are used to indicate optional
parameters.
Sometimes only relevant parameters are listed for a procedure. For a full
parameter listing, refer to the MzScheme Language Manual on the PLT homepage
or in the DrScheme Help Desk.
Italics are used when introducing new terms.
Constant width is used for code examples, procedures, symbols and other things
that appear in code.

3. The Basics
To establish a connection between two computers via TCP, one computer need to
act as a client, and the other needs to act as a server. The idea is that the client
connects to the server to establish a connection. To be able to do this, the client
needs to know the IP- address of the server, and which port the server is listening
on. The IP-address can be in the form of a hostname or URL, like “ida.liu.se”, or in
the form of a (currently) 32-bit number written in dotted form like 130.236.177.26.
A port can be any number between 1 and 65535, however some of the lower
numbered ports are reserved. For example, 20-21 is for FTP access, 22 for SSH, 23
for TELNET, 25 for SMTP and 80 for HTTP. To avoid problems, use a port number
above 1000.
For example, if we want a browser to view
the web page at http://www.ida.liu.se, the
URL would be www.ida.liu.se, and as it is a
http connection it would use port 80.

4. Peer-to-Peer Connectivity Client Server

To establish a connection in DrScheme we

need three procedures: tcp-listen, tcp-accept and tcp-connect. The first two
are used by server to open a port and wait for and accept connections, and the
last one is used the client to connect to the server.
(tcp-listen port [max-allow-wait reuse?]) returns listener object. This
represents a listener at the specified port on the local machine, which listens for
connections. max-allow-wait is the maximum number of connections waiting for
acceptance. reuse? violates the TCP protocol, and reuses port even if it has not
been properly closed . This might cause problems, but during development it can
be convenient.
(tcp­accept tcp­listener) accepts a connection to tcp­listener (returned by
tcp­listen). Two values are returned, an outport and an inport. These should
should be bound with let­values, set!­values or equivalent. If no connection
attempt is waiting, tcp­accept will block until a client attempts to connect.
(tcp­connect hostname port) attempts to connect to hostname at port. For
this to work, the computer representing hostname need to have listener listening
on port, and then accept the connection attempt with tcp­accept. The returned
values are the same as in the tcp-connect case, an outport and an inport.
If a computer acting as a client want to connect to a computer acting as a server,
we would need something like the following for the server:
(define *listener* (tcp­listen 9000))
(set!­values (*outport* *inport*) (tcp­accept *listener*))
And the client would then do the following to connect:
(set!­values (*outport* *inport*) (tcp­connect “localhost” 9000))
The hostname “localhost” represents the local machine, which is also represented
by the IP-address 127.0.0.1 . This means that in the above case the client and
server is running on the same computer.
We can now send and receive data through the out- and inports respectively, and
from now on it is actually irrelevant who connected to whom. Both sides send and
receive data in the same way.
Sending data can be done with procedures such as write or display, and reading
can be done with procedures such as read or read­line. For detailed descriptions
of the port operations, refer to the manual.
For example, any side could send a message with:
(display “Hello, World” *outport*)
and the other side would receive it with:
(read *inport*)
When we are ready, either side can close the connection with
(tcp-abandon-port *outport*)
(tcp-abandon-port *inport*)
When one side has closed the connection the other side will only receive the
symbol <eof>, end of file, when reading from its inport. This should be checked
with (eof­object? obj), which returns #t for this special value.

5. Peer-to-Peer Example
See p2pchat.scm

6. The Client-Server Model

Two handle connections between more than Server
two computers we need a different model. In
the Client-Server Model one machine acts as a
server which accepts connections from a
number of clients, and usually provides some
services to them. For example, a chat server
lets clients connect to it and then provides
some functionality for text communication. This
functionality could be different chat channels,
private messages, channel messages, global Clients
messages, different status of users and so on.
The associated chat client would then connect
to the chat server and let the user use the servers functionality in a useful way,
like with a well designed GUI.
The main different between the Peer-to-Peer model and the Server-Client model is
that the latter model needs to handle several connections at once. This can be
done with the following loop:
1) The server listens for connections on a certain port.
2) When a client connects, the server accepts the connection and opens up a new
inport and outport. The server then spawns a new thread which listens for
incoming data on the inport (this thread also decides what to do with the
incoming data) and adds the outport to a shared data structure so that each client
can be sent data later. The server then returns to 1) and waits for more clients.
Almost all other of the server's functionality, as well the communication
functionality for the client can be done in the same way as in the Peer-to-Peer
model.

7. Client-Server Example
A simple chat server is implemented in server-example.scm, and a even simpler
chat client is implemented in client-example.scm. To get started, examine those
files and you should have enough knowledge to do your own network applications.

8. Comments?
Typos, corrections, questions and/or other comments can be sent to Joakim
Hellsten, joahe@ida.liu.se.

Last Updated: 2004-10-27