HOMEWORK 1 FAQ Last Revision: 1115 AM, Feb 11, 2004 ERRATA ------ Problem 2, Part c: Assume that the sender can transmit packets continuously and that no acknowledgements are necessary; i.e., we want to know the length of the time interval from the beginning of transmission until the last bit reaches the receiver. Problem 3, Part a: Add: "A collision occurs when one signal collides with another. The result is a noise burst traveling in the same direction as the original signals." Problem 4, Part c: Should read: "... part b." (i.e., change 'c' to 'b') Problem 5, Part b: Should read: "Suppose that this structure is properly transmitted across a network to a big-endian receiver using network byte ordering. Repeat Part a for the message received at the receiver before conversion to host byte (HBO) order. Problem 5, Part c: Should be what is now Part d; i.e., Parts b and c should have been Part b alone. Problem 7, Part b: Assume now that queueing delays can occur. Problem 10: The -v flag should cause the gettimeofday() values to be printed in hex while in NBO format and the getservbyport() ASCII strings in hex. Print the normal output results AFTER conversion so that they make sense. Problem 10: The assignment says to submit the output of a test script that is on the web page. But instead, it should say: Submit output from your own test. The test should result in the client sending the following sequence of requests: gettimeofday getservbyport with m=7, n=11 gettimeofday getservbyport with m=80, n=81 gettimeofday getservbyport with m=110, n=129 quit This is an abstract description. You can use your own encoding. QUESTIONS/ANSWERS ----------------- Problem 1 --------- Problem 2 --------- Q2-1) How can we do this problem if we don't know anything about TCP? A2-1) See the Errata. Q2-2) On problem 2c, shouldn't the transmission time be # frames * 188.4 usec? I got 198 msec, not 373 msec. It looks like your posted solution is incorrect. A2-2) You are right. I don't know where I got that solution. I posted an updated solution. Q2-3) Does the payload in Part c include the headers or not? A2-3) I should have said the "application payload" is 1000 bytes. This excludes the IP, TCP and Ethernet headers. Problem 3 --------- Q3-1) How is a bus LAN different than a link? A3-1) Multiple hosts can be attached to a bus at various points along the bus. Also, a signal travels in both directions along a bus. But the main idea here is that the worst case is when you have a transmitter at one end of the bus and a receiver at the other end. Now, apply our standard model of electrical propagation. Problem 4 --------- Problem 5 --------- Problem 6 --------- Q6-1) In Part c, first, we divide 1GB file into a lot of 1KB packets, and then start to send these packets one by one. But, does the receiver send back the ack to sender while it gets a packet? A6-1) The solution assumes that the transmitter transmits continuously. It implies that the receiver is sending back ACKs but it doesn't prevent the transmitter from sending as fast as it can. Q6-2) Do we add the Frame header size overhead (64 bytes) to the 1KB packets in our calculation or do we just calculate for 1KB packets assuming all headers are included ? A6-2) No, don't add anything. The point of this problem is to get at the issue of link efficiency (or lack there of) when you have to wait an RTT for an ACK. Problem 7 --------- Q7-1) Does each link have the same distance ? A7-1) No, not necessarily. Q7-2) In Part b, you say that there can be congestion. But Assumption 6 says that there are no queueing delays. How can that be true? A7-2) Part b should say that it no longer makes Assumption 6. Q7-3) Why would there be queuing delays in this scenario. Since there are no hops between Tx and Rx? A7-3) In part b, there can be queueing delays because the intermediate hops are routers. These routers typically will have more than one input interface which means that there is traffic contending for the same output interface as the measured flow. Problem 8 --------- Problem 9 --------- Q9-x) A 2-bit sequence number can detect 4 lost packets. Isn't that why 2 bits will work? A9-x) This is an incorrect statement. In Part b, data packets and ACK packets can be lost or delayed. HINT: If packets can never be delayed (but can be lost) and the time out is perfect, no sequence numbering is required! Convince yourself that this is true or find a counter example. Then, consider the case of delayed ACKs. Problem 10 ---------- Q10-1) Is it possible to ssh from the hilton.cec box to the Linux box's ? It doesn't appear that the private IP's of the lab Linux box's are routable. A10-1) You can ssh. Also, in the other direction ... assuming they are up and running. Try the following depending on the host: hilton> /usr/sbin/ping -s chigger.int # or 172.16.2.1 chigger> /bin/ping hilton.cec If you can ping then you should be able to ssh. Now try ssh (but of course you have to get the name or IP address right). Q10-2) Would it be alright for me to just use my Linux box at home and route the client query's to the hilton server query's ? I don't believe that the hilton box can function as the client for the fashion that I have things routed and nat'd as they come into my house. A10-2) Right now there is no firewall rules that will block traffic between any of the CEC hosts; i.e., hilton can function as a server. I do not know what their firewall issues are with respect to going between your home and CEC. I am checking on this right now and will let you know when I get an answer. But you can use your Linux box at home if there are no firewall issues. Just make sure the ultimately other end is a different architecture. Typically, your Linux is running on an Intel PC. Since hilton is a Sun, you are ok. Furthermore, if I were doing this problem and I had a home computer, I would get it working with the client AND server running on my home computer. Then, the only problem should be NBO and compiling issues when I move the code elsewhere. Q10-3) I am getting the value -4261476 from gettimeofday() and my client prints -1073750704. What is going on here? It must be my C++. Is there a consultant? A10-3) Evidently you have not taken CS422S ... Anyway (and unfortunately), we do not have a consultant/grader and are unlikely to get one soon. You will have to ask me your C++ questions or talk to another student. But to get you over the current hump, try the following steps: 1a) On the server, print the contents of the 1st arg from gettimeofday(). Note that the struct timeval contains two longs. So, if you use printf, use %ld to display the right values. cout should auto detect the right format (assuming your declaration is correct). The two values indicate sec and usec since the epoch (see the man page) and therefore should make sense. The return code should be 0. The seconds should be around 1075480931. The useconds should be between 0 and 999999. 1b) Also print the fields out in hex. Do the results make sense? 2) Repeat 1a and 1b using the message buffer values that are the result of calling htonl() on the 2 values. 3) Repeat the above steps on the client using the incoming message fields. This should show you where the problem is. If the output is too confusing, try the above steps by sending two long constants instead of the gettimeofday() value; e.g., struct { long x; long y; } foo = { 1, 3 }; Then try the message in problem 5 of the homework. Q10-4) In Part 2, you want us to "return the protocol names for the protocol numbers in the inclusive range(see getservbyport(3)". I don't understand how can we get "protocol names" for some given "protocol numbers" by calling getservbyport(). Do you mean to return service names for the port number in some range? A10-4) Yes. Q10-5) In your handout or website, there is always a number associated with a function when describing that function, like "getservbyport(3)" or "gettimeofday(2)", what do those "2" or "3" mean? A10-5) The numbers 2 and 3 refer to the section of the Unix man page. You don't need to know those in most cases although there are some names which have entries in multiple sections. For example, there is a sleep command and a sleep library call which are distinguised by sleep(1) and sleep(3) respectively; i.e., since section 1 is for commands, sleep(1) refers to the command manual page and the other refers to the library call. In order to read the man page for these two: Linux> man 1 sleep # 'man sleep' will default to this Linux> man 3 sleep Solaris> man -s 1 sleep Solaris> man -s 3C sleep # sleep is in section 3C in Solaris Note that Solaris has the sleep library function in a different section from Linux. Q10-6) I tried calling getservbyport() on Free BSD, Linux, and Solaris. But none of them work. I either get a large integer or it says "No such service." I think it must be a NBO thing, but I can't get it to do anything when I call it with port 6. A10-6) A few comments. 1) If you are having a problem with hilton, it is NOT a NBO thing since hilton is a Sun running Solaris which is big endian; i.e., it is already in NBO and things like htons() and ntohs() are null functions. 2) "No such service" just says that there is no such service; i.e., there is no such entry in /etc/services. Typically, port 6 has no service. So, it is not surprising that you got the "No such service" result. Try port 7 which should be the "echo" service. 3) You do have to be careful. The man page indicates that you need to pass in an 'int' in NBO. The resulting "struct servent" is defined in the include file /usr/include/netdb.h and shows that "s_port" is an NBO int. However, this is confusing since a port number is a 16-bit quantity (unsigned short or u_int16_t). The short answer is that the calls should look something like: servent *sptr; sptr = getservbyport(htons(7),"tcp"); if (sptr != NULL) { printf("Port 7 is %s (port = %d, proto = %s)\n", sptr->s_name, ntohs(sptr->s_port), sptr->s_proto); } ... The longer answer is given below. If you print out the contents of sptr->s_port in hex on a Sun (big-endian), you will get: Addresses: a a+1 a+2 a+3 sptr->s_port 00 00 00 07 As expected, the field is right justified. On a PC (little-endian), you will get: Addresses: a a+1 a+2 a+3 sptr->s_port 00 00 07 00 This looks strange. But what it really means is that it is the rightmost 16 bits that contains the port number and the 2 bytes are in reverse order! Q10-7) I am trying to pass a "struct servent" over a socket. How do I deal with pointers? A10-7) Pointers make no sense between two hosts. I would return a sequence of strings for the reply to getservbyport(). Q10-8) For problem 10, because I prefer to use C++, can I wrap these socket APIs into object-oriented fashion ? A10-8) Yes, so long as it hides the unexpected cases and tests all return codes of system calls and library functions. Q10-9) You say to "print incoming messages in both hexadecimal and human readable form BEFORE conversion." What do you mean by this? A10-9) -v is suppose to be a pedagogic flag so that you can see what the internal representation looks like before conversion. The normal field print out should occur AFTER conversion so they make sense. Q10-10) How should we input m and n, the command line? Does the server reads m and n from stdin when it gets a connection from a client? A10-10) Try stdin. The CLIENT logic might look like: Connect to server; do { Display prompt; Get command; Case (cmnd) { gtod: Send msg to server; Get reply; gpbn: Send msg to server; Get reply; quit: Send msg to server; Get reply; done = TRUE: } } until done; Disconnect; Q10-11) I don't understand why I get garbage in my output (marked with <<<<< below): please input the start port number:9 please input the end port number:12 the services for port number [9, 12] are: the service on port 9 is discard the service on port 10 is NULL rd <<<<< the service on port 11 is systat <<<<< the service on port 12 is NULL t <<<<< A10-11) I suspect that you are sending the information using: send(..., strlen(foo)); where foo is the name of the string you are sending. This means that the null character is not being sent and therefore unless you add it back in the correct spot, then you will get garbage output when you try to print the protocol name. Why don't you try sending from the server using: send(..., 1+strlen(stringAtServer)); and printing from the client using: printf ("... %s\n", stringAtClient); Q10-12) How complicated should our input routine be for the client? A10-12) Try something like: void doClient(void) { char line[LINESZ]; int run = 1; while (run) { printf("command (g, p, q): "); fgets(line, LINESZ, stdin); switch(line[0]) { case 'g': doGettimeofday(); break; case 'p': doGetservbyport(); break; case 'q': run = 0; break; default: fprintf(stderr, "*** Bad command %c\n", line[0]); break; } } } Q10-13) I didn't transmit the service aliases or port numbers. Is that ok? A10-13) Yes. Q10-14) Do we have to convert the struct timeval stuff to hours, minutes, etc? A10-14) No, don't waste your time.