Exam FeedbackMar. 8, 2006Traceroute slide incorporated March 24Pigeon slide added May 10Further additions not expectedTopicsTopicsreading listthe traceroute/netmask questionfinger client: errors & mythsL13b_Exam15-441Computer Networking– 2 –15-441SynchronizationTextbookTextbookRelevant nowSection 2.5 (Reliable Transfer)Chapter 5: Transport (ok if you read 5.3 lightly)Chapter 6: Congestion ControlLooking Backward / ForwardSection 3.3 (ATM)Section 4.4 (Multicast), 4.5 (MPLS)Section 9.1 (DNS)– 3 –15-441OutlineThe pigeon questionThe pigeon questionThe netmask questionThe netmask questionThe finger questionThe finger questionMythsMyths– 4 –15-441The Pigeon QuestionBob...Bob......inspects and makes decisions based on IP addresses....is a network-layer entity, typically called a router.Kelly...Kelly......“strengthens” packets which are “tired”Kelly could be a repeater, but...Kelly......also decides where packets should goKelly can't be a physical-layer device»Kelly's decisions are based on something “outside of” the IP addressesoKelly must be a link-layer device – in this case, a bridge.– 5 –15-441Size of Netmask IncreasesAN 2ISP 2ISP 1ISP 3AN 4AN 1AN 5AN 3HostHostHostHostHostHostNet.HostNet IDNet IDNet IDNet IDNextNextNextNextForwarding TableAs you get closer to the destination, the set of hosts in your target area becomes smaller, i.e. the Net ID growns and the Host ID shrinks.Analogy: when you travel to a hotel, you first get to the right continent, then the right country, then the right city, and finally, the right hotel.– 6 –15-441Size of Netmask IncreasesCasesCasesDeparting from a host with only one linkThat link probably has a “default route” entry»0.0.0.0/0Heading toward “the backbone”Probably more default-route entries (mask stays 0 bits long)Departing “the backbone” for target's ISPOne entry probably covers the ISP's address space»x.y/16Departing the ISP to the target organization's networkOne entry probably covers the target organization»x.y.z/24 Arriving at the destination host via point-to-point linkThe table entry for that link on the penultimate host is like»x.y.z.w/32– 7 –15-441fingerProblemProblemHere is a finger clientConnect to TCP port 79send usernameprint out server's responseSay what's wrongThis was a “target-rich environment”– 8 –15-441finger.cint main(int argc, char *argv[]){ int s, len; struct sockaddr_in server; struct hostent *hp; char c, buf[8192]; if (argc != 3) { fprintf(stderr, "usage: %s host user\n", argv[0]); exit(9); } server.sin_family = AF_INET; server.sin_port = 79; server.sin_addr.s_addr = gethostbyname(argv[1]); s = socket(AF_INET, SOCK_DGRAM, 0); bind(s, (struct sockaddr *) &server, sizeof (server)); write(s, argv[2], strlen(argv[2])); write(s, "\r\n", 2); if ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len); exit(0);}– 9 –15-441finger.cint main(int argc, char *argv[]){ int s, len; struct sockaddr_in server; struct hostent *hp; char c, buf[8192]; if (argc != 3) { fprintf(stderr, "usage: %s host user\n", argv[0]); exit(9); } server.sin_family = AF_INET; server.sin_port = 79; server.sin_addr.s_addr = gethostbyname(argv[1]); s = socket(AF_INET, SOCK_DGRAM, 0); bind(s, (struct sockaddr *) &server, sizeof (server)); write(s, argv[2], strlen(argv[2])); write(s, "\r\n", 2); if ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len); exit(0);}– 10 –15-441finger.c server.sin_family = AF_INET; server.sin_port = 79; server.sin_addr.s_addr = gethostbyname(argv[1]); s = socket(AF_INET, SOCK_DGRAM, 0); bind(s, (struct sockaddr *) &server, sizeof (server)); write(s, argv[2], strlen(argv[2])); write(s, "\r\n", 2); if ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len);Pretty much all of this is wrongPretty much all of this is wrong– 11 –15-441finger.c server.sin_family = AF_INET; server.sin_port = 79; server.sin_addr.s_addr = gethostbyname(argv[1]); s = socket(AF_INET, SOCK_DGRAM, 0); bind(s, (struct sockaddr *) &server, sizeof (server)); write(s, argv[2], strlen(argv[2])); write(s, "\r\n", 2); if ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len);– 12 –15-441finger.cBadBad server.sin_port = 79;GoodGood server.sin_port = htons(79);BadBad server.sin_addr.s_addr = gethostbyname(argv[1]);GoodGood hp = gethostbyname(argv[1]); memmove(&server.sin_addr, hp->h_addr, hp->h_length);– 13 –15-441finger.cBadBad s = socket(AF_INET, SOCK_DGRAM, 0);GoodGood s = socket(AF_INET, SOCK_STREAM, 0);BadBad bind(s, (struct sockaddr *) &server, sizeof (server));GoodGood connect(s, (struct sockaddr *) &server, sizeof (server));– 14 –15-441finger.cBadBad if ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len);GoodGood while ((len = read(s, buf, sizeof (buf))) > 0) write(1, buf, len);– 15 –15-441MythsMust close sockets before exit()Must close sockets before exit()If that were true we'd all be in big trouble!exit()'s job is to clean up process resourcessizeof(buf) == 4That's like a real problem...sizeof (pretty much any pointer) == 4 (on many machines)sizeof (array) is, well, the size of the array, in bytes»“Doesn't work” for array parameters to a function»They're actually pointers (call by reference), not arrayswrite(stdout, ...)That's mixing metaphors – file descriptors aren't stdio streamsYou could write write(fileno(stdout), ...)But if fileno(stdout) != 1 something very very odd is going on– 16 –15-441MythsCannot use write() and read() on UDP socketsCannot use write() and read() on UDP socketsSure you can!read() doesn't block to wait for server responseread() doesn't block to wait for server responseYes, it does!strings must be converted to network byte orderstrings must be converted to network byte orderThe network byte order for strings is:Send the first byte, then the second, then the third...“Byte order” is a problem when you have N-byte chunksInteger is a 4-byte chunkYou could have a string byte-order problem with UnicodeOut of scope– 17 –15-441MythsBuffer overflows!Buffer overflows! write(s, argv[2], strlen(argv[2]));We aren't putting anything into a buffer!Certainly not one of fixed size, without a length checkThe kernel might be putting these bytes in a bufferIf the kernel does that unsafely
View Full Document