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
o

CS 640 Mail List Archive


Auto-generated by a hideous Perl script on: Sat Nov 2 18:00:03 1996

Table of Contents

Better CVS documentation
Timer Hint
Please Sign up for 640 Project Meetings
Obnoxious Flame on 640 Project Design Documents
Office hours clarification
Office hours
calculators
midterm
Addendum to Limits Message
Routing Requirements Summarized
Limits on network configuration
About the Draft Design due This Friday
The Authoritative AAL7 Service Interface is Ready!
Design document evaluation form
aal7_send() Blocks Until When?
Using Multiple Sockets (addendum)
Using Multiple Sockets
What is a Protocol State Machine?
Error Warning Codes

Midterm Exam
TCP Spec
What is a struct aal7_sap ?
Re: You Must Tell Me Your Groups by Today
Initialization Hooks Added to AAL7 Service Interface
Clarification of SAP's, aal7_conn_desc's, etc.
Project Groups

First Assignments

Change in office hours this week
Policy on Remedial Questions
Re: Error in network.congif

Caching Virtual Circuits
Questions on Routing Alg
Error in network.congif
The Slides are Fixed!
Process Spawning Script now Available
Information on Solaris Threads...
Class Notes
Slides from Friday's Talk On-line
Mail Me Your Project Groups
Project Description On-Line
Handimg in hard copy
Clarification of Assignment 1 due Time
Assignment 1 due Time
Solaris / BSD Equivalences
Sample Makefile
Parallel Mail Archive
REVERSAL
undergrads
Project - Undergrads
Sending Structures
Handing in the First Assignment
Buffer size in recvfrom()
How Do You Get The Size Of A File?
If Message is Just Chars, why Worry About Network Order?
Note on inet_ntoa
Using the CS 640 HTML Mail Archive
inet_ntoa(), struct hostent, and struct in_addr
Handling an Invalid Address
Can't Just Send struct{...}
Clarification on Assign 1 Interface and where to Look for Files
TCP Protocol not Appropriate for Datagrams
Compiler Warnings for Sample Code
Assignment 1 Deadline
Besaw Sample Client/Server Code Now Available


Better CVS documentation


Date: Sat, 2 Nov 1996 17:49:30 -0600 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Better CVS documentation Sender: owner-cs640-1list@cs.wisc.edu



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.
                           -
                           .
   









Timer Hint


Date: Wed, 30 Oct 1996 19:37:29 -0600 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Timer Hint Sender: owner-cs640-1list@cs.wisc.edu


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);
}

Please Sign up for 640 Project Meetings


Date: Sun, 27 Oct 1996 21:50:47 -0600 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Please Sign up for 640 Project Meetings Sender: owner-cs640-1list@cs.wisc.edu


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

Obnoxious Flame on 640 Project Design Documents


Date: Sat, 26 Oct 1996 15:50:57 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Obnoxious Flame on 640 Project Design Documents Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Office hours clarification


Date: Tue, 22 Oct 1996 14:58:03 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Office hours clarification Sender: owner-cs640-1list@cs.wisc.edu

My office hours tomorrow will
be 4-6.
Sorry if i confused you in my previous mail,
nsp

Office hours


Date: Tue, 22 Oct 1996 14:55:29 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Office hours Sender: owner-cs640-1list@cs.wisc.edu

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

calculators


Date: Mon, 21 Oct 1996 09:42:42 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: calculators Sender: owner-cs640-1list@cs.wisc.edu

You may not use calculators for the test.

midterm


Date: Sun, 20 Oct 1996 17:13:02 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: midterm Sender: owner-cs640-1list@cs.wisc.edu

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.

Addendum to Limits Message


Date: Wed, 16 Oct 1996 16:10:42 -0500 From: Benjamin Teitelbaum To: cs640-1list@cs.wisc.edu Subject: Addendum to Limits Message Sender: owner-cs640-1list@cs.wisc.edu


>    * 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.
                           -
                           .
   







Routing Requirements Summarized


Date: Wed, 16 Oct 1996 16:07:50 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Routing Requirements Summarized Sender: owner-cs640-1list@cs.wisc.edu


  * 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


Limits on network configuration


Date: Tue, 15 Oct 1996 16:49:09 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Limits on network configuration Sender: owner-cs640-1list@cs.wisc.edu

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

About the Draft Design due This Friday


Date: Tue, 15 Oct 1996 15:03:18 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: About the Draft Design due This Friday Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







The Authoritative AAL7 Service Interface is Ready!


Date: Sun, 13 Oct 1996 11:36:06 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: The Authoritative AAL7 Service Interface is Ready! Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Design document evaluation form


Date: Fri, 11 Oct 1996 17:42:17 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Design document evaluation form Sender: owner-cs640-1list@cs.wisc.edu

The evalution form for the project design
document is available online (in postscript form)
-nsp

aal7_send() Blocks Until When?


Date: Fri, 11 Oct 1996 15:20:50 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: aal7_send() Blocks Until When? Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Using Multiple Sockets (addendum)


Date: Thu, 10 Oct 1996 17:29:02 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Using Multiple Sockets (addendum) Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Using Multiple Sockets


Date: Thu, 10 Oct 1996 17:16:31 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Using Multiple Sockets Sender: owner-cs640-1list@cs.wisc.edu

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

What is a Protocol State Machine?


From: Benjamin Teitelbaum Date: Wed, 9 Oct 1996 16:13:26 -0500 To: cs640-1list@alfred.cs.wisc.edu Subject: What is a Protocol State Machine? Sender: owner-cs640-1list@cs.wisc.edu


See page 294 of your textbook for an example.

-- 

                         ,,,

                        `o-o-
                          <    Ben.
                           -
                           .
   








Error Warning Codes


Date: Wed, 9 Oct 1996 13:56:37 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: Error Warning Codes Sender: owner-cs640-1list@cs.wisc.edu

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 To: cs640-1list@parmesan.cs.wisc.edu Sender: owner-cs640-1list@cs.wisc.edu

I apologize for again forgetting to bring the assignments. You can
come by my office to pick yours up.

Midterm Exam


Date: Tue, 8 Oct 1996 15:14:04 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: Midterm Exam Cc: ben@parmesan.cs.wisc.edu, lhl@parmesan.cs.wisc.edu,
        nsp@parmesan.cs.wisc.edu

132 Noland 
Wednesday, October 23
7:15-9:15 PM

TCP Spec


Date: Tue, 8 Oct 1996 11:03:13 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: TCP Spec Sender: owner-cs640-1list@cs.wisc.edu

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.

What is a struct aal7_sap ?


Date: Fri, 4 Oct 1996 16:45:17 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: What is a struct aal7_sap ? Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Re: You Must Tell Me Your Groups by Today


Date: Fri, 4 Oct 1996 10:53:50 -0500 From: Lawrence Landweber To: ben@cs.wisc.edu Subject: Re: You Must Tell Me Your Groups by Today Cc: cs640-1list@alfred.cs.wisc.edu Sender: owner-cs640-1list@cs.wisc.edu

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.

Initialization Hooks Added to AAL7 Service Interface


Date: Wed, 2 Oct 1996 12:04:04 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Initialization Hooks Added to AAL7 Service Interface Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Clarification of SAP's, aal7_conn_desc's, etc.


Date: Wed, 2 Oct 1996 11:32:05 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Clarification of SAP's, aal7_conn_desc's, etc. Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Project Groups


Date: Wed, 2 Oct 1996 11:25:59 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Project Groups Sender: owner-cs640-1list@cs.wisc.edu


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 To: edwins@cs.wisc.edu CC: cs640-1list@alfred.cs.wisc.edu In-reply-to:
	(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.
                           -
                           .
   







First Assignments


Date: Tue, 1 Oct 1996 14:51:35 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: First Assignments Sender: owner-cs640-1list@cs.wisc.edu


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 To: swanderb@cs.wisc.edu CC: nsp@maggie.cs.wisc.edu, cs640-1list@alfred.cs.wisc.edu In-reply-to: <199609251405.JAA06889@maggie.cs.wisc.edu> (message from Brian
	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.
                           -
                           .
   







Change in office hours this week


Date: Sun, 29 Sep 1996 23:10:15 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Change in office hours this week Sender: owner-cs640-1list@cs.wisc.edu

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

Policy on Remedial Questions


Date: Sun, 29 Sep 1996 16:00:24 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Policy on Remedial Questions Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Re: Error in network.congif


Date: Fri, 27 Sep 1996 09:30:58 -0500 From: Benjamin Teitelbaum To: luke_blanshard@vnp.com CC: cs640-1list@alfred.cs.wisc.edu Subject: Re: Error in network.congif Sender: owner-cs640-1list@cs.wisc.edu


> 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 To: haris@cs.wisc.edu CC: nsp@sol2.cs.wisc.edu, cs640-1list@alfred.cs.wisc.edu In-reply-to: <199609240133.UAA04498@sol2.cs.wisc.edu> (message from Haris
	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.
                           -
                           .
   







Caching Virtual Circuits


Date: Thu, 26 Sep 1996 15:50:36 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Caching Virtual Circuits Sender: owner-cs640-1list@cs.wisc.edu


> 
> 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.
                           -
                           .
   







Questions on Routing Alg


Date: Thu, 26 Sep 1996 15:49:43 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Questions on Routing Alg Sender: owner-cs640-1list@cs.wisc.edu


> 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.
                           -
                           .
   







Error in network.congif


Date: Thu, 26 Sep 1996 15:24:30 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Error in network.congif Sender: owner-cs640-1list@cs.wisc.edu

> 
> 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 Slides are Fixed!


Date: Thu, 26 Sep 1996 15:20:27 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: The Slides are Fixed! Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Process Spawning Script now Available


Date: Thu, 26 Sep 1996 15:09:40 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Process Spawning Script now Available Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Information on Solaris Threads...


Date: Wed, 25 Sep 1996 09:41:26 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Information on Solaris Threads... Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Class Notes


Date: Tue, 24 Sep 1996 14:29:24 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: Class Notes Sender: owner-cs640-1list@cs.wisc.edu

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.

Slides from Friday's Talk On-line


Date: Mon, 23 Sep 1996 23:03:40 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Slides from Friday's Talk On-line Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Mail Me Your Project Groups


Date: Thu, 19 Sep 1996 14:40:26 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Mail Me Your Project Groups Sender: owner-cs640-1list@cs.wisc.edu


When you have a group of three together, please mail me (ben) your
names and usernames.  Thanks,

-- 

                         ,,,

                        `o-o-
                          <    Ben.
                           -
                           .
   







Project Description On-Line


Date: Thu, 19 Sep 1996 14:37:33 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Project Description On-Line Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Handimg in hard copy


Date: Wed, 18 Sep 1996 16:59:36 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Handimg in hard copy Sender: owner-cs640-1list@cs.wisc.edu

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

Clarification of Assignment 1 due Time


Date: Tue, 17 Sep 1996 21:39:18 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Clarification of Assignment 1 due Time Sender: owner-cs640-1list@cs.wisc.edu


> 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.
                           -
                           .
   







Assignment 1 due Time


Date: Tue, 17 Sep 1996 21:25:26 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Assignment 1 due Time Sender: owner-cs640-1list@cs.wisc.edu


Because, It's very important that everyone get the first assignment
working, the deadline for submitting is midnight tomorrow.

-- 

                         ,,,

                        `o-o-
                          <    Ben.
                           -
                           .
   







Solaris / BSD Equivalences


Date: Tue, 17 Sep 1996 20:46:32 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Solaris / BSD Equivalences Sender: owner-cs640-1list@cs.wisc.edu


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.

Sample Makefile


Date: Tue, 17 Sep 1996 16:12:17 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Sample Makefile Sender: owner-cs640-1list@cs.wisc.edu


# 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

Parallel Mail Archive


Date: Tue, 17 Sep 1996 14:08:52 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Parallel Mail Archive Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







REVERSAL


Date: Mon, 16 Sep 1996 19:18:47 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: REVERSAL Sender: owner-cs640-1list@cs.wisc.edu

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.


undergrads


Date: Mon, 16 Sep 1996 18:18:35 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: undergrads Sender: owner-cs640-1list@cs.wisc.edu

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.

Project - Undergrads


Date: Mon, 16 Sep 1996 16:02:08 -0500 From: Lawrence Landweber To: cs640-1list@parmesan.cs.wisc.edu Subject: Project - Undergrads Sender: owner-cs640-1list@cs.wisc.edu

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.

Sending Structures


Date: Mon, 16 Sep 1996 14:20:23 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Sending Structures Sender: owner-cs640-1list@cs.wisc.edu

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

Handing in the First Assignment


Date: Sun, 15 Sep 1996 15:14:11 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Handing in the First Assignment Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







Buffer size in recvfrom()


Date: Sat, 14 Sep 1996 16:19:10 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Buffer size in recvfrom() Sender: owner-cs640-1list@cs.wisc.edu

> 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. 

How Do You Get The Size Of A File?


Date: Fri, 13 Sep 1996 09:39:24 -0500 From: Benjamin Teitelbaum To: edwins@cs.wisc.edu CC: cs640-1list@alfred.cs.wisc.edu Subject: How Do You Get The Size Of A File? Sender: owner-cs640-1list@cs.wisc.edu


> 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.
                           -
                           .
   







If Message is Just Chars, why Worry About Network Order?


Date: Thu, 12 Sep 1996 20:48:07 -0500 From: Benjamin Teitelbaum To: yetkin@cs.wisc.edu CC: cs640-1list@alfred.cs.wisc.edu, nsp@sol27.cs.wisc.edu Subject: If Message is Just Chars, why Worry About Network Order? Sender: owner-cs640-1list@cs.wisc.edu


> 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.
                           -
                           .
   







Note on inet_ntoa


Date: Thu, 12 Sep 1996 15:55:41 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Note on inet_ntoa Sender: owner-cs640-1list@cs.wisc.edu


> 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)

Using the CS 640 HTML Mail Archive


Date: Wed, 11 Sep 1996 15:55:35 -0500 From: Benjamin Teitelbaum To: cs640-1list@alfred.cs.wisc.edu Subject: Using the CS 640 HTML Mail Archive Sender: owner-cs640-1list@cs.wisc.edu


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.
                           -
                           .
   







inet_ntoa(), struct hostent, and struct in_addr


Date: Wed, 11 Sep 1996 15:24:11 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: inet_ntoa(), struct hostent, and struct in_addr Sender: owner-cs640-1list@cs.wisc.edu

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

Handling an Invalid Address


From: Srinivasa Narayanan Subject: Handling an Invalid Address To: siman@cs.wisc.edu (Jose F. Siman) Date: Wed, 11 Sep 1996 14:06:35 -0500 (CDT) Cc: cs640-1list@cs.wisc.edu In-Reply-To: from "Jose F. Siman" at Sep 11, 96 01:54:11 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cs640-1list@cs.wisc.edu

> 
> 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. 

Can't Just Send struct{...}


From: Srinivasa Narayanan Subject: Can't Just Send struct{...} To: geery@cs.wisc.edu (Andrew Geery) Date: Wed, 11 Sep 1996 13:38:24 -0500 (CDT) Cc: cs640-1list@cs.wisc.edu In-Reply-To: <323703DE.1586@cs.wisc.edu> from "Andrew Geery" at Sep 11, 96 01:24:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cs640-1list@cs.wisc.edu

> 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)

Clarification on Assign 1 Interface and where to Look for Files


From: Srinivasa Narayanan Subject: Clarification on Assign 1 Interface and where to Look for Files To: cs640-1list@cs.wisc.edu Date: Wed, 11 Sep 1996 11:15:54 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cs640-1list@cs.wisc.edu

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(). 

TCP Protocol not Appropriate for Datagrams


Date: Wed, 11 Sep 1996 10:58:56 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: TCP Protocol not Appropriate for Datagrams Sender: owner-cs640-1list@cs.wisc.edu

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

Compiler Warnings for Sample Code


Date: Wed, 11 Sep 1996 10:05:06 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Compiler Warnings for Sample Code Sender: owner-cs640-1list@cs.wisc.edu

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

Assignment 1 Deadline


Date: Tue, 10 Sep 1996 16:02:50 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Assignment 1 Deadline Sender: owner-cs640-1list@cs.wisc.edu

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

Besaw Sample Client/Server Code Now Available


Date: Mon, 9 Sep 1996 15:34:18 -0500 From: Srinivasa Narayanan To: cs640-1list@cs.wisc.edu Subject: Besaw Sample Client/Server Code Now Available Sender: owner-cs640-1list@cs.wisc.edu

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