Download Chapter 14 Communication

Chapter 14 Communication
14.1
Sockets for networking
Robbins gives an introduction to network communication in Section 12.3, and introduces
sockets in Section 12.4.
Santifaller Chapter 1 covers protocols, including OSI.
Solomon introduces networking in NT in Chapter One.
Internet domain
Gray introduces communications basics such as IP addresses, domains, families, and types of
socket, in Section 10.2.
Haviland Section 10.3.1 covers IP addresses, with Section 10.3.2 on ports.
Rusling Section 10.1 gives an overview of TCP/IP. Section 10.2 deals with TCP/IP in Linux.
Section 10.5 covers the IP layer in Linux.
Santifaller Chapter 2 introduces TCP/IP, with Chapters 3 and 4 going into it in great detail.
Satchell Chapter 2 introduces TCP/IP. Chapter 3 introduces the ISO 7 layer model, and
shows where TCP/IP fits into this. Chapter 7 introduces the IPv4 packet format. Table 7.1
lists all of the IPv4 functions implemented in the kernel, by name; this is followed by a
brief resume of where and how they are implemented. The chapter then goes on to
consider the building of an IP header, including fragmentation, and how incoming packets are
handled by IP.
Satchell Chapter 8 deals with UDP, including sending and receiving packets. Likewise
Chapter 9 deals with TCP, including sending and receiving packets, packet format, and
internal TCP functions.
Network interface
Bowman describes the overall architecture of the Linux network interface in Section 2.4.
14.2
IP sockets
Gray Program 10.4 is an example of using gethostbyname() to obtain host information, while
Program 10.5 uses getservbyname() to obtain information about a server. Program 10.6 is a
connection oriented server, while Program 10.7 is the corresponding client. Program 10.10 is
a connectionless server, with the corresponding client in Program 10.11.
Satchell Chapter 5 introduces the socket API, including all of the major socket functions.
The various options that may be set are covered here too.
Rusling Section 10.4 covers INET sockets; creating (10.4.1), binding (10.4.2), connecting
(10.4.3), listening (10.4.4), and accepting (10.4.5).
© John O’Gorman 2000
Gray introduces the concept of non destructive reads, or peeking at data, in Section 10.7.
Program 10.14 is the server side of this, while Program 10.15 is the corresponding client.
Gray introduces out of band, or priority, messages in Section 10.8. Program 10.16 is the
server side of his example, while Program 10.17 is the corresponding client.
14.3
Network interrupt handler
Rusling Section 8.6 covers network devices in Linux.
14.4
Extended transport interface
Robbins Section 12.5 introduces the Transport Layer Interface (forerunner to XTI).
Santifaller has a section on XTI in Chapter 13, including a programming example.
14.5
Remote procedure call
Gray introduces RPC in Section 9.1, as does Robbins in Section 14.1.
Corbin, J. (1991) The art of distributed applications. Springer, NY, is the classic on this
subject.
14.6
RPC programming
Identification
Robbins Section 14.6 deals with binding and naming of services. This includes the official
Sun numbers, and rpcinfo. Section 14.7 deals with failures.
Santifaller introduces ONC protocols in Chapter 9.
Interface specification
Gray covers the RPC language, XDR, and rpcgen, in Section 9.4. Appendix C contains RPC
language syntax diagrams. Figure 9.6 gives a sample interface definition. Program 9.3 is a
sample client program, illustrating the use of clnt_create(), clnt_pcreateerror(), and
clnt_call(). Program 9.4 is the corresponding server program.
In Section 9.6 Gray uses the –a option with rpcgen to generate skeleton (template) code for
the client and server. The two functions clnt_perror() and clnt_destroy() are also
introduced here.
Section 9.7 of Gray goes on to cover encoding and decoding arbitrary data types, typedefs,
and the discriminated union. This section concludes with an extended example, which lists a
directory tree on a remote machine. Program 9.6 contains the code for the client, and
Program 9.7 that for the server.
Gray deals with the use of broadcast to search for an RPC server, using rpc_broadcast(), in
Section 9.8. Program 9.8 sends such a broadcast request.
Robbins deals with converting a local function call to RPC, using rpcgen, in Section 14.2.
Programs 14.1 and 14.2 are examples of simple local client and server programs. Program
14.4 is the specification (.x) file. Program 14.5 is the client skeleton produced by rpcgen.
© John O’Gorman 2000
Program 14.6 is the finished client. Program 14.7 is the skeleton server produced by rpcgen.
Program 14.8 is the full server.
Robbins Section 14.4 deals with server state, and idempotent requests. Section 14.5
develops a remote idempotent file service. Program 14.15 is the specification file for a
stateless file server. Program 14.16 is the server function. Program 14.17 is the client
main().
Robbins Section 14.9 deals with threads and RPC, and introduces a multi-threaded version
of the file server from Section 14.5. Section 14.10 is an exercise to further develop the
stateless file server – there is plenty of work for students here.
14.9 Discussion questions
1.
Consult the manual page for netstat.
[Section 14.1]
2. Because DecNet would encapsulate its messages as DecNet packets. The AppleTalk
software on the other machine would not be able to make sense of this.
All machines must have at least one protocol in common.
[Section 14.1]
3. SOCK_STREAM, SOCK_DGRAM, SOCK_SEQPACKET, SOCK_RDM.
[Section 14.2]
4. This is really networks, and a textbook on computer networks should be consulted.
TCP does not number its packets sequentially, rather it numbers each byte in a
message. So the sequence number attached to a packet is the number of the first
byte in the packet. When a packet is fragmented, there is no problem generating
consistent sequence numbers for each of the fragments.
When a TCP connection has been idle for some time, a timer goes off, and causes an
“are you alive” packet to be sent to the other machine. If no reply is received, it
assumes the other machine has died, and it terminates the connection.
[Section 14.2]
5. The bind() system service takes as a parameter a sockaddr, no matter which domain
is in use. Each particular domain has its own address structure, such as sockaddr_un
or sockaddr_in. These are cast to be of type sockaddr.
[Section 14.2]
6. Yes, such a handler might return a message to the sender, saying that the protocol
is not available.
[Section 14.3]
7. It is very important to get the packet off the network interface card to make room
for another packet, which may follow immediately. Further processing can be done
at a lower priority.
[Section 14.3]
© John O’Gorman 2000
8. It might be the logical place to do it. But if it is a valid packet, then time has been
wasted checking. It is absolutely vital to get the network interface card ready to
receive the next packet as soon as possible.
[Section 14.3]
9. At Ethernet level, it determines that it is an IP packet, and passes it on to IP
software. This determines whether it is UDP or TCP. [Section 14.3]
10. One module has the advantage of simplicity. There is only one process, not many.
But there is room for error, such as calling the wrong local procedure.
A separate stub has clearer logic, but there could be many server processes, all
waiting, and rarely doing anything.
[Section 14.5]
11. The pointer identifies a memory location in the local machine. It is meaningless on
the remote machine.
[Section 14.5]
12. When asked to translate a name to an address, it would only do so if the caller were
entitled to the information. This would put all the security eggs in one basket. Of
course individual services could implement their own authentication as well.
[Section 14.5]
13. The sender could set a “repeat request” bit in the header of the request packet,
with the same transaction number as the original. If the server recognises that it
has seen this request before, then it is the reply which was lost; otherwise the
original request.
14. It is useful to be able to check whether a particular server is up and running,
without actually getting it to do any work. Typically the NULL procedure would
require little or no authentication.
[Section 14.6]
15. It declares a static variable to hold the result value.
The heart of it is a call to clnt_call(), which is passed seven parameters.
a) The client handle (passed in by the client)
b) The symbolic constant representing the procedure to be called
c) The XDR routine to serialize the input parameter
d) The input parameter (passed in by the client)
e) The XDR routine to deserialize the result
f) The address of the memory location where the result will be written
g) A timeout value.
Note that it returns a NULL pointer if clnt_call() fails, otherwise the address of
the result value, which is what the client is expecting.
[Section 14.6]
16. This is more complicated. The main area to look at is the user defined function, at
the end. Note that for the NULL procedure, it just returns. For any other
procedure, it sets up a pointer to the appropriate function in local. This function is
not here – it is the server function, to be written by the user.
© John O’Gorman 2000
Note the function closedown() at the end, which is registered in main() as a handler
for SIGALRM.
The main() is concerned with setting up the socket, and registering the service.
Note the calls to svc_register(), and svc_run().
[Section 14.6]
17. See Gray Figure 9.10. Authentication; clnt_ops; network address, socket, port. The
typedef can be found in <rpc/clnt.h>.
[Section 14.6]
18. The pointer passed by a client to its stub. The call is synchronous, so nothing is
done until it returns. But if the client is multithreaded, changes could be made.
The pointer returned by the stub. The data is in a static variable, so is safe until
the client deallocates it. Once the client does deallocate it, the pointer is invalid.
Similar considerations apply to the server.
[Section 14.6]
19. Register a signal handler for SIGKILL, which first deregisters the server, then
terminates it.
[Section 14.6]
20. Create a thread which waits on the socket, while the main thread returns to the
client. When the asynchronous reply comes in, this thread makes the result
available in some shared variable, and signals a semaphore. The client eventually
picks up the result, using the semaphore for synchronization. It could also write
this result to a pipe or message queue. [Section 14.6]
© John O’Gorman 2000