Course groundrules (not updated yet, but midterm exam will be June 12, and will count about 75-80% as much as the final, which is June 28)
Here are the files for the (first?) programming assignment, due June 19:
You are to: InputStream istr;
try { istr = s.getInputStream(); }
catch (IOException ioe) {...}
byte[] buf = new byte[bufsize];
int len;
while (true) {
try {
len =
istr.read(buf, 0, bufsize);
}
catch (IOException ioe) {... }
if (len == -1) break; // this means
EOF
String str = new String(buf, 0,
len);
System.out.println(str);
} //while reading from s
Note that this prints out an extra blank line between each output line ... it shouldn't.
For the UDP version, you have to do slightly more work. Much of this is closely tied to the different semantics of UDP sockets. First, you create a DatagramSocket (bound to a specific port on the server, any port on the client). Then, you read from the keyboard and send over the network, on the client, and read from the network and write to the screen, on the server. This part is just like the TCP version.
What changes is sending over the network. To transfer data using UDP,
you will use the methods send() and receive(). The parameter for these
is of type DatagramPacket. A DatagramPacket is constructed with a byte[]
buffer and int length to hold the data, and also an IP address and port.
The client only needs to set the IP address (using the getByName() function)
and port once; the buffer and length change with each message sent. The
server can ignore the IP address and port.
I hope to cover some material on network security too.
1.1 Foundations
2.2 Encoding
2.3 Framing
2.4 Error Detection
2.5 Sliding windows
2.6 Ethernet (see also my ethernet notes)
3.1 Forwarding
3.2 Bridging
4.1 Basic IP
4.3.1 Subnets
5.1 UDP
5.2 TCP (basic properties, connection setup, concept of state
diagram)
The homework problems assigned earlier are good to study. The following additional exercises would also be good to study; you shouldn't necessarily complete these, but you should study the text until you're reasonably confident you know how to approach them. Solutions are here.
Here are two further study problems:
1. The following problem deals with IP routing tables as maintained by routers; machines A, B, C, D, etc. are routers. No host machines are shown. The special machine DEFAULT is also a router, but you need not give its routing table (it represents a default destination). Nets involved are all class C, with addresses 200.0.5, 200.0.6, 200.0.7, .... The following convention is used: machine A always has host portion of its address equal to 1; e.g. 200.0.5.1, 200.0.6.1, etc. Similarly, B has host portion 2, C has 3, D has 4. The special machine DEFAULT has host portion 100.
(a). Give the routing tables for the following connections. You may use symbolic names (A, B, C...) for routers instead of IP addresses. Use default routes whenever possible, but be sure that a packet destined for some net other than 200.0.x gets routed to machine DEFAULT.
net
net
net
net
200.0.5____A_____200.0.6_____B______200.0.7_______D____
200.0.8______DEFAULT
|
200.0.8.100
net 200.0.9
|
C
|
net 200.0.10
b. Do the same for the following configuration.
B
/ \
net 200.0.5
net 200.0.6
/
\
A
D------------200.0.9
\
/
\
net 200.0.7
net 200.0.8
DEFAULT
\
/
C
c. Suppose two routers, A and B, have tables as below. What will happen to an IP packet sent from A to address 147.126.4.9?
200.0.5----A----------------------B----200.0.6
A: ___________________
B: ___________________
200.0.5 | direct
200.0.6 | direct
default | B
default | A
======================================================================
2. In real implementations of ARP, hosts are allowed
to extract address mapping info from any broadcast ARP query packet: every
machine sending such a packet includes its own IP-to-physical address binding
info, and every machine receiving such a broadcast (whether or not intended
for that machine) adds the source IP-to-physical address info to its ARP
cache. Thus, in the example above, not only would A get B's address info
but also every machine on the net would get A's address info.
(a). Explain why this means that if
1. A broadcasts an ARP query "where is B?"
2. A sends B a regular IP packet
3. B wants to send an IP packet in reply
to A
then A's physical address will already be in B's ARP
cache.
(b). Suppose A broadcasts a request "where is B", but inadvertently lists the physical address of another machine C instead of its own (i.e. the ARP packet has IP src=A, phys src = ethernet address of C).
What will happen? Specifically, will A get a reply? What entries will be made in the ARP caches on A, B, C, and a 4th machine D?
Suppose D uses its newly updated cache to send to A. Will
the packet arrive at A? What if C tries to send to A?
Here are a few review exercises from chapters 4-6 for the final. The
final may include questions from selected sections of chapters 2 and 3
as well, as listed above; see the midterm study questions to prepare for
these.
The following paper has useful information about TCP/IP security: Security Problems in the TCP/IP Protocol Suite by Steve Bellovin.