Date: Tue, 05 Nov 1996 00:31:24 GMT Server: NCSA/1.5 Content-type: text/html Last-modified: Sun, 03 Nov 1996 00:00:03 GMT Content-length: 76560
![]() |
CS 640 Mail List Archive |
If you have been considering using CVS, but have had trouble getting through the man pages, check out the info documentation -- it's much better. ("M-x info" from emacs) -- ,,, `o-o- < Ben. - .
Don't knock yourselves out trying to implement some elaborate timer mechanism. Solaris has a cond_timedwait() function that allows you to wait on a condition variable for a bounded amount of time. This effectively gives you a very clean way to set a timeout that you can later cancel if an ACK arrives. Consider the attached demonstration of this feature. (Note: this is not necessarily a good example of how to write code, just a demo of cond_timedwait()). The source and an executable for this are in: /p/course/cs640-lhl/public/project/timerDemo/ -- ,,, `o-o- < Ben. - . -------------------------------------------------------------------------- ////////////////////////////////////////////////////////////////////////// // Demonstration of timers using cond_timedwait() // // To compile: // CC +w -lthread timedwaitDemo.C -o timedwaitDemo // ////////////////////////////////////////////////////////////////////////// #define _REENTRANT #include#include #include #include #include #include enum State {IDLE, REQUEST_PENDING, ACKED}; // Connection control block class class connectCB { public: // Construct CCB with given timeout connectCB(char* nm, int to) : timeout(to) { name = nm; state = IDLE; mutex = new mutex_t; ackArrivedCV = new cond_t; } // Destructor ~connectCB() { delete mutex; delete ackArrivedCV; } // Set up the connection, retransmitting as necessary void establishConnection() { int attempt = 0; int wakeReason; mutex_lock(mutex); // Send initial connection request state = REQUEST_PENDING; sendConReq(++attempt); // Set up timeout value struct timespec timeoutTime; timeoutTime.tv_sec = time(NULL) + timeout; timeoutTime.tv_nsec = 0; // Wait for ACK or timeout, whichever comes first (note "while" // needed because of Mesa cv semantics) while(state == REQUEST_PENDING) { wakeReason = cond_timedwait(ackArrivedCV, mutex, &timeoutTime); // If timout occured, retransmit and reset timeout if (wakeReason == ETIME || wakeReason == ETIMEDOUT) { sendConReq(++attempt); timeoutTime.tv_sec = time(NULL) + timeout; } } printf("Thread %s done -- ACK arrived.\n", name); mutex_unlock(mutex); } // Process an ACK void ack() { mutex_lock(mutex); state = ACKED; cond_signal(ackArrivedCV); mutex_unlock(mutex); } // Get the connection state State getState() { State retVal; mutex_lock(mutex); retVal = state; mutex_unlock(mutex); return retVal; } // Private methods private: // Send connection request message void sendConReq(int tryNum) { printf("Thread %s sends connection request %d\n", name, tryNum); } // Private data private: State state; const int timeout; char* name; mutex_t* mutex; cond_t* ackArrivedCV; public: thread_t thrID; }; connectCB* ccb[2]; void* establishConnectionStub(void* cCB) { connectCB* connect = (connectCB*) cCB; // Just call the class function for the given object connect->establishConnection(); return 0; } main() { ccb[0] = new connectCB("A", 3); thr_create(0, 0, establishConnectionStub, (void*)ccb[0], 0, &ccb[0]->thrID); ccb[1] = new connectCB("B", 1); thr_create(0, 0, establishConnectionStub, (void*)ccb[1], 0, &ccb[1]->thrID); sleep(10); ccb[0]->ack(); sleep(5); ccb[1]->ack(); sleep(5); thr_exit(0); }
We would like to schedule individual meetings with each project group this week to discuss (and return) your draft designs. All office hours will be canceled to accommodate 15 minutes meetings with each group. Meeting slots are available TR 2:30-4:30 and WF 3:00-5:00 and you should sign up electronically as follows: 1) View ~ben/public/signup/sched.txt and consult your group members to pick an available time slot 2) Edit ~ben/public/signup/sched.txt quickly to enter your group into a time slot Please, please do not mangle this file or write it back ages after you load it into your editor. If this system degenerates into chaos, we'll have to resort to a paper signup sheet. Meetings will be held in one of our offices or in a conference room if we can get one. In the later case, there will be forwarding notes left on our office doors. See you all soon, - Ben and Srinivasa
Just because we TA's are still working our way through the draft project specifications, does not mean that you should slack off on your project. Indeed, judging by what we have seen so far, many of you still have a lot of design work to do. Here are a few general comments that apply to most of the specifications we have seen: * This document is suppose to be a SPECIFICATION, not a casual discussion of issues or a set of annotated header files. You must provide the full details of your system structure, algorithms, key data structures, and packet formats. Anyone reading the spec (especially the members of your project team) should know exactly how the system is supposed to be built and who is doing what. Furthermore, if at the end of the semester, your project doesn't work, your specification is the main proof that we have that you were at least on the right track! * Many of you clearly have no clue how to make an FSM description of a protocol; I suggest looking at the TCP state diagram in the book and following these general guidelines: - every state should have a name - make it clear what the diagram describes and break complex protocols into cases; for example, show 3 FSM's for VC establishment, corresponding to the roles played by a connection-request initiator, the destination node end-point, and an intermediate node. - label which state is the start state - every arc should have two labels: the event that causes the transition and the action to take * Testing plans and implementation schedules were woefully sketchy; come up with a plan to build and test your project incrementally, so that you will be guaranteed to be able to demonstrate at least some subset of your project that works. * Don't wave your hands about anything; for example, if you plan to use the TCP checksum algorithm, describe it. Hope this helps, -- ,,, `o-o- < Ben. - .
My office hours tomorrow will be 4-6. Sorry if i confused you in my previous mail, nsp
I will not be available from 3-4 tomorrow. Instead, I will be available from 5-6. So, the changes office hours for tomorrow is 4-6. -nsp
You may not use calculators for the test.
The material from the text to be covered on the exam is: Chapter 1 Chapter 3 but not 3.8 Chapter 6 but not 6.3, 6.4, 6.5 In addition, all material discussed in class plus notes handed out and documents purchased at DOIT will be included.
> * no more than 100 nodes in network > * no more than 5 links per node > * no more than 100 connections passing through or terminating at a > node In addition, you may make one other assumption, * no node is ever more than 10 hops away from any other node -- ,,, `o-o- < Ben. - .
* the algorithm must detect link failures (as caused by a node failing at one end of a link) * if a route exists through the network from A to B, a connection request from A to B must succeed (note that the underlying VC does not necessarily have to follow the shortest path at all times) * if a virtual circuit exists between A and B, and a node goes down in the middle, and... * there is an alternative route from A to B, then the connection must stay alive from the perspective of an AAL7 client (technically speaking, it should stay alive from the perspective of an ATM client). Note that it is OK to tear the VC down and rebuild from an endpoint, just as long as the higher system layers don't notice that anything has happened. * there is no alternative route from A to B, then the connection is closed and AAL7 clients informed as per the service interface specification
Many of you have been asking about the size of the network and stuff, You can assume the following limits :- * no more than 100 nodes in network * no more than 5 links per node * no more than 100 connections passing through or terminating at a node -ben & nsp
We will go over your document carefully, checking that your design is reasonable and complete. Although the final version of your design document counts for a portion of your project grade, you WILL NOT BE GRADED on the draft version. This is just a good opportunity to get early feedback from us before you waste time and effort pursuing a bad or flawed design. -- ,,, `o-o- < Ben. - .
It is in: /p/course/cs640-lhl/public/html/fall96/src/aal7.h To link successfully with our FTP/FTPd, you must support this interface. There have been a few changes to and elaborations on the tentative interface described in the handout, so please check this file out carefully. -- ,,, `o-o- < Ben. - .
The evalution form for the project design document is available online (in postscript form) -nsp
aal7_send() only has to block the calling thread until the data in the "packet" buffer has been enqueued by AAL7. At that point the "packet" buffer can be reused, but the application layer cannot assume that the data actually arrived. If you want aal7_send() to block until all sent data has been acknowledged, that is OK too. -- ,,, `o-o- < Ben. - .
Pretty much the only acceptable reason for using multiple sockets per node is if you want a more realistic simulation of the physical links in the link-layer of your system. There will be no "out-of-band" communication allowed between nodes for which a link is not specified in the configuration file! -- ,,, `o-o- < Ben. - .
For those of you who wanted to use multiple sockets for the ATM layer here's our protocol. The virtual nodes have a port number. We will guarantee that these port numbers will always be an integer which is a multiple of 10. This will enable you to use multiple sockets. Just be sure that the port number(s) for your extra sockets are not multiples of 10. -nsp
See page 294 of your textbook for an example. -- ,,, `o-o- < Ben. - .
Some of you have notes on your code citing error codes... the full list of these can be referenced via the class web page, next to the line for the assignement.Date: Wed, 9 Oct 1996 10:08:11 -0500 From: Lawrence Landweber
I apologize for again forgetting to bring the assignments. You can come by my office to pick yours up.
nsp@parmesan.cs.wisc.edu 132 Noland Wednesday, October 23 7:15-9:15 PM
The TCP spec is available online via the class web page. http://www.cs.wisc.edu/~cs640-1/TCP-793 This is for friday and next week.
A SAP is simply the name of a particular service on a particular host. The data structure used to represent a SAP is a struct aal7_sap and you can count on it looking like this (complete .h's coming soon): /* Host ID type (this could just be the node number from the network configuration file) */ typedef int host_ID; /* AAL7 service identifier type */ typedef int aal7_servID; /* AAL7 Service Access Point (SAP) */ typedef struct { host_ID hostID; aal7_servID servID; } aal7_sap; -- ,,, `o-o- < Ben. - .
To CS 640 Students Let me emphasize ben's request... there are 12 people for whom we do not have group info. Could each of those people please send their status to ben before friday. Please do so whether you are currently a group of 1, 2 or 3.
In addition to the AAL7 service interface calls listed in the project handout, there will be an initialization "hook" for you to set up worker threads and shared data structures in all your layers. void aal7_init() You must support this call, but precisely it does is totally up to you; it is just a hook for you to use. The main thread in our main() will do this: 1) Call aal7_init(); 2) Create an FTPd server thread 3) Create an FTP client thread 4) Go to sleep The only thing missing from the prototypes of the AAL7 service interface functions is the error codes that must be supported. We will have these ready for you next week. -- ,,, `o-o- < Ben. - .
Srinivasa has made a nice diagram that shows the sequence of events in connecting to a server. It also should clarify some of the terminology we have been using. /p/course/cs640-lhl/public/html/fall96/project/sap.eps -- ,,, `o-o- < Ben. - .
Groups of one: There are 18 of you and you know who you are. Please find a group ASAP and mail me your members names and usernames. Groups of two (need another person): Edwin Sutanto (edwins); Henny Dwiyono (dwiyono) Groups of three: Ming He (he); Amir Roth (amir); Glenn Ammons (ammons) Scott Colville (sec); Brian Swander (swanderb); Tim Flechtner (flechtne) Abhinav Gupta (agupta); Ashish Thusoo (ashisht); Shrinivas Ashwin (sashwin) Zhenyu Liu (zhenyu); Konstantinos Dovrolis (konstant); Moncef Elaoud (moncef) Luke Blanshard (luke); Jennifer Shi (shi); Taxiao Wang (twang) Narayanan Anand (narayana); Shyamsundar Nuggehalli (shyamsun); Andrew Therber (andyt) Chris Weaver (weaver); Shilpa Lawande (ssl); V. Gopalakrishnan (raji) John Edwards (edwards); Johannes Gehrke (johannes); Krzysztof Zmudzinski (zmudzin) Andrew Miller (miller1); Dan Schuster (schuster); Erik Yoder (yoder) Kurt Wiedenhoeft (wiedenho); Eric Groth (groth); Paul Salmon (pdsalmon) Daniel Goemans (goemans); Peter Mateja (mateja); Randal Ramig (randal) Zhenhai Lin (zhenhai); Liping Zhu (liping); Dan Yao (dyao) Baicheng Liao (bail); Xuelin Lu (xuelin); Tim Fliss (fliss) Shad Aumann (aumann); Mike Payne (mpayne); Tricia Powers (powers) Ming Yin Mak "Newton" (mak); Chi-Man Sizto "Jason" (chi-man); Chi Yan Liu "Alice" (chil) Brad Thayer (brad); David Sundaram-Stukel (sundaram); Kurt Froehlich (froehlic) Sivasankaran Chandrasekar (schandra); George Varghese (joev); Chan Wai Kei "Stephen" (waic) Susan Chiang (susanc); Eleanora Suran (suran); Oguz Yetkin (yetkin) Irvin Tsang (irvin); Shang Zou (zou); Chi-Cheng Chu (chi-chen) Luis Ulloa (ulloa); Kin Chan (kinc); Kam-weng Cheong (kamweng) Zhe Wang (zhe); Haihong Wang (whh); Jin Zhang (zj) Thomas Dever (dever); Jim Auer (auer); Kristin Martens (martens) Haris Stewart (haris); Byron Yeung (byron); Soma DasGupta (soma) Yau Mo Chan (yau); Ching-lun Wu (chinglu); Rong Wang (rongw) Dan Schuster (schuster); Andy Miller (miller1); Erik Yoder (yoder) -- ,,, `o-o- < Ben. - .Date: Wed, 2 Oct 1996 09:38:30 -0500 From: Benjamin Teitelbaum
(message from Edwin Sutanto on Tue, 1 Oct 1996 21:16:19 -0500 (CDT)) Subject: FSM's Missing from Slides Sender: owner-cs640-1list@cs.wisc.edu > Ehmm. Ben, > > your postscript project overview slides still > has that meesing FSMs I know. I hand pasted the FSM's in. Look at page 3 of http://www.cs.wisc.edu/~cs640-1/fall95/project/ to see what is on those slides. -- ,,, `o-o- < Ben. - .
We will be done grading by Friday, or Monday at the latest. -- ,,, `o-o- < Ben. - .Date: Tue, 1 Oct 1996 14:48:34 -0500 From: Benjamin Teitelbaum
Swander on Wed, 25 Sep 1996 09:05:41 -0500 (CDT)) Subject: Interactions Between the Garbler and Signalling/Routing Sender: owner-cs640-1list@cs.wisc.edu > > I have a question about the garbler and arbitrary protocols. > Does the garbler only effect the ATM packets going out (meaning > our signalling packets and routing packets are uneffected), or > does the garbler garble everything (much more realistic)? It (potentially) garbles all ATM payloads, but will never garble an ATM cell header. Therefore, yes, you do need to worry about signalling and routing protocol cells being garbled. > > If the garbler does garble everything, then how will it deal with > the arbitrary structure of our signal and routing packets? Or, > do we need to come up with signalling and routing protocols > that communicate completely within the secure (from garbling) > of the header of ATM packets (meaning that all we send are > ATM packets, but we use the payload type in the header to > tell how to interpret that header). You won't be able to squeeze all of your routing and signalling info in the ATM cell header. You will have to do a checksum or CRC computation for these cells. You could put this in the payload or use the CRC field in the ATM cell header -- your design choice. > > What seems to me to be the best solution is to allow arbitrary > packets of whatever size we like to be sent for our signalling > and routing protocols. These will be lost and garbled at will. > The question is: are the first 5 bytes garble-proof? Would > we need to do some sort of CRC to check the rest? Should we > just send signalling and routing info in 5 byte chuncks? Be careful here. Your signalling and routing protocols will be communicating through ATM "cells", not "packets", which is the word we have been using to describe the AAL7 data transfer unit. I believe that I answered your other questions in my previous comment. -- ,,, `o-o- < Ben. - .
Please note the following change in my office hours for this week Monday: 1.45 - 3.45 (shifted 15 mts earlier from the normal hours) Wednesday: 3.00-4.00 (i am cancelling 4.00-5.00) to compensate for that i will hold office hours from 4.00-5.00 on Thursday Sorry for the inconvenience -nsp
We are here to help you with questions about networking and with the course project, not to teach you C++ (which is a prerequisite) or to debug your programs for you. Questions like: "the compiler says X, what do I do?" or basic questions about the C++ programming language like this: > > what is a const method? I am getting a strange error like this in > code where a const instance of a class is called on a method that only > prints the contents: > > bvect.cc:53: call to non-const method `int bvector::print()' with > const object will be given last priority. Since there is a steady stream of valid questions about the project, this means that questions like those above will probably never be answered. If you have questions like these, I suggest buying a book on C++ (I like the Scott Meyers books), studying man pages, or reviewing your 302 notes. Sorry for the obnoxiousness, -- ,,, `o-o- < Ben. - .
> How do you expect us to handle erroneous configuration files like > the one you started with? Should we barf or just go ahead and allow > any connection that is present in either direction? You can assume no errors in the configuration file. -- ,,, `o-o- < Ben. - .Date: Thu, 26 Sep 1996 15:58:11 -0500 From: Benjamin Teitelbaum
Stewart on Mon, 23 Sep 1996 20:33:50 -0500) Subject: Will We Suspend Nodes or Cause the Garbler to go "Insane" Sender: owner-cs640-1list@cs.wisc.edu > you said that for the project you'd be bringing down nodes by killing > those processes (and perhaps restarting them?). I am wondering if this > is really what you plan to do, or should we expect that you might do > either of the following as well: > > suspend the process - the node goes unresponsive, but later it floods > the network with packets that are way too late > and should be ignored until that node gets with > the times. All we will do is kill nodes and perhaps restart them. You don't have to worry about a node being suspended and then later restarted, causing really old cells to be transmitted. > > insane garbeler - the garbeler just goes insane and the node just > spits packets out onto the network that are total garbage > with no recoverable ATM packets. Again, ignore packets > until the offending node works again. > > the problem of course is that either of these above options not only > will mean re-routing virtual circuits around dead or bad nodes, but > may mean increased, useless traffic that has to be dealt with. The garbler will not go "insane". It will introduce a constant amount of noise across all links. -- ,,, `o-o- < Ben. - .
> > Another minor point: Is it OK to cache virtual circuits once they are > found for the sake of efficiency and try them first, or is the completely > unnecessary? This doesn't make sense. First of all, where would you cache VC's? Each node only knows it's local part of a VC, not the whole thing. Secondly, even if you bent over backwards to cache VC's, they might not be valid if your routing tables have changed. -- ,,, `o-o- < Ben. - .
> 3) Graph algorithm: > > How optimal does our routing have to be? Do we have to use a shortest > path algorithm, and if so, need we consider its complexity? (For > example, if we have to re-route a VC before timeout occurs, should we > search for the next best circuit? What if the network is large--the > shortest path algorithm isn't exactly lightning fast. What assumptions > can we make about the size of the network? It's more important that your routing algorithm discover routes or detect that it can not route between two end-points than that it find "optimal routes". Of course, you DO have to worry about loops. Vis-a-vis your last question, let's say the network will contain at most 100 nodes and you can set your timeout values accordingly. -- ,,, `o-o- < Ben. - .
> > The network.congif you gave is the following: > > ---------------------------------------------- > // Here is a sample network configuration file. > // The syntax should be clear. > // Comments must begin with "//" > Node 1 (sol22, 5000) links 2 > Node 2 (sol22, 5001) links 3 4 > > // Blank lines are OK > Node 3 (sol23, 5000) links 2 4 > Node 4 (sol23, 5001) links 2 3 > ------------------------------------------------ > > Shouldn't Node 2 also connect back to Node 1, like: > "Node 2 (sol22, 5001) links 1 3 4 "? > Absolutely right. Sorry about that. -- ,,, `o-o- < Ben. - .
The project overview slides are fixed, thanks to Shad Aumann. The link is still in the same place on the course page. Note that you have to set the ghostview orientation to "Seascape" to view them right-side-up. "Software Engineering 101" talk slides coming soon... -- ,,, `o-o- < Ben. - .
The script that automatically invokes a copy of your project running on each node mentioned in the network configuration file is here: http://www.cs.wisc.edu/~cs640-1/fall96/project/moa640.pl Please read the comment at the top for usage information and to see how the script constrains your command-line syntax. I've also placed a sample network configuration file in this directory that you might find useful. It lives here: http://www.cs.wisc.edu/~cs640-1/fall96/project/network.config If you find a problem with the script, please let me know right away. Thanks, -- ,,, `o-o- < Ben. - .
There is lots of information here: http://www.sun.com/sunsoft/Products/Developer-products/sig/threads/resources.html including a good FAQ and pointers to various papers about threads. I have also downloaded the "Solaris 2.4 Multithreaded Programming Guide", which I mentioned in class. It is 188 pages long. so I have 2up'd it and put it in: /p/course/cs640-lhl/public/html/fall96/project/solThreads.ps Still it's 94 pages long, so you might want to look through it to see if it's useful to you before you print it out. -- ,,, `o-o- < Ben. - .
There are 4 sets of notes available for purchase at DOIT... 1. Bit Oriented Link Protocols 2. Logical Link Control Spec 3. 802.3 Spec 4. 802.5 Spec We will cover these in the order above... beginning next monday.
Since many folks have requested them, I have put the slides from Friday's presentation of the project on-line. They are available through the course page in either MS Powerpoint format or Postscript. However, the Postscript is messed up at least when viewed through Ghostview (landscape slides are printed across portrait pages). If there are any Postscript or MS Windows gurus out there who can generate correct Postscript from either file, please send me the correct Postscript and tell me how you did it. Thanks. -- ,,, `o-o- < Ben. - .
When you have a group of three together, please mail me (ben) your names and usernames. Thanks, -- ,,, `o-o- < Ben. - .
A Postscript version of the project is now available from the cs640 home page. If you have time, please look this over before tomorrow morning, when I will present the project in lecture. -- ,,, `o-o- < Ben. - .
For those of you who are worrying about how to turn in a hard copy late at night, You can slip your hard copy under Ben's office door (room no. 3310). You dont need a key to get to room 3310 Thanks nsp
> You mean midnight the day after? Midnight this evening IS tomorrow. Deadline = Wed Sep 18 23:59:59 CDT 1996 > > Do you still want the hard copies handed in during class tomorrow? If not > then when, if ever? If you don't hand in tomorrow morning in class, put your hard copy in one of our mailboxes on the 5th floor or slip it under one of our office doors. Thanks, -- ,,, `o-o- < Ben. - .
Because, It's very important that everyone get the first assignment working, the deadline for submitting is midnight tomorrow. -- ,,, `o-o- < Ben. - .
Some of the library calls in the sample code (including bzero) are BSD-specific and that is why you may have trouble finding them. Solaris is derived mainly from System V R4 and has other ways of doing things. For your convenience, I have appended a chart below mapping the BSD calls to their Solaris equivalents. BSD Possibilities Standards/Notes ============================================================================ srandom(seed) srand(seed) ANSI-C (Also, some older UNIX) srand48(seed) SVR4 non-ANSI signal() sigset() SVR4 (systems calls not (e.g., SunOS) restarted, but bytes r/w returned, else EINTR) sigaction POSIX (but extensible by implementation) sigvec sigaction POSIX sigblock sigprocmask POSIX sigset(.., SIG_HOLD) sighold SVR4 sigsetmask sigprocmask POSIX sigset/sigrelse SVR4 sigpause sigsuspend POSIX setjmp sigsetjmp POSIX longjmp siglongjmp POSIX statfs statvfs SVR4 bcopy memmove ANSI-C (BSD bcopy() handles overlapping areas correctly, as does memmove, but not memcpy) bzero memset ANSI-C index strchr ANSI-C rindex strrchr ANSI-C getwd getcwd POSIX getrusage open,ioctl The getrusage information (and a whole lot more) can be found in the prusage structure. Use the PIOCUSAGE ioctl. See the example below and the proc(4) man page for detail. gethostname sysinfo(SI_HOSTNAME,..) SVR4 See sysinfo(2) for many other possible values getdtablesize sysconf(_SC_OPEN_MAX) POSIX See sysconf(3C) for many other values available via sysconf. strptime See code from Kevin Ruddy below timelocal mktime wait3 w/o rusage waitpid POSIX wait3 waitid SVR4 wait3 See J"org Schilling's wait3 emulation code below. usleep nanosleep POSIX See nanosleep(3R) on Solaris 2.3 (see libposix4.a) For a Solaris 2.[0-2], see the example below.
# Simple Makefile to rebuild client and server programs # Modify to suit your needs... CC = g++ LD = g++ DEFINES = INCPATH = CFLAGS = -g -Wall $(INCPATH) $(DEFINES) LDFLAGS = CLIENT_O = client.o common.o SERVER_O = server.o common.o SRCS = client.C server.C common.C client: $(CLIENT_O) $(LD) $(CLIENT_O) -o client $(LDFLAGS) server: $(SERVER_O) $(LD) $(SERVER_O) -o server $(LDFLAGS) .C.o: %.o: $(CC) $(CFLAGS) -c $< depend: makedepend -- $(CFLAGS) -- $(SRCS) # DO NOT DELETE
I've just learned that the lab is now automatically archiving course mail with Hypermail. The lab archive lives at: http://www.cs.wisc.edu/~lists/classes/cs640-1list/ and is nicely threaded by message subject. I will keep the current mail archive that is generated by my Perl script running, since it is easy to filter out messages that are irrelevant to a FAQ ("looking for project partner", "the Internet in China", etc.). The bottom line is: if you want to see an archive of all the messages, look at: http://www.cs.wisc.edu/~lists/classes/cs640-1list/ and if you want to see a moderated archive, look at: http://www.cs.wisc.edu/~cs640-1/mail-archive.html -- ,,, `o-o- < Ben. - .
OK.. I concede... my goal was not to break up friendships or split hairs on status... We will devise a single project for all... it will be a blend of the two versions we were planning.
Since sending the note, I have received requests regarding mixed teams, special students, non-cs majors, etc. The system that we will adopt is that teams that are made up of 3 undergrads will implement fewer functions. This change for undergrads will not trivialize the project, just make it a bit less work. Since EVERY student in the class has had 537 or equivalent and IS proficient at C programming, there is no reason to distinguish between majors. My goal is to help the over 50% of the students who are undergrads and who are likely to be taking more courses than grad students. Note that projects are NOT graded on a curve.. every team will get what it deserves, independent of what is done by others in the class. I would be as thrilled to have all A projects as I would be disappointed to have all C, D or F projects.
As I indicated in class today, teams of undergrads will not have to implement as much protocol functionality for the term project as will teams containing grad students. For this purpose, an undergrad team is one where ALL three members are classified as undergrads (e.g., ce3, ls4, bus4, etc). Special students will count as grad students.
One more note on sending structures Seems like some people are still having doubts on why one shouldn't send the structure as such. I am sorry if my earlier messages on this were cryptic. So I'll present a concrete example below. This should help if you have any doubts. Lets define a sample structure :- struct pkt { short type; long data; }; Define a variable of type pkt :- struct pkt pkt1; Lets assume that the address of pkt1 is 0 On the Sun Sparcs, the size of pkt1 will be 8 bytes.Bytes 0 and 1 will be for the field type, bytes 2 and 3 are not used bytes 4-7 will be used for the field data The reason is that on some machines, long inetgers are required to be aligned on a double word boundary. Hence bytes 2 and 3 cannot be used for the field data. However, all machines do not have this requirement. The same structure pkt when defined on the Vectra's will have a size of only 6 bytes. As before, assuming pkt1 starts at address 0, Byte 0 and 1 will be used for the type field and bytes 2-5 will be used for the data field because there is no requirement for the long field to be aligned on a double word boundary. So assuming that your client runs on the Sols and the server runs on the Vectras, imagine what will happen if you just send the structures across the network. Thanks nsp
When you are absolutely done with Assignment 1, please copy your source code as well as a makefile to build your client and server programs to: /p/course/cs640-lhl/public/handin/Note that you have insert access, but not write/delete access in this directory, so be certain that you are done before you copy your code over. Also, for our grading convenience, please have your makefile generate a client executable named "client" and a server executable named "server" and DO NOT COPY EXECUTABLES OR OBJECT FILES INTO YOUR HANDIN DIRECTORY! We should be able to go into your handin directory, type "make", and see two executables called "client" and "server" created that we can test. If you need a tutorial in using make, have a look at: http://www.cs.wisc.edu/~cs536-1/make.html Also, please hand in a 2-up'd paper copy of your assignment in class Wednesday as per the "Requirements" section of the assignment. Let us know if you have any trouble with the hand in process. -- ,,, `o-o- < Ben. - .
> I also have one question; what happens if you only read part of a packet, > when you specify within the recvfrom a buffer small then the packet size. > Since it is a datagram protocol and not stream, I didn't think it is possible > to read part of a packet and then come back with another call to read the > later part. While I have tried it yet, it seems that it should read nothing > or only the first part and through the rest away. Now on a stream protocol, > I think it make sense to only get a few bytes at a time.. What do you > think? > > Right, reading parts at a time works only for Streams For Datagrams, if the buffer size is smaller the recvfrom call will throw away the rest of the packet.
> another question, how do you get the size of a file ? I get it with stat(2). int stat(const char *path, struct stat *buf); -- ,,, `o-o- < Ben. - .
> is there anything that dictates the structure of the packets? > More specifically, is there something drastically wrong with making the > packet just be an array of characters that is 256 + 4 + 2 bytes long and > putting in the integers in the appropriate fields as ASCII characters? > If I do this, do I still have to worry about network or host order when > sending these packets? At the level of the sendto/recvfrom library calls, the packets you send are just "arrays of characters" as you point out. However, you still need to worry about Endian-ness because you know that those first two characters really represent an integer and if you aren't careful, they will represent the wrong integer (the byte mirror image) at the other end. So, yes, you do still have to worry about network and host order. Hope that helps, -- ,,, `o-o- < Ben. - .
> I am doing the following: > > address = inet_ntoa(hostp->h_addr); > > and I get an error about incompatible type in argument 1 of inet_ntoa. > What is exactly the thing we should place there? > hostp was declared as: > struct hostent *hostp; the first argument of inet_ntoa should be of type struct in_addr. the h_addr_list field of struct hostent is defined as char ** and hence h_addr (which is a #define for h_addr_list[0]) will be of type char * But the pointers h_addr_list[0], h_addr_list[1] etc. are really pointers to structures of type in_addr So you should type cast them before using it in the inet_ntoa function. The inet_ntoa call would look like inet_ntoa(*(struct in_addr *)hostp->h_addr)
Please note that there is a mail archive hanging off the course web page at: http://www.cs.wisc.edu/~cs640-1/mail-archive.html Any general-interest mail sent to the class list is archived here. You will probably find the archive useful as a loosely-organized FAQ that you can go to first when you have questions. -- ,,, `o-o- < Ben. - .
I have been geeting questions regarding the inet_ntoa function, the hostent structure and struct in_addr. The hostent structure and in_addr structures are different. The hostent structure has a list of pointers to structures of type in_addr (this is the h_addr_list field of the hostent structure) The inet_addr could just be thought of as a 4 byte value which stores the internet address in some form The inet_ntoa() function converts the internet address from this form to a dotted-decimal form. You could read the first few pages in Chapter 8 of the book by Stevens (Unix Network Programming) to get more information on these -nsp
> > What should we do in case the client sends an ADDR request with an > invalid address? (i.e., what should the server return?) > For instance: > > client vega24.cs.wisc.edu ADDR invalid.cs.wisc.edu > > The server won't be able to translate invalid.cs.wisc.edu, should the > server print an error? Should it exit? Should it respond to the client > with some special error message? > > The server should respond to the client with an error message. use the type and string fields to convey an error message back to the client. (for e.g. the server could set the type field to a value indicating Error condition and send the error message in the string field) The server should NOT exit.
> I have a quick question about assignment #1. > You said at the end of your presentation that we couldn't simply take > our packet struct and send it because the integer fields wouldn't in > network order. But if we transform them into network order by using > htonl & hntos *before* we put them into the packet structure, can't we > simply send the the packet structure? > e.g., > packet.pack_type = htons(v1); > packet.filesize = htonl(v2); > strcpy(packet.name, v3); > sendto(sd, packet...); > > Does that work correctly (it works, but I'm not sure that it is in the > proper order)? > That would take care of the host and network byte order problem But then, the assignmnet specifies that the packet should have a 2 byte field, followed by a 4 byte field, followed by a string with maximum length 256. This defines the packet size to be maximum 262 bytes. If you send the packet structure as such you would be not be sending data in the same format as the specifications because you do not know the internal structure of a packet. What if the machine which receives data interprets the packet structure in a different format than the machine which sent the packet ? So the packet thats sent across the network, should match the specification EXACTLY. The first 2 bytes should the short field, the NEXT 4 bytes should be the data field and so on. You should be aware of what goes into EACH byte of the packet which is sent (which doesn't happen when you send the packet structure)
Here are answers to some questions I got: > > 1. Do we need to convert the string that the user inputs in the command line > using htons()? Since this is a character string and not a short or a long. No, Since the string is just a sequence of single byte characters (no integers involved) > > 2. Will the user input a number for the request type (i.e., 1 for ADDR, 2 > for FILEZISE) or do we need to expect ADDR and FILESIZE typed in this way > (i.e., all capital letters)? If so, should we send ADDR and FILESIZE too > to the server or can we use numbers to distinguish between them internally? > The user will type in ADDR or FILESIZE (not a number like 1 or 2) The user may type them in lowercase too. (addr or filesize) However when sending the type to the server you should use a short integer to distinguish them. (thats what the 2 byte type field in the packet is for) Just to give examples, heres what typical client requests will look like:- client sol10.cs.wisc.edu ADDR krusty.cs.wisc.edu (the first sol10.cs.wisc.edu is the name of the m/c where the server is running, ADDR is the request type and krusty.cs.wisc.edu is the name of the m/c you want to find the internet address for) The filesize request will look like client sol10.cs.wisc.edu FILESIZE testfile.c (FILESIZE is the request type and testfile.c is the name of the file) > 3. If the user requests FILESIZE, do we have to "look" for the existance > of this file within our home directory? What exactly is it that we should > do in this case? It is not clear in the handout when it says "print the > file name and the file size (or an error if the file doesn't exist)." > Also, if you actually mean a file in our home directory, how deep in our > account should we look for the file? In every directory? Lets make this real simple. You can assume that the filename specified is relative with respect to the current working directory of the server. So all you have to do is a stat() system call providing the name of the file which you got in the string field as the argument to stat().
There was a question about using TCP as the protocol for the type Datagrams (SOCK_DGRAM). Using TCP for datagrams will not work for the following reason:- TCP is a protocol which provides a connection-oriented protocol which provides byte-stream semantics. Datagrams by definition imply a connectionless approach and also the semantics are different from Streams (For e.g., in Datagrams message boundaries are preserved which is not the case in streams) I apologise for not being clear on this topic in class. -nsp
A note on the sample programs :- If you compile the sample client and server programs with the -Wall option you will see a lot of warnings saying "implicit declaration of function ..." This means that the appropriate header files for those functions are not included. You should try to AVOID these warnings by including the appropriate header files when you do your assignment. The man pages for a system call / library function usually specify the files which should be included. -nsp
The Deadline for assignment 1 is Wednesday, September 18. Apart from the code and a script output, you will also need to hand in your executables electronically. We will give more instructions on how to do that in a separate mail. Thanks nsp
One student had asked if there was a sample client/server code which he could compile and run it to see how the stuff works. I have made the sample client and server in the Besaw's tutorial available in ~cs640-1/public/assign1 You could use the following commands to get the client and server executables:- gcc -Wall client.c -lsocket -lnsl -o client gcc -Wall server.c -lsocket -lnsl -o server After this you could run the server as server 5000 (the 5000 is just a sample port no. you should be able to use any no. > 1024) run the client as follows client 5000 xxx (where xxx = name of the m/c where the server is running e.g. sol10.cs.wisc.edu) after this whatever you type in at the client should be displayed at the server (line by line) There were bugs in the code which appears in the tutorial. I have fixed them. However, I cannot guarantee full correctness. It seems to work well when I tried it. Anyway, this is just to give you a feel for the assignment. -nsp