su.class.cs244a

Path: shelby.stanford.edu!not-for-mail
From: Benjamin Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [CS244a] Bookstore is selling a different textbook
Date: Mon, 08 Jan 2007 09:11:13 -0800
Lines: 7
Distribution: su
Message-ID: <45A27B31.6090905@stanford.edu>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168276274 21872 128.12.94.22 (8 Jan 2007 17:11:14 GMT)
X-Complaints-To: news@news.stanford.edu
To:  nickm@stanford.edu
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
Xref: shelby.stanford.edu su.class.cs244a:10902

The bookstore is selling the Kurose and Ross book (ISBN 0321227352).

The website links to the Peterson and Davie book (ISBN 155860832X).

Which is correct?

Ben
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [CS244a] Bookstore is selling a different textbook
Date: Mon, 08 Jan 2007 09:43:05 -0800
Lines: 12
Distribution: su
Message-ID: <entvr2$mt8$1@news.Stanford.EDU>
References: <45A27B31.6090905@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168278178 23464 127.0.0.1 (8 Jan 2007 17:42:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <45A27B31.6090905@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10903

Benjamin Nham wrote:
> The bookstore is selling the Kurose and Ross book (ISBN 0321227352).
> 
> The website links to the Peterson and Davie book (ISBN 155860832X).
> 
> Which is correct?
> 
> Ben

Kurose and Ross is the correct book.

-David
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Book Edition
Date: Tue, 09 Jan 2007 09:31:08 -0800
Lines: 2
Distribution: su
Message-ID: <paun-B1D1CE.09310709012007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1168363867 13824 128.12.135.184 (9 Jan 2007 17:31:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:10904

Is it okay to use the 2nd edition of the book or are there significant 
changes between the two editions that the 3rd edition is required?
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Book Edition
Date: Tue, 09 Jan 2007 13:59:23 -0800
Lines: 15
Distribution: su
Message-ID: <C1C9503B.7306%jpettit@stanford.edu>
References: <paun-B1D1CE.09310709012007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168379966 29144 127.0.0.1 (9 Jan 2007 21:59:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Book Edition
Thread-Index: Acc0OWvRqkAmXqAsEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10905

Hi, Filip.  We switched to a completely different textbook this year, so we
don't know how different the 2nd edition is.  You are going to need to do
some problems out of the book, so the mapping between the editions may be
difficult to track.  I'd recommend getting the 3rd edition.

--Justin


On 1/9/07 9:31 AM, in article paun-B1D1CE.09310709012007@nntp.stanford.edu,
"Filip Paun" <paun@stanford.edu> wrote:

> Is it okay to use the 2nd edition of the book or are there significant
> changes between the two editions that the 3rd edition is required?


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Handout Drawer
Date: Tue, 09 Jan 2007 16:16:05 -0800
Lines: 8
Distribution: su
Message-ID: <C1C97045.731E%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168388162 7468 127.0.0.1 (10 Jan 2007 00:16:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Handout Drawer
Thread-Index: Acc0TISXw0z86aA/EduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10906

We have setup a drawer that will hold extra printings of the handouts and
any graded assignments that have not been picked up.  If you come out of the
elevators on the third floor and hook a left, you will see a number of
filing cabinets once you pass the hallway.  It is the bottom drawer on the
first set of cabinets on your left.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Linux Access
Date: Tue, 09 Jan 2007 17:02:06 -0800
Lines: 18
Distribution: su
Message-ID: <C1C97B0E.7329%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168390924 10344 127.0.0.1 (10 Jan 2007 01:02:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Linux Access
Thread-Index: Acc0UvJGMMFBmaBGEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10907

I've already gotten questions about where you should do your development.
I'd recommend working on the Xenon systems.  To logon, you'll need a SUNet
id.  If you have a Stanford email address, this is your SUNet id.  If not,
you can set one up here:

    http://sunetid.stanford.edu/

If you are an NDO student and don't have a student id yet, you should
contact HelpSU by phone (650-725-HELP) or file a HelpSU ticket:

    http://helpsu.stanford.edu/

Once you have a SUNet account, you should be able to SSH into Xenons:

    ssh <userid>@xenon.stanford.edu

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Parsing HTTP Request
Date: Wed, 10 Jan 2007 08:09:45 +0000 (UTC)
Lines: 5
Distribution: su
Message-ID: <eo2709$44m$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine35.stanford.edu
X-Trace: news.Stanford.EDU 1168416585 4246 171.64.15.110 (10 Jan 2007 08:09:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:10908


Is the proxy supposed to parse the HTTP request according to the specifications 
in the RFC and ensure it is syntactically correct before forwarding the request
to the server? 
Wanted to confirm this as parsing the request takes up a major portion of the code. 
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing HTTP Request
Date: Wed, 10 Jan 2007 09:35:50 -0800
Lines: 10
Distribution: su
Message-ID: <eo385b$3hl$1@news.Stanford.EDU>
References: <eo2709$44m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168450539 3637 127.0.0.1 (10 Jan 2007 17:35:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo2709$44m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10909

Dina Thomas wrote:
> Is the proxy supposed to parse the HTTP request according to the specifications 
> in the RFC and ensure it is syntactically correct before forwarding the request
> to the server? 
> Wanted to confirm this as parsing the request takes up a major portion of the code. 

Yes, if you receive a malformed request from the client it is your 
responsibility to return an appropriate error code, per the RFC.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: No Office Hours This Week
Date: Wed, 10 Jan 2007 10:11:18 -0800
Lines: 6
Distribution: su
Message-ID: <C1CA6C46.7363%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168452678 6031 127.0.0.1 (10 Jan 2007 18:11:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: No Office Hours This Week
Thread-Index: Acc04rlV9/LOXKDVEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10910

Since the first assignment has not officially kicked off, none of the TAs
are going to hold office hours this week.  We will be checking the
newsgroups as usual, though, so post any questions you have here.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Linux Access
Date: Wed, 10 Jan 2007 13:37:56 -0800
Lines: 31
Distribution: su
Message-ID: <C1CA9CB4.7377%jpettit@stanford.edu>
References: <C1C97B0E.7329%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168465075 16873 127.0.0.1 (10 Jan 2007 21:37:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Linux Access
Thread-Index: Acc0UvJGMMFBmaBGEduVdAARJDbi7gArKTah
Xref: shelby.stanford.edu su.class.cs244a:10911

I've heard that Xenon is only available to CS students.  You are all
probably better off using the Myths instead:

    ssh <userid>@myth.stanford.edu

--Justin


On 1/9/07 5:02 PM, in article C1C97B0E.7329%jpettit@stanford.edu, "Justin
Pettit" <jpettit@stanford.edu> wrote:

> I've already gotten questions about where you should do your development.
> I'd recommend working on the Xenon systems.  To logon, you'll need a SUNet
> id.  If you have a Stanford email address, this is your SUNet id.  If not,
> you can set one up here:
> 
>     http://sunetid.stanford.edu/
> 
> If you are an NDO student and don't have a student id yet, you should
> contact HelpSU by phone (650-725-HELP) or file a HelpSU ticket:
> 
>     http://helpsu.stanford.edu/
> 
> Once you have a SUNet account, you should be able to SSH into Xenons:
> 
>     ssh <userid>@xenon.stanford.edu
> 
> --Justin
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on Assignment 1: What to read next?
Date: Wed, 10 Jan 2007 16:05:16 -0800
Lines: 13
Distribution: su
Message-ID: <eo3uvm$ofj$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168473911 25075 128.12.194.72 (11 Jan 2007 00:05:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:10912

Hey guys,

I've read the assignment 1 overview, but I'm not sure what my next step
should be. Since I have no idea on how to get started with the project, 
what should I read next? The RFC? Ch. 3-5 in the Unix socket programming 
book? Or Ch. 1-2 in the Kurose book?

Also, when and where will be the Friday discussion sections be held? 
Will they be web-cast?

Any guidance would be appreciated (those from the TAs especially). Thanks.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on Assignment 1: What to read next?
Date: Wed, 10 Jan 2007 18:38:33 -0800
Lines: 24
Distribution: su
Message-ID: <eo47uu$2o6$1@news.Stanford.EDU>
References: <eo3uvm$ofj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168483102 2822 127.0.0.1 (11 Jan 2007 02:38:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo3uvm$ofj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10913

Yangfan Wang wrote:
> Hey guys,
> 
> I've read the assignment 1 overview, but I'm not sure what my next step
> should be. Since I have no idea on how to get started with the project, 
> what should I read next? The RFC? Ch. 3-5 in the Unix socket programming 
> book? Or Ch. 1-2 in the Kurose book?

I would read Ch 1-2 in the Kurose book first as there is discussion in 
there about HTTP requests and responses as well as elementary socket 
discussion.  When you start the assignment you'll need to read both the 
Unix socket programming book and the RFC.

> Also, when and where will be the Friday discussion sections be held? 
> Will they be web-cast?

Please see the front page of the website:
"Discussion Section: Fridays 11:00-11:50AM, Gates B03, Live on E3"

> Any guidance would be appreciated (those from the TAs especially). Thanks.
> 
> -Yangfan

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Linux Access
Date: Wed, 10 Jan 2007 18:39:44 -0800
Lines: 13
Distribution: su
Message-ID: <eo4815$2o6$2@news.Stanford.EDU>
References: <C1C97B0E.7329%jpettit@stanford.edu> <C1CA9CB4.7377%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168483173 2822 127.0.0.1 (11 Jan 2007 02:39:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1CA9CB4.7377%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10914

Justin Pettit wrote:
> I've heard that Xenon is only available to CS students.  You are all
> probably better off using the Myths instead:
> 
>     ssh <userid>@myth.stanford.edu
> 
> --Justin

Also beware sometimes the ssh login hangs to the Myths (don't ask me 
why), but usually if you just let it sit there for a bit it will 
eventually go through.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: HTTP Request grammar is strict?
Date: Thu, 11 Jan 2007 03:23:00 +0000 (UTC)
Lines: 6
Distribution: su
Message-ID: <eo4aik$4ls$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine6.stanford.edu
X-Trace: news.Stanford.EDU 1168485780 4796 171.64.15.71 (11 Jan 2007 03:23:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:10915


Though the RFC seems to indicate that there is one space in the simple-request, 
multiple spaces and tabs did not produce an error when I tried with telnet 
on port 80. 
Does this suggest we have to handle such cases gracefully? 
In addition, do we need to handle the case where a line is ended with newline only and not CRLF?
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HTTP Request grammar is strict?
Date: Wed, 10 Jan 2007 19:36:43 -0800
Lines: 21
Distribution: su
Message-ID: <eo4bc1$5dm$1@news.Stanford.EDU>
References: <eo4aik$4ls$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168486593 5558 127.0.0.1 (11 Jan 2007 03:36:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo4aik$4ls$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10916

Dina Thomas wrote:
> Though the RFC seems to indicate that there is one space in the simple-request, 
> multiple spaces and tabs did not produce an error when I tried with telnet 
> on port 80. 
> Does this suggest we have to handle such cases gracefully? 

You must comply with the RFC, there are areas of it that are notably 
ambiguous, so yes you need to handle the cases gracefully.  A good test 
is to see if they work on production servers, as you have tried.

> In addition, do we need to handle the case where a line is ended with newline only and not CRLF?

Please carefully read the RFC:
5.1  Request-Line

    The Request-Line begins with a method token, followed by the
    Request-URI and the protocol version, and ending with CRLF. The
    elements are separated by SP characters. No CR or LF are allowed
    except in the final CRLF sequence.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: HTTP Request grammar is strict?
Date: Thu, 11 Jan 2007 04:04:39 +0000 (UTC)
Lines: 7
Distribution: su
Message-ID: <eo4d0n$6e2$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine6.stanford.edu
X-Trace: news.Stanford.EDU 1168488279 6594 171.64.15.71 (11 Jan 2007 04:04:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:10917



What I wanted to ask is whether we can have a Request-line 
ended only with LF instead of CRLF?
Isn't LF='\n' and CR='\r'? So when we use the 'enter' key 
on the keyboard it corresponds to '\n'?

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HTTP Request grammar is strict?
Date: Wed, 10 Jan 2007 20:10:51 -0800
Lines: 18
Distribution: su
Message-ID: <eo4dc0$6l0$1@news.Stanford.EDU>
References: <eo4d0n$6e2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168488640 6816 127.0.0.1 (11 Jan 2007 04:10:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo4d0n$6e2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10918

Dina Thomas wrote:
> What I wanted to ask is whether we can have a Request-line 
> ended only with LF instead of CRLF?
> Isn't LF='\n' and CR='\r'? So when we use the 'enter' key 
> on the keyboard it corresponds to '\n'?
> 

The RFC clearly states the line must end with CRLF, a LF without a CR in 
front if it is an error, and vice versa.  The answer to 'isn't enter 
just sending a LF', well, it depends.  It depends on your OS and how 
your telnet application is interpreting the enter key.  I recommend 
reading the wikipedia article on the topic, it was very enlightening for 
me. http://en.wikipedia.org/wiki/Newline  But I do believe the telnet 
app is sending CRLF.

Hope that helps.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: link to cs106x coding style pdf is broken
Date: Wed, 10 Jan 2007 20:49:06 -0800
Lines: 11
Distribution: su
Message-ID: <eo4fiu$89u$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168490910 8510 127.0.0.1 (11 Jan 2007 04:48:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10919

I went to the cs106x web page and cannot find the 106x pdf linked to on 
http://www.stanford.edu/class/cs244a/CS244aCodingGuidelines.html either.

Any idea if it is still around somewhere?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: link to cs106x coding style pdf is broken
Date: Wed, 10 Jan 2007 21:52:36 -0800
Lines: 17
Distribution: su
Message-ID: <eo4jap$asi$1@news.Stanford.EDU>
References: <eo4fiu$89u$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168494745 11154 127.0.0.1 (11 Jan 2007 05:52:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo4fiu$89u$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10920

Randy Jennings wrote:
> I went to the cs106x web page and cannot find the 106x pdf linked to on 
> http://www.stanford.edu/class/cs244a/CS244aCodingGuidelines.html either.
> 
> Any idea if it is still around somewhere?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 

I couldn't find a readily accessible copy but I'll check in to it. 
Thanks for the pointer.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: maximum url length
Date: Thu, 11 Jan 2007 11:49:44 -0800
Lines: 10
Distribution: su
Message-ID: <eo64cm$sp8$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434dec.stanford.edu
X-Trace: news.Stanford.EDU 1168544982 29480 171.67.77.236 (11 Jan 2007 19:49:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10921

1) can we make any assumptions about the maximum length of request-uri?

2) Also, can we make any assumptions about the maximum length of 
header:<value> pair?

The rfc does not put any limitations on their size. Does this mean that we 
have to accommodate "request-line", "response-line" and "header-lines" of 
unbounded size? 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Nick's Office Hours Changed to Tuesday 2:30-3:30PM
Date: Thu, 11 Jan 2007 15:55:06 -0800
Lines: 1
Distribution: su
Message-ID: <eo6iom$cv2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168559702 13282 127.0.0.1 (11 Jan 2007 23:55:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:10922

See Subject.
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: balanced tree/hash table
Date: Thu, 11 Jan 2007 21:05:25 -0800
Lines: 17
Distribution: su
Message-ID: <eo74tg$s3s$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168578288 28796 127.0.0.1 (12 Jan 2007 05:04:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10923

I know the first assignment can be done in C or C++, but I am trying to 
start with C now.  Unfortunately, I am suffering withdrawal from STL.

I was wondering if there was a C library with balanced trees (or a hash 
table) that we could use?  I have heard of CS140 having access to such 
things.  These structures are non-trivial; if it was just a ring buffer or 
something like that, I would write it myself.

If not, may I just use the hashing function found at:
http://burtleburtle.net/bob/c/lookup3.c?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Windows Only Access
Date: Thu, 11 Jan 2007 21:17:12 -0800
Lines: 8
Distribution: su
Message-ID: <eo75kt$slj$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168579039 29363 127.0.0.1 (12 Jan 2007 05:17:19 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:10924

I am a distance student and only have access to Windows XP.  Does anyone 
have a recommendation for the best program/enviroment to access the Lab 
servers and to develop the programming assignments in?

Thanks,
--Brian 


.

Path: shelby.stanford.edu!not-for-mail
From: Benjamin Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Windows Only Access
Date: Thu, 11 Jan 2007 21:32:14 -0800
Lines: 26
Distribution: su
Message-ID: <eo76h0$n$1@news.Stanford.EDU>
References: <eo75kt$slj$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168579936 23 128.12.94.22 (12 Jan 2007 05:32:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eo75kt$slj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10925

You probably should download an ssh client like securecrt or putty. Then 
connect to a machine like myth or bramble or another leland machine:

http://www.stanford.edu/services/unixcomputing/which.html

Usually I use myth or hedge (note that hedge runs 64-bit linux, not sure 
if that will impact any of these assignments).

If you want to open X windows you should probably also install a local x 
server like XMing and turn on X11 forwarding in your ssh client so you 
can open xterms and so forth.

Note that I'm just another student, I'm sure the staff will have some 
ideas as well.

Ben

Brian Thompson wrote:
> I am a distance student and only have access to Windows XP.  Does anyone 
> have a recommendation for the best program/enviroment to access the Lab 
> servers and to develop the programming assignments in?
> 
> Thanks,
> --Brian 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Windows Only Access
Date: Thu, 11 Jan 2007 22:16:03 -0800
Lines: 41
Distribution: su
Message-ID: <C1CC67A3.7423%jpettit@stanford.edu>
References: <eo75kt$slj$1@news.Stanford.EDU> <eo76h0$n$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168582560 2154 127.0.0.1 (12 Jan 2007 06:16:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Windows Only Access
Thread-Index: Acc2ESLTYTi2NqIEEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10926

I think you pretty well covered it!  Here's a link to PuTTY, which I've had
pretty good luck with:

    http://www.chiark.greenend.org.uk/~sgtatham/putty/

Thanks,

--Justin


On 1/11/07 9:32 PM, in article eo76h0$n$1@news.Stanford.EDU, "Benjamin Nham"
<nham@stanford.edu> wrote:

> You probably should download an ssh client like securecrt or putty. Then
> connect to a machine like myth or bramble or another leland machine:
> 
> http://www.stanford.edu/services/unixcomputing/which.html
> 
> Usually I use myth or hedge (note that hedge runs 64-bit linux, not sure
> if that will impact any of these assignments).
> 
> If you want to open X windows you should probably also install a local x
> server like XMing and turn on X11 forwarding in your ssh client so you
> can open xterms and so forth.
> 
> Note that I'm just another student, I'm sure the staff will have some
> ideas as well.
> 
> Ben
> 
> Brian Thompson wrote:
>> I am a distance student and only have access to Windows XP.  Does anyone
>> have a recommendation for the best program/enviroment to access the Lab
>> servers and to develop the programming assignments in?
>> 
>> Thanks,
>> --Brian 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Windows Only Access
Date: Thu, 11 Jan 2007 22:26:23 -0800
Lines: 48
Distribution: su
Message-ID: <eo79mo$2hh$1@news.Stanford.EDU>
References: <eo75kt$slj$1@news.Stanford.EDU> <eo76h0$n$1@news.Stanford.EDU> <C1CC67A3.7423%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168583194 2609 127.0.0.1 (12 Jan 2007 06:26:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:10927

Thanks I'll give that a try and hopefully get cooking on this assignment.

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1CC67A3.7423%jpettit@stanford.edu...
>I think you pretty well covered it!  Here's a link to PuTTY, which I've had
> pretty good luck with:
>
>    http://www.chiark.greenend.org.uk/~sgtatham/putty/
>
> Thanks,
>
> --Justin
>
>
> On 1/11/07 9:32 PM, in article eo76h0$n$1@news.Stanford.EDU, "Benjamin 
> Nham"
> <nham@stanford.edu> wrote:
>
>> You probably should download an ssh client like securecrt or putty. Then
>> connect to a machine like myth or bramble or another leland machine:
>>
>> http://www.stanford.edu/services/unixcomputing/which.html
>>
>> Usually I use myth or hedge (note that hedge runs 64-bit linux, not sure
>> if that will impact any of these assignments).
>>
>> If you want to open X windows you should probably also install a local x
>> server like XMing and turn on X11 forwarding in your ssh client so you
>> can open xterms and so forth.
>>
>> Note that I'm just another student, I'm sure the staff will have some
>> ideas as well.
>>
>> Ben
>>
>> Brian Thompson wrote:
>>> I am a distance student and only have access to Windows XP.  Does anyone
>>> have a recommendation for the best program/enviroment to access the Lab
>>> servers and to develop the programming assignments in?
>>>
>>> Thanks,
>>> --Brian
>>>
>>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: maximum url length
Date: Thu, 11 Jan 2007 22:28:14 -0800
Lines: 23
Distribution: su
Message-ID: <C1CC6A7E.742A%jpettit@stanford.edu>
References: <eo64cm$sp8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168583289 2645 127.0.0.1 (12 Jan 2007 06:28:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: maximum url length
Thread-Index: Acc2EtaJFNcyyqIGEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10928

In both cases, I'd recommend growing the buffer to some reasonable limit
(such as 8KB or 16KB).  Legitimate requests can be quite large, however, you
don't want your system open to a denial of service attack.  Make sure to
document your design decisions in the README file.

--Justin


On 1/11/07 11:49 AM, in article eo64cm$sp8$1@news.Stanford.EDU, "manj"
<manj@stanford.edu> wrote:

> 1) can we make any assumptions about the maximum length of request-uri?
> 
> 2) Also, can we make any assumptions about the maximum length of
> header:<value> pair?
> 
> The rfc does not put any limitations on their size. Does this mean that we
> have to accommodate "request-line", "response-line" and "header-lines" of
> unbounded size? 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: balanced tree/hash table
Date: Thu, 11 Jan 2007 22:33:27 -0800
Lines: 29
Distribution: su
Message-ID: <C1CC6BB7.742D%jpettit@stanford.edu>
References: <eo74tg$s3s$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168583605 2877 127.0.0.1 (12 Jan 2007 06:33:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: balanced tree/hash table
Thread-Index: Acc2E5EZz+rFaKIGEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10929

Sorry to do this to you, Randy, but we would like everyone to stick with
standard libraries and STL.  The concern is that it could really complicate
things--especially the grading.

--Justin


On 1/11/07 9:05 PM, in article eo74tg$s3s$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> I know the first assignment can be done in C or C++, but I am trying to
> start with C now.  Unfortunately, I am suffering withdrawal from STL.
> 
> I was wondering if there was a C library with balanced trees (or a hash
> table) that we could use?  I have heard of CS140 having access to such
> things.  These structures are non-trivial; if it was just a ring buffer or
> something like that, I would write it myself.
> 
> If not, may I just use the hashing function found at:
> http://burtleburtle.net/bob/c/lookup3.c?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Section Slides Posted
Date: Fri, 12 Jan 2007 12:53:49 -0800
Lines: 4
Distribution: su
Message-ID: <eo8shv$n55$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168635263 23717 171.64.74.54 (12 Jan 2007 20:54:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:10930

Powerpoint slides from today's section are now posted on the website. 
We'll hopefully have a PDF version of them available later on.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Section Slides Posted
Date: Fri, 12 Jan 2007 13:16:29 -0800
Lines: 14
Distribution: su
Message-ID: <C1CD3AAD.745F%jpettit@stanford.edu>
References: <eo8shv$n55$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168636584 25027 127.0.0.1 (12 Jan 2007 21:16:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Section Slides Posted
Thread-Index: Acc2juzVK0l3bKKCEduVdAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10931

A PDF version has been posted.

--Justin


On 1/12/07 12:53 PM, in article eo8shv$n55$1@news.Stanford.EDU, "Clay
Collier" <ccollier@stanford.edu> wrote:

> Powerpoint slides from today's section are now posted on the website.
> We'll hopefully have a PDF version of them available later on.
> 
> Clay


.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Section Slides Posted
Date: Fri, 12 Jan 2007 19:57:40 -0800
Lines: 21
Distribution: su
Message-ID: <Pine.LNX.4.62.0701121957030.1022@xenon.Stanford.EDU>
References: <eo8shv$n55$1@news.Stanford.EDU> <C1CD3AAD.745F%jpettit@stanford.edu>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1168660663 16275 171.64.66.201 (13 Jan 2007 03:57:43 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <C1CD3AAD.745F%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10932

In one of the slides, it mentions this "man pages (section 2)", where is 
this man page that you guys are talking about? Thanks.

On Fri, 12 Jan 2007, 
Justin Pettit wrote:

> A PDF version has been posted.
>
> --Justin
>
>
> On 1/12/07 12:53 PM, in article eo8shv$n55$1@news.Stanford.EDU, "Clay
> Collier" <ccollier@stanford.edu> wrote:
>
>> Powerpoint slides from today's section are now posted on the website.
>> We'll hopefully have a PDF version of them available later on.
>>
>> Clay
>
>
>
.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Section Slides Posted
Date: Fri, 12 Jan 2007 20:05:15 -0800
Lines: 27
Distribution: su
Message-ID: <Pine.LNX.4.62.0701122004360.4582@xenon.Stanford.EDU>
References: <eo8shv$n55$1@news.Stanford.EDU> <C1CD3AAD.745F%jpettit@stanford.edu>
 <Pine.LNX.4.62.0701121957030.1022@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1168661118 16659 171.64.66.201 (13 Jan 2007 04:05:18 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.62.0701121957030.1022@xenon.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10933

Sorry, never mind. Found one online...... but if the TA likes to provide 
the best man page access, that's fine too.

On Fri, 12 Jan 2007, Ryan Chen 
wrote:

> In one of the slides, it mentions this "man pages (section 2)", where is this 
> man page that you guys are talking about? Thanks.
>
> On Fri, 12 Jan 2007, Justin Pettit wrote:
>
>> A PDF version has been posted.
>> 
>> --Justin
>> 
>> 
>> On 1/12/07 12:53 PM, in article eo8shv$n55$1@news.Stanford.EDU, "Clay
>> Collier" <ccollier@stanford.edu> wrote:
>> 
>>> Powerpoint slides from today's section are now posted on the website.
>>> We'll hopefully have a PDF version of them available later on.
>>> 
>>> Clay
>> 
>> 
>> 
>
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Section Slides Posted
Date: Fri, 12 Jan 2007 20:46:19 -0800
Lines: 65
Distribution: su
Message-ID: <C1CDA41B.7483%jpettit@stanford.edu>
References: <eo8shv$n55$1@news.Stanford.EDU> <C1CD3AAD.745F%jpettit@stanford.edu> <Pine.LNX.4.62.0701121957030.1022@xenon.Stanford.EDU> <Pine.LNX.4.62.0701122004360.4582@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168663577 18483 127.0.0.1 (13 Jan 2007 04:46:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Section Slides Posted
Thread-Index: Acc2zcQgAvUpg6LBEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10934

Clay was referring to the different sections in the man pages.  For example,
if you type "man write", you'll get the man page for "write" from section
"P", which is a program that writes to the console of another user.
However, if you type "man 2 write", you'll get a man page on the "write"
system call, which is what you want.

Here's a breakdown on the meanings of the some of the main section numbers:

       1   Executable programs or shell commands
       2   System calls (functions provided by the kernel)
       3   Library calls (functions within program libraries)
       4   Special files (usually found in /dev)
       5   File formats and conventions eg /etc/passwd
       6   Games
       7   Miscellaneous (including macro  packages  and  conven-
           tions), e.g. man(7), groff(7)
       8   System administration commands (usually only for root)
       9   Kernel routines [Non standard]

When you're programming, you'll generally want pages out of sections 2 and
3.  You only need to specify the section number when you don't get the page
you wanted, such as with "read" and "write".  The man program just grabs the
first page that matches your request.

By the way, putting the bare section number before your request doesn't work
on all systems.  For example, on Solaris you'd need to type "man -s 2 read".

I hope that clarifies things.

--Justin


On 1/12/07 8:05 PM, in article
Pine.LNX.4.62.0701122004360.4582@xenon.Stanford.EDU, "Ryan Chen"
<ryanchen@xenon.Stanford.EDU> wrote:

> Sorry, never mind. Found one online...... but if the TA likes to provide
> the best man page access, that's fine too.
> 
> On Fri, 12 Jan 2007, Ryan Chen
> wrote:
> 
>> In one of the slides, it mentions this "man pages (section 2)", where is this
>> man page that you guys are talking about? Thanks.
>> 
>> On Fri, 12 Jan 2007, Justin Pettit wrote:
>> 
>>> A PDF version has been posted.
>>> 
>>> --Justin
>>> 
>>> 
>>> On 1/12/07 12:53 PM, in article eo8shv$n55$1@news.Stanford.EDU, "Clay
>>> Collier" <ccollier@stanford.edu> wrote:
>>> 
>>>> Powerpoint slides from today's section are now posted on the website.
>>>> We'll hopefully have a PDF version of them available later on.
>>>> 
>>>> Clay
>>> 
>>> 
>>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: balanced tree/hash table
Date: Fri, 12 Jan 2007 21:31:21 -0800
Lines: 8
Distribution: su
Message-ID: <eo9qq4$k93$1@news.Stanford.EDU>
References: <eo74tg$s3s$1@news.Stanford.EDU> <C1CC6BB7.742D%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168666244 20771 127.0.0.1 (13 Jan 2007 05:30:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10935

Okay.  Do you have an STL implementation in C? :-)  That would be a catch!

> Sorry to do this to you, Randy, but we would like everyone to stick with
> standard libraries and STL.  The concern is that it could really 
> complicate
> things--especially the grading.


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Windows Only Access
Date: Fri, 12 Jan 2007 21:37:12 -0800
Lines: 24
Distribution: su
Message-ID: <eo9r53$kdq$1@news.Stanford.EDU>
References: <eo75kt$slj$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168666595 20922 127.0.0.1 (13 Jan 2007 05:36:35 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10936

Don't forget cygwin (with X11, sftp, ssh, gcc, gdb all modules in it).  This 
way you get to test on your system first.

I said in the recitation session today that cygwin does not claim to be 
thread safe.  That is true; however, I have never had issues with it, so 
saying it works most of the time was not quite correct.

(BTW, if you use xemacs, and you want to use gdb, xemacs must be installed 
for cygwin, not native.  Things don't work, and it does not tell you why.)

Sincerely,
Randy Jennings

"Brian Thompson" <Brian.C.Thompson@Boeing.com> wrote in message 
news:eo75kt$slj$1@news.Stanford.EDU...
>I am a distance student and only have access to Windows XP.  Does anyone 
>have a recommendation for the best program/enviroment to access the Lab 
>servers and to develop the programming assignments in?
>
> Thanks,
> --Brian
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: helper functions from the UNIX network programming book
Date: Fri, 12 Jan 2007 23:16:42 -0800
Lines: 9
Distribution: su
Message-ID: <eoa0u3$o8t$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168672515 24861 128.12.134.140 (13 Jan 2007 07:15:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:10937

Hi,

Can we use the helper functions (writen, readn, ...) from the Network
Programming book in our code. It would make things much simpler (since
those functions are already checked for errors, and are not related to
the core functionality of the proxy).

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: helper functions from the UNIX network programming book
Date: Fri, 12 Jan 2007 23:59:25 -0800
Lines: 22
Distribution: su
Message-ID: <C1CDD15D.7494%jpettit@stanford.edu>
References: <eoa0u3$o8t$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168675163 208 127.0.0.1 (13 Jan 2007 07:59:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: helper functions from the UNIX network programming book
Thread-Index: Acc26L3r/KUXQqLbEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10938

Please implement your own methods for reading and writing data.  The point
of this project is to get everyone used to writing socket code, which
includes the pain of not having a read or write call not complete the action
you requested.

--Justin


On 1/12/07 11:16 PM, in article eoa0u3$o8t$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> Hi,
> 
> Can we use the helper functions (writen, readn, ...) from the Network
> Programming book in our code. It would make things much simpler (since
> those functions are already checked for errors, and are not related to
> the core functionality of the proxy).
> 
> Thanks,
> Jad.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: accept Failure
Date: Sat, 13 Jan 2007 01:03:28 -0800
Lines: 10
Distribution: su
Message-ID: <C1CDE060.7499%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168679006 6417 127.0.0.1 (13 Jan 2007 09:03:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: accept Failure
Thread-Index: Acc28bCG711mbKLkEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10939

We had a question after the review session today about what to do if the
"accept" call fails.  For the purposes of this assignment, it is fine to
just exit with an error return code.  There are times that you could recover
from an "accept" error, but they're in very limited circumstances.  However,
I would recommend that you always print the errno to failed system calls,
since it could indicate a bug in your program, such as not closing your
sockets.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on running perl script.
Date: Sat, 13 Jan 2007 02:05:31 -0800
Lines: 3
Distribution: su
Message-ID: <eoaat0$99f$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168682720 9519 128.12.194.72 (13 Jan 2007 10:05:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:10940

Um, how do I run a perl script again? :p

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on running perl script.
Date: Sat, 13 Jan 2007 09:58:24 -0800
Lines: 21
Distribution: su
Message-ID: <eob6ip$32t$1@news.Stanford.EDU>
References: <eoaat0$99f$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168711065 3165 127.0.0.1 (13 Jan 2007 17:57:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10941

perl <scriptname>

or put
#!/usr/sweet/bin/perl
as the first line (on myth).
Just plain "#! perl" might work, too.

However, if you are talking about the grading script, I would recommend 
using python instead :-).

Sincerely,
Randy Jennings

The squirrels are your friends!
"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eoaat0$99f$1@news.Stanford.EDU...
> Um, how do I run a perl script again? :p
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on running perl script.
Date: Sat, 13 Jan 2007 13:57:15 -0800
Lines: 39
Distribution: su
Message-ID: <eobkje$ce2$1@news.Stanford.EDU>
References: <eoaat0$99f$1@news.Stanford.EDU> <eob6ip$32t$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168725422 12738 128.12.194.72 (13 Jan 2007 21:57:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eob6ip$32t$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10942

*smacks head*

Right, python.

So...

python <program name> (?)

I have no idea here. I can barely figure out how to run python programs 
in Windows, much less Unix. :(

That's what I get from trying to study at 2AM.

-Yangfan

Randy Jennings wrote:
> perl <scriptname>
> 
> or put
> #!/usr/sweet/bin/perl
> as the first line (on myth).
> Just plain "#! perl" might work, too.
> 
> However, if you are talking about the grading script, I would recommend 
> using python instead :-).
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:eoaat0$99f$1@news.Stanford.EDU...
> 
>>Um, how do I run a perl script again? :p
>>
>>-Yangfan 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Compiling
Date: Sat, 13 Jan 2007 14:04:20 -0800
Lines: 24
Distribution: su
Message-ID: <eobl17$cp2$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168725863 13090 127.0.0.1 (13 Jan 2007 22:04:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:10943

Before I crash into the assignment I want to make sure I can at least create 
a little program on lab pc since I am a remote student, but I'm having a 
problem running the executable file.  I get the following message:
> hello: Command not found.

I have a the generic hello.c program:

#include <stdio.h>
int
main(int argc, char *argv[])
{
    printf ("hello world\n");
    return 0;
}

and I am compiling by typing:
> gcc -o hello hello.c

Any suggestions why I can't run the hello program and get this error?

Thanks,
--Brian 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Compiling
Date: Sat, 13 Jan 2007 15:04:18 -0800
Lines: 35
Distribution: su
Message-ID: <C1CEA572.74C8%jpettit@stanford.edu>
References: <eobl17$cp2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168729455 16633 127.0.0.1 (13 Jan 2007 23:04:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Compiling
Thread-Index: Acc3ZycSZXx+YKNaEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10944

For security reason, executable don't execute out of your local directory.
You probably need to run it as "./hello".

--Justin


On 1/13/07 2:04 PM, in article eobl17$cp2$1@news.Stanford.EDU, "Brian
Thompson" <Brian.C.Thompson@Boeing.com> wrote:

> Before I crash into the assignment I want to make sure I can at least create
> a little program on lab pc since I am a remote student, but I'm having a
> problem running the executable file.  I get the following message:
>> hello: Command not found.
> 
> I have a the generic hello.c program:
> 
> #include <stdio.h>
> int
> main(int argc, char *argv[])
> {
>     printf ("hello world\n");
>     return 0;
> }
> 
> and I am compiling by typing:
>> gcc -o hello hello.c
> 
> Any suggestions why I can't run the hello program and get this error?
> 
> Thanks,
> --Brian 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: past exams
Date: Sat, 13 Jan 2007 17:25:40 -0800
Lines: 7
Distribution: su
Message-ID: <eoc0nt$oan$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168737853 24919 128.12.134.140 (14 Jan 2007 01:24:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:10945

Hi,

It would be very useful if we could have past exams posted so we can
know what the format is and how to read the book and what to concentrate on.

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: helper functions from the UNIX network programming book
Date: Sat, 13 Jan 2007 18:37:16 -0800
Lines: 29
Distribution: su
Message-ID: <eoc50i$8d$1@news.Stanford.EDU>
References: <eoa0u3$o8t$1@news.Stanford.EDU> <C1CDD15D.7494%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168742226 269 128.12.194.72 (14 Jan 2007 02:37:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1CDD15D.7494%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10946

What if we re-use the book's algorithm and cite it?

-Yangfan

Justin Pettit wrote:
> Please implement your own methods for reading and writing data.  The point
> of this project is to get everyone used to writing socket code, which
> includes the pain of not having a read or write call not complete the action
> you requested.
> 
> --Justin
> 
> 
> On 1/12/07 11:16 PM, in article eoa0u3$o8t$1@news.Stanford.EDU, "Jad Naous"
> <jnaous@stanford.edu> wrote:
> 
> 
>>Hi,
>>
>>Can we use the helper functions (writen, readn, ...) from the Network
>>Programming book in our code. It would make things much simpler (since
>>those functions are already checked for errors, and are not related to
>>the core functionality of the proxy).
>>
>>Thanks,
>>Jad.
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Cannot telnet to localhost?
Date: Sat, 13 Jan 2007 21:04:10 -0800
Lines: 17
Distribution: su
Message-ID: <eocdk0$6m6$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168751041 6854 128.12.194.72 (14 Jan 2007 05:04:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:10947

I'm trying to test my code by doing this:

../proxy 8118 &
(This starts my proxy on another thread with port 8118.)

telnet localhost 8118
(Then I try to establish a connection to it.)

But then I always get this error:
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host: Connection refused

I believe that this is because the myth cluster is secure, and won't let 
me telnet in even if I'm at localhost. This there a way to get around 
this? What am I doing wrong?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Compiling
Date: Sat, 13 Jan 2007 23:25:35 -0800
Lines: 42
Distribution: su
Message-ID: <eocltm$cds$1@news.Stanford.EDU>
References: <eobl17$cp2$1@news.Stanford.EDU> <C1CEA572.74C8%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168759543 12732 127.0.0.1 (14 Jan 2007 07:25:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:10948

This worked perfect.  Thanks.

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1CEA572.74C8%jpettit@stanford.edu...
> For security reason, executable don't execute out of your local directory.
> You probably need to run it as "./hello".
>
> --Justin
>
>
> On 1/13/07 2:04 PM, in article eobl17$cp2$1@news.Stanford.EDU, "Brian
> Thompson" <Brian.C.Thompson@Boeing.com> wrote:
>
>> Before I crash into the assignment I want to make sure I can at least 
>> create
>> a little program on lab pc since I am a remote student, but I'm having a
>> problem running the executable file.  I get the following message:
>>> hello: Command not found.
>>
>> I have a the generic hello.c program:
>>
>> #include <stdio.h>
>> int
>> main(int argc, char *argv[])
>> {
>>     printf ("hello world\n");
>>     return 0;
>> }
>>
>> and I am compiling by typing:
>>> gcc -o hello hello.c
>>
>> Any suggestions why I can't run the hello program and get this error?
>>
>> Thanks,
>> --Brian
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: helper functions from the UNIX network programming book
Date: Sat, 13 Jan 2007 23:55:15 -0800
Lines: 42
Distribution: su
Message-ID: <C1CF21E3.74E1%jpettit@stanford.edu>
References: <eoa0u3$o8t$1@news.Stanford.EDU> <C1CDD15D.7494%jpettit@stanford.edu> <eoc50i$8d$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168761316 16646 127.0.0.1 (14 Jan 2007 07:55:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: helper functions from the UNIX network programming book
Thread-Index: Acc3sVNSkb2TmqOkEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10949

There are only so many ways you can write a function that makes sure all the
data you request to be written is written.  However, make an attempt to
write your own as best you can and make sure you follow the coding
guidelines (e.g. don't use global variables).

--Justin


On 1/13/07 6:37 PM, in article eoc50i$8d$1@news.Stanford.EDU, "Yangfan Wang"
<yfw@stanford.edu> wrote:

> What if we re-use the book's algorithm and cite it?
> 
> -Yangfan
> 
> Justin Pettit wrote:
>> Please implement your own methods for reading and writing data.  The point
>> of this project is to get everyone used to writing socket code, which
>> includes the pain of not having a read or write call not complete the action
>> you requested.
>> 
>> --Justin
>> 
>> 
>> On 1/12/07 11:16 PM, in article eoa0u3$o8t$1@news.Stanford.EDU, "Jad Naous"
>> <jnaous@stanford.edu> wrote:
>> 
>> 
>>> Hi,
>>> 
>>> Can we use the helper functions (writen, readn, ...) from the Network
>>> Programming book in our code. It would make things much simpler (since
>>> those functions are already checked for errors, and are not related to
>>> the core functionality of the proxy).
>>> 
>>> Thanks,
>>> Jad.
>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: past exams
Date: Sun, 14 Jan 2007 00:00:35 -0800
Lines: 18
Distribution: su
Message-ID: <C1CF2323.74E3%jpettit@stanford.edu>
References: <eoc0nt$oan$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168761633 17799 127.0.0.1 (14 Jan 2007 08:00:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: past exams
Thread-Index: Acc3shIOUGdRtKOlEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10950

In previous versions of this course, past exams have been posted.  I'm sure
we'll do the same when we get closer to midterm and final.

--Justin


On 1/13/07 5:25 PM, in article eoc0nt$oan$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> Hi,
> 
> It would be very useful if we could have past exams posted so we can
> know what the format is and how to read the book and what to concentrate on.
> 
> Thanks,
> Jad.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Sun, 14 Jan 2007 00:11:08 -0800
Lines: 42
Distribution: su
Message-ID: <C1CF259C.74E6%jpettit@stanford.edu>
References: <eocdk0$6m6$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168762267 18621 127.0.0.1 (14 Jan 2007 08:11:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Cannot telnet to localhost?
Thread-Index: Acc3s4taydH/uqOmEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10951

I just tested my implementation and didn't have any problem.  Are you sure
you're on the same Myth machine?  The Myth cluster is a bunch of different
Linux machines.  Stanford uses some DNS tricks, which we'll cover next
Friday, to make it so that when you SSH into a "myth", it sends you to a
random one.  This means that if you have multiple remote sessions open,
you'll end up on multiple machines.  When you start your proxy on one, it
won't work for testing on another.

To work around this, create your multiple sessions on the same Myth host.
For example, I logged into "myth.stanford.edu", and I can see from my prompt
that I'm on "myth26".  I then create my additional sessions by SSHing to
"myth26.stanford.edu".  If you don't see which Myth machine you are on, you
can run the "hostname" command.

If this doesn't address your problem, let us know.

--Justin


On 1/13/07 9:04 PM, in article eocdk0$6m6$1@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> I'm trying to test my code by doing this:
> 
> ./proxy 8118 &
> 
> (This starts my proxy on another thread with port 8118.)
> 
> telnet localhost 8118
> (Then I try to establish a connection to it.)
> 
> But then I always get this error:
> telnet: connect to address 127.0.0.1: Connection refused
> telnet: Unable to connect to remote host: Connection refused
> 
> I believe that this is because the myth cluster is secure, and won't let
> me telnet in even if I'm at localhost. This there a way to get around
> this? What am I doing wrong?
> 
> -Yangfan


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on running perl script.
Date: Sun, 14 Jan 2007 00:55:41 -0800
Lines: 52
Distribution: su
Message-ID: <eocra7$kgp$1@news.Stanford.EDU>
References: <eoaat0$99f$1@news.Stanford.EDU> <eob6ip$32t$1@news.Stanford.EDU> <eobkje$ce2$1@news.Stanford.EDU>
NNTP-Posting-Host: shelly.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168765063 21017 128.12.133.165 (14 Jan 2007 08:57:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eobkje$ce2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10952

It is much easier in unix than in windows, since your default 
environment is a command prompt.

You guessed the command right.

python <script name> <parameter list>

If that doesn't work, see if python is in your path. You can find the 
executable with

locate python

Yangfan Wang wrote:
> *smacks head*
> 
> Right, python.
> 
> So...
> 
> python <program name> (?)
> 
> I have no idea here. I can barely figure out how to run python programs 
> in Windows, much less Unix. :(
> 
> That's what I get from trying to study at 2AM.
> 
> -Yangfan
> 
> Randy Jennings wrote:
>> perl <scriptname>
>>
>> or put
>> #!/usr/sweet/bin/perl
>> as the first line (on myth).
>> Just plain "#! perl" might work, too.
>>
>> However, if you are talking about the grading script, I would 
>> recommend using python instead :-).
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>> news:eoaat0$99f$1@news.Stanford.EDU...
>>
>>> Um, how do I run a perl script again? :p
>>>
>>> -Yangfan 
>>
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Sun, 14 Jan 2007 05:38:16 -0800
Lines: 62
Distribution: su
Message-ID: <eodbnv$ajc$1@news.Stanford.EDU>
References: <eocdk0$6m6$1@news.Stanford.EDU> <C1CF259C.74E6%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168781887 10860 128.12.194.72 (14 Jan 2007 13:38:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1CF259C.74E6%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10953

Hmm. The problem only seems to occur if I start the telnet connection 
after my proxy has been running for more than a dozen seconds or so. In 
gdb, I could tell that my proxy goes all the way up to the call to 
accept. Does accept have a time-out mechanism or something?

Also, I could use some clarifications on gethostbyname. After calling 
gethostbyname(<the URL>), I know that I get a struct hostent pointer 
back. But then what? I can't tell from the man page where to get the IP 
address in the "X.X.X.X" form. My best guess was 
<struct>.h_addr_list[0], but I'm getting mangled garbage out of it right 
now. So... am I looking at the wrong thing?

I know that my URL was valid, since <struct>.h_name was different but 
still made sense.

-Yangfan

Justin Pettit wrote:
> I just tested my implementation and didn't have any problem.  Are you sure
> you're on the same Myth machine?  The Myth cluster is a bunch of different
> Linux machines.  Stanford uses some DNS tricks, which we'll cover next
> Friday, to make it so that when you SSH into a "myth", it sends you to a
> random one.  This means that if you have multiple remote sessions open,
> you'll end up on multiple machines.  When you start your proxy on one, it
> won't work for testing on another.
> 
> To work around this, create your multiple sessions on the same Myth host.
> For example, I logged into "myth.stanford.edu", and I can see from my prompt
> that I'm on "myth26".  I then create my additional sessions by SSHing to
> "myth26.stanford.edu".  If you don't see which Myth machine you are on, you
> can run the "hostname" command.
> 
> If this doesn't address your problem, let us know.
> 
> --Justin
> 
> 
> On 1/13/07 9:04 PM, in article eocdk0$6m6$1@news.Stanford.EDU, "Yangfan
> Wang" <yfw@stanford.edu> wrote:
> 
> 
>>I'm trying to test my code by doing this:
>>
>>./proxy 8118 &
>>
>>(This starts my proxy on another thread with port 8118.)
>>
>>telnet localhost 8118
>>(Then I try to establish a connection to it.)
>>
>>But then I always get this error:
>>telnet: connect to address 127.0.0.1: Connection refused
>>telnet: Unable to connect to remote host: Connection refused
>>
>>I believe that this is because the myth cluster is secure, and won't let
>>me telnet in even if I'm at localhost. This there a way to get around
>>this? What am I doing wrong?
>>
>>-Yangfan
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: running grading script
Date: Sun, 14 Jan 2007 16:21:04 -0800
Lines: 39
Distribution: su
Message-ID: <eoehdh$l9f$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168820465 21807 127.0.0.1 (15 Jan 2007 00:21:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10954

I was trying to run the grading script on my proxy and I get the messages 
below. Why is this happening?

vine7:~/proj1> ./grade proxy.c 98235
Binary: proxy.c
Running on port 98235
Traceback (most recent call last):
  File "./grade", line 100, in ?
    main()
  File "./grade", line 45, in main
    foblist.append(urllib.urlopen(url, None, proxy_map))
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 82, in urlopen
    return opener.open(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 190, in open
    return getattr(self, name)(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 313, in open_http
    h.endheaders()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
798, in endheaders
    self._send_output()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
679, in _send_output
    self.send(msg)
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
646, in send
    self.connect()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
630, in connect
    raise socket.error, msg
IOError: [Errno socket error] (111, 'Connection refused')


.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: running grading script
Date: Sun, 14 Jan 2007 16:21:31 -0800
Lines: 39
Distribution: su
Message-ID: <eoeheb$l9m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168820491 21814 127.0.0.1 (15 Jan 2007 00:21:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10955

I was trying to run the grading script on my proxy and I get the messages 
below. Why is this happening?

vine7:~/proj1> ./grade proxy.c 98235
Binary: proxy.c
Running on port 98235
Traceback (most recent call last):
  File "./grade", line 100, in ?
    main()
  File "./grade", line 45, in main
    foblist.append(urllib.urlopen(url, None, proxy_map))
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 82, in urlopen
    return opener.open(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 190, in open
    return getattr(self, name)(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 313, in open_http
    h.endheaders()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
798, in endheaders
    self._send_output()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
679, in _send_output
    self.send(msg)
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
646, in send
    self.connect()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
630, in connect
    raise socket.error, msg
IOError: [Errno socket error] (111, 'Connection refused')


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 14 Jan 2007 16:35:57 -0800
Lines: 52
Distribution: su
Message-ID: <C1D00C6D.7506%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168821355 22437 127.0.0.1 (15 Jan 2007 00:35:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: Acc4PR8kXeJ0iqQwEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10956

TCP and UDP port numbers are 16-bit values, which means the maximum value is
65535.  Try something between 1024 and 65535.  You also might want to check
to make sure that you're checking all your socket return values and compiler
warnings.

--Justin


On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
<axle@sonic.net> wrote:

> I was trying to run the grading script on my proxy and I get the messages
> below. Why is this happening?
> 
> vine7:~/proj1> ./grade proxy.c 98235
> Binary: proxy.c
> Running on port 98235
> Traceback (most recent call last):
>   File "./grade", line 100, in ?
>     main()
>   File "./grade", line 45, in main
>     foblist.append(urllib.urlopen(url, None, proxy_map))
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
> line 82, in urlopen
>     return opener.open(url)
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
> line 190, in open
>     return getattr(self, name)(url)
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
> line 313, in open_http
>     h.endheaders()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line
> 798, in endheaders
>     self._send_output()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line
> 679, in _send_output
>     self.send(msg)
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line
> 646, in send
>     self.connect()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line
> 630, in connect
>     raise socket.error, msg
> IOError: [Errno socket error] (111, 'Connection refused')
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on gethostbyname
Date: Sun, 14 Jan 2007 17:17:43 -0800
Lines: 13
Distribution: su
Message-ID: <eoekn7$nr1$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168823847 24417 128.12.194.72 (15 Jan 2007 01:17:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:10957

(reposted from unanswered post)

I could use some clarifications on gethostbyname. After calling 
gethostbyname(<the URL>), I know that I get a struct hostent pointer 
back. But then what? I can't tell from the man page where to get the IP 
address in the "X.X.X.X" form. My best guess was 
<struct>.h_addr_list[0], but I'm getting mangled garbage out of it right 
now. So... am I looking at the wrong thing?

I know that my URL was valid, since <struct>.h_name was different but 
still made sense.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 14 Jan 2007 17:26:41 -0800
Lines: 107
Distribution: su
Message-ID: <eoel8m$ob8$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168824406 24936 127.0.0.1 (15 Jan 2007 01:26:46 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10958

I gave a port in the valid range and I still see this issue. I was able to 
run my proxy on that port and use telnet and do GET correctly but I'm still 
having problems with the grading script.

vine7:~/proj1> ./grade proxy.c 32454
Binary: proxy.c
Running on port 32454
Traceback (most recent call last):
  File "./grade", line 97, in ?
    main()
  File "./grade", line 42, in main
    foblist.append(urllib.urlopen(url, None, proxy_map))
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 82, in urlopen
    return opener.open(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 190, in open
    return getattr(self, name)(url)
  File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
line 313, in open_http
    h.endheaders()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
798, in endheaders
    self._send_output()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
679, in _send_output
    self.send(msg)
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
646, in send
    self.connect()
  File 
"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
630, in connect
    raise socket.error, msg
IOError: [Errno socket error] (111, 'Connection refused')

Alex

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D00C6D.7506%jpettit@stanford.edu...
> TCP and UDP port numbers are 16-bit values, which means the maximum value 
> is
> 65535.  Try something between 1024 and 65535.  You also might want to 
> check
> to make sure that you're checking all your socket return values and 
> compiler
> warnings.
>
> --Justin
>
>
> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
> <axle@sonic.net> wrote:
>
>> I was trying to run the grading script on my proxy and I get the messages
>> below. Why is this happening?
>>
>> vine7:~/proj1> ./grade proxy.c 98235
>> Binary: proxy.c
>> Running on port 98235
>> Traceback (most recent call last):
>>   File "./grade", line 100, in ?
>>     main()
>>   File "./grade", line 45, in main
>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>> line 82, in urlopen
>>     return opener.open(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>> line 190, in open
>>     return getattr(self, name)(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>> line 313, in open_http
>>     h.endheaders()
>>   File
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line
>> 798, in endheaders
>>     self._send_output()
>>   File
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line
>> 679, in _send_output
>>     self.send(msg)
>>   File
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line
>> 646, in send
>>     self.connect()
>>   File
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line
>> 630, in connect
>>     raise socket.error, msg
>> IOError: [Errno socket error] (111, 'Connection refused')
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: RFC compliance
Date: Sun, 14 Jan 2007 19:51:54 -0800
Lines: 20
Distribution: su
Message-ID: <eoetoe$33f$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168833102 3183 127.0.0.1 (15 Jan 2007 03:51:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:10959

Hi,

I had doubts as to how tolerant should the proxy server be while 
implementing the RFC.

1. Should it accept a request from the client if the method is not in 
upper-case and so on?

2. How should the proxy behave when we have a request that contains 
"CRLF SP CRLF"? When I tried testing this scenario with yahoo, google 
and w3c.org, they behaved differently.

3. Should we accept requests with space preceding GET as valid requests?

4. While checking if the request is properly formatted, do we need to
verify the header sections too?

Thanks
Neelima

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on tab length / left indention
Date: Sun, 14 Jan 2007 22:34:12 -0800
Lines: 4
Distribution: su
Message-ID: <eof795$c4i$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168842853 12434 128.12.194.72 (15 Jan 2007 06:34:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:10960

Does anyone know how to modify xemacs so that when it auto-formats code, 
the left indention is set at, say, 4 spaces rather than 2?

-Yangfan
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Sun, 14 Jan 2007 23:06:01 -0800
Lines: 62
Distribution: su
Message-ID: <paun-DCC8AE.23060014012007@nntp.stanford.edu>
References: <eocdk0$6m6$1@news.Stanford.EDU> <C1CF259C.74E6%jpettit@stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1168844761 13595 128.12.135.184 (15 Jan 2007 07:06:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:10961

I am running in the same problem as Yangfan.

I issue the commands:

   ./proxy 10000

   telnet localhost 10000

and get the error:

   telnet: connect to address 127.0.0.1: Connection refused
   telnet: Unable to connect to remote host: Connection refused

On both terminals, I can see that i am on the same myth machine (in my 
case myth23).

Any help is much appreciated.  Thank you in advance.
Filip

In article <C1CF259C.74E6%jpettit@stanford.edu>,
 Justin Pettit <jpettit@stanford.edu> wrote:

> I just tested my implementation and didn't have any problem.  Are you sure
> you're on the same Myth machine?  The Myth cluster is a bunch of different
> Linux machines.  Stanford uses some DNS tricks, which we'll cover next
> Friday, to make it so that when you SSH into a "myth", it sends you to a
> random one.  This means that if you have multiple remote sessions open,
> you'll end up on multiple machines.  When you start your proxy on one, it
> won't work for testing on another.
> 
> To work around this, create your multiple sessions on the same Myth host.
> For example, I logged into "myth.stanford.edu", and I can see from my prompt
> that I'm on "myth26".  I then create my additional sessions by SSHing to
> "myth26.stanford.edu".  If you don't see which Myth machine you are on, you
> can run the "hostname" command.
> 
> If this doesn't address your problem, let us know.
> 
> --Justin
> 
> 
> On 1/13/07 9:04 PM, in article eocdk0$6m6$1@news.Stanford.EDU, "Yangfan
> Wang" <yfw@stanford.edu> wrote:
> 
> > I'm trying to test my code by doing this:
> > 
> > ./proxy 8118 &
> > 
> > (This starts my proxy on another thread with port 8118.)
> > 
> > telnet localhost 8118
> > (Then I try to establish a connection to it.)
> > 
> > But then I always get this error:
> > telnet: connect to address 127.0.0.1: Connection refused
> > telnet: Unable to connect to remote host: Connection refused
> > 
> > I believe that this is because the myth cluster is secure, and won't let
> > me telnet in even if I'm at localhost. This there a way to get around
> > this? What am I doing wrong?
> > 
> > -Yangfan
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Telnet Error
Date: Sun, 14 Jan 2007 23:11:34 -0800
Lines: 21
Distribution: su
Message-ID: <paun-C442BE.23113414012007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1168845095 13595 128.12.135.184 (15 Jan 2007 07:11:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:10962

Hello,

I am running in the same telnet problem as Yangfan.

I issue the commands on two terminals:
  
   ./proxy 10001
   telnet localhost 10001

and receive the following error

   telnet: connect to address 127.0.0.1: Connection refused
   telnet: Unable to connect to remote host: Connection refused

now both commands were issued on the same myth machine (in my case 
myth23).

What do i need to do to solve this error? Your help is much appreciated 
and thank you in advance for your response.

Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on tab length / left indention
Date: Mon, 15 Jan 2007 00:36:55 -0800
Lines: 24
Distribution: su
Message-ID: <eofefi$lkn$1@news.Stanford.EDU>
References: <eof795$c4i$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1168850226 22167 127.0.0.1 (15 Jan 2007 08:37:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:10963

On 2007-01-14 22:34:12 -0800, Yangfan Wang <yfw@stanford.edu> said:

> Does anyone know how to modify xemacs so that when it auto-formats 
> code, the left indention is set at, say, 4 spaces rather than 2?
> 
> -Yangfan

There are like 800 ways to do it, which you can get the gritty details 
of by googling, but one way is to edit your .xemacs file to include

(add-hook 'c-mode-hook '(lambda ()
	(setq c-basic-offset 4))))

That'll do it for C files.  On regular old emacs at least. You could also try

(setq default-tab-width 4)

if you want it for all files.






.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 01:30:28 -0800
Lines: 48
Distribution: su
Message-ID: <eofhjl$p1f$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168853429 25647 128.12.194.72 (15 Jan 2007 09:30:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eoekn7$nr1$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10964

A related question:

 From the man page on gethostbyname:

The hostent structure is defined in <netdb.h> as follows:

               struct hostent {
                       char    *h_name;        /* official name of host */
                       char    **h_aliases;    /* alias list */
                       int     h_addrtype;     /* host address type */
                       int     h_length;       /* length of address */
                       char    **h_addr_list;  /* list of addresses */
               }
               #define h_addr  h_addr_list[0]  /* for backward 
compatibility */

....

h_addr_list
               A zero-terminated array of network addresses for the host 
in network byte order.

What does it mean for a char* (a string, really) to be in network byte 
order? Is this a human readable IP address (X.X.X.X) or a machine 
reabale IP address (in_addr_t)?

This is making me pull my hair out. I just want to go from 
"www.yahoo.com" to a machine readable IP address of type in_addr_t. It 
shouldn't be this complicated. I must be doing something wrong here. :/

Any help would be appreciated. Thanks.

-Yangfan

Yangfan Wang wrote:
> (reposted from unanswered post)
> 
> I could use some clarifications on gethostbyname. After calling 
> gethostbyname(<the URL>), I know that I get a struct hostent pointer 
> back. But then what? I can't tell from the man page where to get the IP 
> address in the "X.X.X.X" form. My best guess was 
> <struct>.h_addr_list[0], but I'm getting mangled garbage out of it right 
> now. So... am I looking at the wrong thing?
> 
> I know that my URL was valid, since <struct>.h_name was different but 
> still made sense.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on tab length / left indention
Date: Mon, 15 Jan 2007 01:31:53 -0800
Lines: 27
Distribution: su
Message-ID: <eofhmb$p1f$2@news.Stanford.EDU>
References: <eof795$c4i$1@news.Stanford.EDU> <eofefi$lkn$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168853515 25647 128.12.194.72 (15 Jan 2007 09:31:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofefi$lkn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10965

Adam Cohen wrote:
> On 2007-01-14 22:34:12 -0800, Yangfan Wang <yfw@stanford.edu> said:
> 
>> Does anyone know how to modify xemacs so that when it auto-formats 
>> code, the left indention is set at, say, 4 spaces rather than 2?
>>
>> -Yangfan
> 
> 
> There are like 800 ways to do it, which you can get the gritty details 
> of by googling, but one way is to edit your .xemacs file to include
> 
> (add-hook 'c-mode-hook '(lambda ()
>     (setq c-basic-offset 4))))
> 
> That'll do it for C files.  On regular old emacs at least. You could 
> also try
> 
> (setq default-tab-width 4)
> 
> if you want it for all files.
> 

I can only use xemacs when I'm remotely logged in, but I can try this 
with emacs in the labs. Thank you Adam.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 01:58:11 -0800
Lines: 123
Distribution: su
Message-ID: <eofjbc$qg9$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU>
NNTP-Posting-Host: shelly.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168855212 27145 128.12.133.165 (15 Jan 2007 10:00:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoel8m$ob8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10966

The important error line that is the last one:

 > IOError: [Errno socket error] (111, 'Connection refused')

That means that it is unable to connect to anything on that port. Are 
you sure your running your proxy on that port? Might you be binding the 
port in the wrong 'endian'ness? There is a function that you should be 
using whenever you are taking data from the host and changing it to 
network byte ordering.

See if you can bind to port 1. If you can, you are doing the endianness 
wrong, since a non-root user can't bind to port < 1024.




Alex wrote:
> I gave a port in the valid range and I still see this issue. I was able to 
> run my proxy on that port and use telnet and do GET correctly but I'm still 
> having problems with the grading script.
> 
> vine7:~/proj1> ./grade proxy.c 32454
> Binary: proxy.c
> Running on port 32454
> Traceback (most recent call last):
>   File "./grade", line 97, in ?
>     main()
>   File "./grade", line 42, in main
>     foblist.append(urllib.urlopen(url, None, proxy_map))
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
> line 82, in urlopen
>     return opener.open(url)
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
> line 190, in open
>     return getattr(self, name)(url)
>   File "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
> line 313, in open_http
>     h.endheaders()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
> 798, in endheaders
>     self._send_output()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
> 679, in _send_output
>     self.send(msg)
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
> 646, in send
>     self.connect()
>   File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", line 
> 630, in connect
>     raise socket.error, msg
> IOError: [Errno socket error] (111, 'Connection refused')
> 
> Alex
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1D00C6D.7506%jpettit@stanford.edu...
>> TCP and UDP port numbers are 16-bit values, which means the maximum value 
>> is
>> 65535.  Try something between 1024 and 65535.  You also might want to 
>> check
>> to make sure that you're checking all your socket return values and 
>> compiler
>> warnings.
>>
>> --Justin
>>
>>
>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>> <axle@sonic.net> wrote:
>>
>>> I was trying to run the grading script on my proxy and I get the messages
>>> below. Why is this happening?
>>>
>>> vine7:~/proj1> ./grade proxy.c 98235
>>> Binary: proxy.c
>>> Running on port 98235
>>> Traceback (most recent call last):
>>>   File "./grade", line 100, in ?
>>>     main()
>>>   File "./grade", line 45, in main
>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 82, in urlopen
>>>     return opener.open(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 190, in open
>>>     return getattr(self, name)(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 313, in open_http
>>>     h.endheaders()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 798, in endheaders
>>>     self._send_output()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 679, in _send_output
>>>     self.send(msg)
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 646, in send
>>>     self.connect()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 630, in connect
>>>     raise socket.error, msg
>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>
>>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 02:07:15 -0800
Lines: 41
Distribution: su
Message-ID: <eofjsc$rrk$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU>
NNTP-Posting-Host: shelly.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168855756 28532 128.12.133.165 (15 Jan 2007 10:09:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eofhjl$p1f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10967

Yangfan Wang wrote:
> A related question:
> 
>  From the man page on gethostbyname:
> 
> The hostent structure is defined in <netdb.h> as follows:
> 
>               struct hostent {
>                       char    *h_name;        /* official name of host */
>                       char    **h_aliases;    /* alias list */
>                       int     h_addrtype;     /* host address type */
>                       int     h_length;       /* length of address */
>                       char    **h_addr_list;  /* list of addresses */
>               }
>               #define h_addr  h_addr_list[0]  /* for backward 
> compatibility */
> 
Yes, that is what the function returns.
> ...
> 
> h_addr_list
>               A zero-terminated array of network addresses for the host 
> in network byte order.
> 
> What does it mean for a char* (a string, really) to be in network byte 
> order? Is this a human readable IP address (X.X.X.X) or a machine 
> reabale IP address (in_addr_t)?
Network byte order just is specifying that the number is "Big Endian". 
It is just the order in which the bits are stored (in this case, the 
most significant bit is in the lowest address position). This is needed 
since machines don't have to store all their data in the same order.

You might want to compare a h_addr to a in_addr_t. The similarities 
might alarm you.

> 
> This is making me pull my hair out. I just want to go from 
> "www.yahoo.com" to a machine readable IP address of type in_addr_t. It 
> shouldn't be this complicated. I must be doing something wrong here. :/
> 
You've already done the hard part. 2 more minutes and you will have it
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: RFC compliance
Date: Mon, 15 Jan 2007 02:10:11 -0800
Lines: 31
Distribution: su
Message-ID: <eofk1s$rrk$2@news.Stanford.EDU>
References: <eoetoe$33f$1@news.Stanford.EDU>
NNTP-Posting-Host: shelly.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168855932 28532 128.12.133.165 (15 Jan 2007 10:12:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoetoe$33f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10968

Please follow the RFC as closely as you can. If other implementations 
differ, and the RFC is very explicit, do exactly what the RFC says. I 
don't want to go through your list and find the pertinent parts of the 
RFC, since part of this assignment is learning how to write a program to 
a given specification.

If the RFC is vague, and you think there is more than one 
interpretation, please code it the most robust way, and then explain 
your decision in your README file.

Neelima Balakrishnan wrote:
> Hi,
> 
> I had doubts as to how tolerant should the proxy server be while 
> implementing the RFC.
> 
> 1. Should it accept a request from the client if the method is not in 
> upper-case and so on?
> 
> 2. How should the proxy behave when we have a request that contains 
> "CRLF SP CRLF"? When I tried testing this scenario with yahoo, google 
> and w3c.org, they behaved differently.
> 
> 3. Should we accept requests with space preceding GET as valid requests?
> 
> 4. While checking if the request is properly formatted, do we need to
> verify the header sections too?
> 
> Thanks
> Neelima
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 02:11:17 -0800
Lines: 26
Distribution: su
Message-ID: <eofk3u$rrk$3@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu>
NNTP-Posting-Host: shelly.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168855998 28532 128.12.133.165 (15 Jan 2007 10:13:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <paun-C442BE.23113414012007@nntp.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10969

As I posted above, check if you are in network byte order. See if you 
can bind to some ports from 1-1024. If you can, that is an error, since 
non-root users shouldn't be able to bind to ports from 1-1024.

Filip Paun wrote:
> Hello,
> 
> I am running in the same telnet problem as Yangfan.
> 
> I issue the commands on two terminals:
>   
>    ./proxy 10001
>    telnet localhost 10001
> 
> and receive the following error
> 
>    telnet: connect to address 127.0.0.1: Connection refused
>    telnet: Unable to connect to remote host: Connection refused
> 
> now both commands were issued on the same myth machine (in my case 
> myth23).
> 
> What do i need to do to solve this error? Your help is much appreciated 
> and thank you in advance for your response.
> 
> Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 02:50:53 -0800
Lines: 62
Distribution: su
Message-ID: <eofmaf$1l0$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU> <eofjsc$rrk$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168858255 1696 128.12.194.72 (15 Jan 2007 10:50:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofjsc$rrk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10970

Paul Tarjan (TA) wrote:
> Yangfan Wang wrote:
> 
>> A related question:
>>
>>  From the man page on gethostbyname:
>>
>> The hostent structure is defined in <netdb.h> as follows:
>>
>>               struct hostent {
>>                       char    *h_name;        /* official name of host */
>>                       char    **h_aliases;    /* alias list */
>>                       int     h_addrtype;     /* host address type */
>>                       int     h_length;       /* length of address */
>>                       char    **h_addr_list;  /* list of addresses */
>>               }
>>               #define h_addr  h_addr_list[0]  /* for backward 
>> compatibility */
>>
> Yes, that is what the function returns.
> 
>> ...
>>
>> h_addr_list
>>               A zero-terminated array of network addresses for the 
>> host in network byte order.
>>
>> What does it mean for a char* (a string, really) to be in network byte 
>> order? Is this a human readable IP address (X.X.X.X) or a machine 
>> reabale IP address (in_addr_t)?
> 
> Network byte order just is specifying that the number is "Big Endian". 
> It is just the order in which the bits are stored (in this case, the 
> most significant bit is in the lowest address position). This is needed 
> since machines don't have to store all their data in the same order.
> 
> You might want to compare a h_addr to a in_addr_t. The similarities 
> might alarm you.
> 

Hmm. So I casted h_addr_list[0], which is a char*, to in_addr_t, but the 
call to bind still failed. (I checked that the endianess is correct. I 
translate it to host byte order when I obtain the value and translate 
back to network byte order before attempting to bind.)

Are you sure it's not an IP string like "127.0.0.1"? Why else would it 
be a char*? And why would I need inet_addr if I can jump straight to the 
32-bit IP address?

I know gethostbyname is giving me a valid hostent struct. I just need to 
  figure out which field will get me to the IP address.

>>
>> This is making me pull my hair out. I just want to go from 
>> "www.yahoo.com" to a machine readable IP address of type in_addr_t. It 
>> shouldn't be this complicated. I must be doing something wrong here. :/
>>
> You've already done the hard part. 2 more minutes and you will have it

Thank you for the encouragement. :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 02:53:40 -0800
Lines: 35
Distribution: su
Message-ID: <eofmfl$1l0$2@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168858421 1696 128.12.194.72 (15 Jan 2007 10:53:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofk3u$rrk$3@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10971

I get this error when I restart my program after it crashes. The port 
number seems to remain allocated for about 20 seconds afterwards, and 
I'd have to wait or change port numbers.

Otherwise, it's working for me. I'm on myth.

-Yangfan

Paul Tarjan (TA) wrote:
> As I posted above, check if you are in network byte order. See if you 
> can bind to some ports from 1-1024. If you can, that is an error, since 
> non-root users shouldn't be able to bind to ports from 1-1024.
> 
> Filip Paun wrote:
> 
>> Hello,
>>
>> I am running in the same telnet problem as Yangfan.
>>
>> I issue the commands on two terminals:
>>      ./proxy 10001
>>    telnet localhost 10001
>>
>> and receive the following error
>>
>>    telnet: connect to address 127.0.0.1: Connection refused
>>    telnet: Unable to connect to remote host: Connection refused
>>
>> now both commands were issued on the same myth machine (in my case 
>> myth23).
>>
>> What do i need to do to solve this error? Your help is much 
>> appreciated and thank you in advance for your response.
>>
>> Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 02:55:18 -0800
Lines: 135
Distribution: su
Message-ID: <eofmin$1l0$3@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eofjbc$qg9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168858519 1696 128.12.194.72 (15 Jan 2007 10:55:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofjbc$qg9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10972

I'm running into this as well. My proxy doesn't behave properly yet, but 
at least I can telnet to it.

-Yangfan

Paul Tarjan (TA) wrote:
> The important error line that is the last one:
> 
>  > IOError: [Errno socket error] (111, 'Connection refused')
> 
> That means that it is unable to connect to anything on that port. Are 
> you sure your running your proxy on that port? Might you be binding the 
> port in the wrong 'endian'ness? There is a function that you should be 
> using whenever you are taking data from the host and changing it to 
> network byte ordering.
> 
> See if you can bind to port 1. If you can, you are doing the endianness 
> wrong, since a non-root user can't bind to port < 1024.
> 
> 
> 
> 
> Alex wrote:
> 
>> I gave a port in the valid range and I still see this issue. I was 
>> able to run my proxy on that port and use telnet and do GET correctly 
>> but I'm still having problems with the grading script.
>>
>> vine7:~/proj1> ./grade proxy.c 32454
>> Binary: proxy.c
>> Running on port 32454
>> Traceback (most recent call last):
>>   File "./grade", line 97, in ?
>>     main()
>>   File "./grade", line 42, in main
>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 82, in urlopen
>>     return opener.open(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 190, in open
>>     return getattr(self, name)(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 313, in open_http
>>     h.endheaders()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 798, in endheaders
>>     self._send_output()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 679, in _send_output
>>     self.send(msg)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 646, in send
>>     self.connect()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 630, in connect
>>     raise socket.error, msg
>> IOError: [Errno socket error] (111, 'Connection refused')
>>
>> Alex
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>
>>> TCP and UDP port numbers are 16-bit values, which means the maximum 
>>> value is
>>> 65535.  Try something between 1024 and 65535.  You also might want to 
>>> check
>>> to make sure that you're checking all your socket return values and 
>>> compiler
>>> warnings.
>>>
>>> --Justin
>>>
>>>
>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>> <axle@sonic.net> wrote:
>>>
>>>> I was trying to run the grading script on my proxy and I get the 
>>>> messages
>>>> below. Why is this happening?
>>>>
>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>> Binary: proxy.c
>>>> Running on port 98235
>>>> Traceback (most recent call last):
>>>>   File "./grade", line 100, in ?
>>>>     main()
>>>>   File "./grade", line 45, in main
>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 82, in urlopen
>>>>     return opener.open(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 190, in open
>>>>     return getattr(self, name)(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 313, in open_http
>>>>     h.endheaders()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 798, in endheaders
>>>>     self._send_output()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 679, in _send_output
>>>>     self.send(msg)
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 646, in send
>>>>     self.connect()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 630, in connect
>>>>     raise socket.error, msg
>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>
>>>>
>>>
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 09:34:53 -0800
Lines: 51
Distribution: su
Message-ID: <eogdvm$spe$1@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168882486 29486 127.0.0.1 (15 Jan 2007 17:34:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eofmfl$1l0$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10973

Yangfan Wang wrote:
> I get this error when I restart my program after it crashes. The port 
> number seems to remain allocated for about 20 seconds afterwards, and 
> I'd have to wait or change port numbers.
> 
> Otherwise, it's working for me. I'm on myth.
> 
> -Yangfan
> 
> Paul Tarjan (TA) wrote:
>> As I posted above, check if you are in network byte order. See if you 
>> can bind to some ports from 1-1024. If you can, that is an error, 
>> since non-root users shouldn't be able to bind to ports from 1-1024.
>>
>> Filip Paun wrote:
>>
>>> Hello,
>>>
>>> I am running in the same telnet problem as Yangfan.
>>>
>>> I issue the commands on two terminals:
>>>      ./proxy 10001
>>>    telnet localhost 10001
>>>
>>> and receive the following error
>>>
>>>    telnet: connect to address 127.0.0.1: Connection refused
>>>    telnet: Unable to connect to remote host: Connection refused
>>>
>>> now both commands were issued on the same myth machine (in my case 
>>> myth23).
>>>
>>> What do i need to do to solve this error? Your help is much 
>>> appreciated and thank you in advance for your response.
>>>
>>> Filip

An easy way to check that your program is actually listening correctly 
is to start up the proxy then enter the command "netstat -a" and look 
for the proper port to see if its listening.  IE:


myth21:~/> ./proxy 9988 &
[1] 18476
myth21:~/> netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:kshell                *:*                     LISTEN
tcp        0      0 *:9988                  *:*                     LISTEN

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 10:47:35 -0800
Lines: 55
Distribution: su
Message-ID: <C1D10C47.752D%jpettit@stanford.edu>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168887026 4734 127.0.0.1 (15 Jan 2007 18:50:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Telnet Error
Thread-Index: Acc41Z7+3USl/KTIEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10974

This is due to a restriction on reusing a bound port in TCP.  The kernel
wants to wait a few seconds before reusing a port to make sure that no more
traffic related to old program is received and handed to the new one.  We
will cover this in more detail when we get to TCP in the class.  Make sure
that you read the assignment FAQ, since this is the first item covered:

    http://yuba.stanford.edu/vns/proxy_faq.html

You can get around this by changing your listening port.  However, a cleaner
solution is to look into the SO_REUSEADDR socket option, which you can read
about in the Stevens book or search the web.

--Justin


On 1/15/07 2:53 AM, in article eofmfl$1l0$2@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> I get this error when I restart my program after it crashes. The port
> number seems to remain allocated for about 20 seconds afterwards, and
> I'd have to wait or change port numbers.
> 
> Otherwise, it's working for me. I'm on myth.
> 
> -Yangfan
> 
> Paul Tarjan (TA) wrote:
>> As I posted above, check if you are in network byte order. See if you
>> can bind to some ports from 1-1024. If you can, that is an error, since
>> non-root users shouldn't be able to bind to ports from 1-1024.
>> 
>> Filip Paun wrote:
>> 
>>> Hello,
>>> 
>>> I am running in the same telnet problem as Yangfan.
>>> 
>>> I issue the commands on two terminals:
>>>      ./proxy 10001
>>>    telnet localhost 10001
>>> 
>>> and receive the following error
>>> 
>>>    telnet: connect to address 127.0.0.1: Connection refused
>>>    telnet: Unable to connect to remote host: Connection refused
>>> 
>>> now both commands were issued on the same myth machine (in my case
>>> myth23).
>>> 
>>> What do i need to do to solve this error? Your help is much
>>> appreciated and thank you in advance for your response.
>>> 
>>> Filip


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Mon, 15 Jan 2007 11:46:50 -0800
Lines: 6
Distribution: su
Message-ID: <eoglm8$76b$1@news.Stanford.EDU>
References: <eocdk0$6m6$1@news.Stanford.EDU> <C1CF259C.74E6%jpettit@stanford.edu> <paun-DCC8AE.23060014012007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168890376 7371 127.0.0.1 (15 Jan 2007 19:46:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <paun-DCC8AE.23060014012007@nntp.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10975

When you bind the listening socket, do you set it to accept any IP? 
Something like the following:

servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

Greg
.

Path: shelby.stanford.edu!cardinal4.Stanford.EDU!cjuhasz
From: Christopher Monkhart Juhasz <cjuhasz@stanford.edu>
Newsgroups: su.class.cs244a
Subject: use lex/yacc?
Date: Mon, 15 Jan 2007 11:52:06 -0800
Lines: 6
Distribution: su
Message-ID: <Pine.LNX.4.44.0701151143241.4568-100000@cardinal4.Stanford.EDU>
NNTP-Posting-Host: cardinal4.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1168890730 7595 171.64.15.252 (15 Jan 2007 19:52:10 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:10976

Can we use lex/yacc to assist us in the parsing for this assignment?

Thanks,

Chris

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: use lex/yacc?
Date: Mon, 15 Jan 2007 12:29:50 -0800
Lines: 11
Distribution: su
Message-ID: <eogo7n$94k$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701151143241.4568-100000@cardinal4.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168892983 9364 127.0.0.1 (15 Jan 2007 20:29:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0701151143241.4568-100000@cardinal4.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10977

Christopher Monkhart Juhasz wrote:
> Can we use lex/yacc to assist us in the parsing for this assignment?
> 
> Thanks,
> 
> Chris
> 

Please stick with the standard C and C++ libraries for now.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 12:58:24 -0800
Lines: 21
Distribution: su
Message-ID: <eogps9$asj$1@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU> <C1D10C47.752D%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168894665 11155 127.0.0.1 (15 Jan 2007 20:57:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:10978

> This is due to a restriction on reusing a bound port in TCP.  The kernel
> wants to wait a few seconds before reusing a port to make sure that no 
> more
> traffic related to old program is received and handed to the new one.
> You can get around this by changing your listening port.  However, a 
> cleaner
> solution is to look into the SO_REUSEADDR socket option, which you can 
> read
> about in the Stevens book or search the web.
Justin,

I have been thinking about this (SO_REUSEADDR).  Is this really a cleaner 
solution, or does it allow garbage to show up on the newly opened connection 
(e.g. what the kernel was trying to prevent)?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Mon, 15 Jan 2007 14:21:58 -0800
Lines: 43
Distribution: su
Message-ID: <C1D13E86.7558%jpettit@stanford.edu>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU> <C1D10C47.752D%jpettit@stanford.edu> <eogps9$asj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168899717 16484 127.0.0.1 (15 Jan 2007 22:21:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Telnet Error
Thread-Index: Acc485Hw0Lf5kqTmEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10979

The chance of having a problem is really tiny with TCP.  When the process
dies, the kernel will mark all of the process's connections as not
available.  In order for old traffic to make it to the new process, a new
connection would have to match an old one's 5-tuple (source IP address,
destination IP address, source port, destination port, and TCP) and fall
within the TCP window.  Every TCP server I have ever written has used
SO_REUSEADDR, and I've never had a problem.

However, UDP traffic is stateless, and the kernel has no way of determining
if the traffic was for the old or new process.  So, if you're using UDP,
your application will need to keep track of whether it knows anything about
this connection (e.g. sequence numbers in the packets).  None of the
assignments in this class use UDP.

--Justin


On 1/15/07 12:58 PM, in article eogps9$asj$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

>> This is due to a restriction on reusing a bound port in TCP.  The kernel
>> wants to wait a few seconds before reusing a port to make sure that no
>> more
>> traffic related to old program is received and handed to the new one.
>> You can get around this by changing your listening port.  However, a
>> cleaner
>> solution is to look into the SO_REUSEADDR socket option, which you can
>> read
>> about in the Stevens book or search the web.
> Justin,
> 
> I have been thinking about this (SO_REUSEADDR).  Is this really a cleaner
> solution, or does it allow garbage to show up on the newly opened connection
> (e.g. what the kernel was trying to prevent)?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Timeouts
Date: Mon, 15 Jan 2007 15:15:27 -0800
Lines: 7
Distribution: su
Message-ID: <eoh1ug$j9q$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1168902928 19770 127.0.0.1 (15 Jan 2007 23:15:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:10980

 Should we implement connection timeouts in the proxy? Is it ok if reads and 
writes in the proxy block?

Thanks,
Riju 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Timeouts
Date: Mon, 15 Jan 2007 15:20:10 -0800
Lines: 11
Distribution: su
Message-ID: <eoh273$jd5$1@news.Stanford.EDU>
References: <eoh1ug$j9q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168903203 19877 127.0.0.1 (15 Jan 2007 23:20:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoh1ug$j9q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10981

Riju Kallivalappil wrote:
>  Should we implement connection timeouts in the proxy? 

This is an implementation issue and thus is up to you.

>Is it ok if reads and 
> writes in the proxy block?

I'm unsure what you mean by this.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 16:31:03 -0800
Lines: 21
Distribution: su
Message-ID: <eoh6c7$oas$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU> <eofjsc$rrk$1@news.Stanford.EDU> <eofmaf$1l0$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168907463 24924 128.12.194.72 (16 Jan 2007 00:31:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofmaf$1l0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10982

>> You might want to compare a h_addr to a in_addr_t. The similarities 
>> might alarm you.
>>
> 
> Hmm. So I casted h_addr_list[0], which is a char*, to in_addr_t, but the 
> call to bind still failed. (I checked that the endianess is correct. I 
> translate it to host byte order when I obtain the value and translate 
> back to network byte order before attempting to bind.)
> 
> Are you sure it's not an IP string like "127.0.0.1"? Why else would it 
> be a char*? And why would I need inet_addr if I can jump straight to the 
> 32-bit IP address?
> 
> I know gethostbyname is giving me a valid hostent struct. I just need to 
>  figure out which field will get me to the IP address.
> 

Really could use some help here. Like Paul said, I'm 2 minutes away from 
the solution. Just need a little push here.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 16:54:41 -0800
Lines: 26
Distribution: su
Message-ID: <eoh7oa$ppp$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU> <eofjsc$rrk$1@news.Stanford.EDU> <eofmaf$1l0$1@news.Stanford.EDU> <eoh6c7$oas$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168908874 26425 127.0.0.1 (16 Jan 2007 00:54:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoh6c7$oas$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10983

Yangfan Wang wrote:
>>> You might want to compare a h_addr to a in_addr_t. The similarities 
>>> might alarm you.
>>>
>>
>> Hmm. So I casted h_addr_list[0], which is a char*, to in_addr_t, but 
>> the call to bind still failed. (I checked that the endianess is 
>> correct. I translate it to host byte order when I obtain the value and 
>> translate back to network byte order before attempting to bind.)
>>
>> Are you sure it's not an IP string like "127.0.0.1"? Why else would it 
>> be a char*? And why would I need inet_addr if I can jump straight to 
>> the 32-bit IP address?
>>
>> I know gethostbyname is giving me a valid hostent struct. I just need 
>> to  figure out which field will get me to the IP address.
>>
> 
> Really could use some help here. Like Paul said, I'm 2 minutes away from 
> the solution. Just need a little push here.
> 
> -Yangfan

Take a look at pages 308-310 of the Unix Network Programming book.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Shahryar" <shahryar@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Segmentation Fault
Date: Mon, 15 Jan 2007 17:07:50 -0800
Lines: 4
Distribution: su
Message-ID: <eoh8h7$qr1$1@news.Stanford.EDU>
NNTP-Posting-Host: m160-07-s270-cl.stanford.edu
X-Trace: news.Stanford.EDU 1168909671 27489 171.64.139.15 (16 Jan 2007 01:07:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:10984

I am getting this error "Segmentation fault" although I am trying different 
ports but still I am getting the same error .


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Segmentation Fault
Date: Mon, 15 Jan 2007 17:13:27 -0800
Lines: 8
Distribution: su
Message-ID: <eoh8rg$r4r$1@news.Stanford.EDU>
References: <eoh8h7$qr1$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168910000 27803 127.0.0.1 (16 Jan 2007 01:13:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoh8h7$qr1$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10985

Shahryar wrote:
> I am getting this error "Segmentation fault" although I am trying different 
> ports but still I am getting the same error .

Try using valgrind, it can help locate memory errors which generally 
cause seg faults.  There are many guides around just google it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 17:43:28 -0800
Lines: 40
Distribution: su
Message-ID: <eohak5$svm$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU> <eofjsc$rrk$1@news.Stanford.EDU> <eofmaf$1l0$1@news.Stanford.EDU> <eoh6c7$oas$1@news.Stanford.EDU> <eoh7oa$ppp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168911813 29686 128.12.194.72 (16 Jan 2007 01:43:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eoh7oa$ppp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10986

David Erickson wrote:
> Yangfan Wang wrote:
> 
>>>> You might want to compare a h_addr to a in_addr_t. The similarities 
>>>> might alarm you.
>>>>
>>>
>>> Hmm. So I casted h_addr_list[0], which is a char*, to in_addr_t, but 
>>> the call to bind still failed. (I checked that the endianess is 
>>> correct. I translate it to host byte order when I obtain the value 
>>> and translate back to network byte order before attempting to bind.)
>>>
>>> Are you sure it's not an IP string like "127.0.0.1"? Why else would 
>>> it be a char*? And why would I need inet_addr if I can jump straight 
>>> to the 32-bit IP address?
>>>
>>> I know gethostbyname is giving me a valid hostent struct. I just need 
>>> to  figure out which field will get me to the IP address.
>>>
>>
>> Really could use some help here. Like Paul said, I'm 2 minutes away 
>> from the solution. Just need a little push here.
>>
>> -Yangfan
> 
> 
> Take a look at pages 308-310 of the Unix Network Programming book.
> 
> -David

Okay, using the debugging code from page 309, I get:

official host name = www.yahoo-ht2.akadns.net
         alias = www.yahoo.com
         address = (null)

Do you guys know what might cause this? Note that the official host name 
was correctly obtained. My input was "www.yahoo.com".

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on gethostbyname
Date: Mon, 15 Jan 2007 17:49:55 -0800
Lines: 46
Distribution: su
Message-ID: <eohavs$suu$1@news.Stanford.EDU>
References: <eoekn7$nr1$1@news.Stanford.EDU> <eofhjl$p1f$1@news.Stanford.EDU> <eofjsc$rrk$1@news.Stanford.EDU> <eofmaf$1l0$1@news.Stanford.EDU> <eoh6c7$oas$1@news.Stanford.EDU> <eoh7oa$ppp$1@news.Stanford.EDU> <eohak5$svm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168912188 29662 127.0.0.1 (16 Jan 2007 01:49:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eohak5$svm$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10987

Yangfan Wang wrote:
> David Erickson wrote:
>> Yangfan Wang wrote:
>>
>>>>> You might want to compare a h_addr to a in_addr_t. The similarities 
>>>>> might alarm you.
>>>>>
>>>>
>>>> Hmm. So I casted h_addr_list[0], which is a char*, to in_addr_t, but 
>>>> the call to bind still failed. (I checked that the endianess is 
>>>> correct. I translate it to host byte order when I obtain the value 
>>>> and translate back to network byte order before attempting to bind.)
>>>>
>>>> Are you sure it's not an IP string like "127.0.0.1"? Why else would 
>>>> it be a char*? And why would I need inet_addr if I can jump straight 
>>>> to the 32-bit IP address?
>>>>
>>>> I know gethostbyname is giving me a valid hostent struct. I just 
>>>> need to  figure out which field will get me to the IP address.
>>>>
>>>
>>> Really could use some help here. Like Paul said, I'm 2 minutes away 
>>> from the solution. Just need a little push here.
>>>
>>> -Yangfan
>>
>>
>> Take a look at pages 308-310 of the Unix Network Programming book.
>>
>> -David
> 
> Okay, using the debugging code from page 309, I get:
> 
> official host name = www.yahoo-ht2.akadns.net
>         alias = www.yahoo.com
>         address = (null)
> 
> Do you guys know what might cause this? Note that the official host name 
> was correctly obtained. My input was "www.yahoo.com".
> 
> -Yangfan

inet_ntop returns null on an error, find out what the error was, and go 
from there.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: recv: Connection reset by peer
Date: Mon, 15 Jan 2007 18:14:02 -0800
Lines: 11
Distribution: su
Message-ID: <eohcda$s9n$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1168913642 28983 127.0.0.1 (16 Jan 2007 02:14:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:10988

After I send a GET request to certain sites (actually, I've only 
observed this with google.com (66.102.7.99) -- yahoo.com and other 
sites don't exhibit this), I get an error while trying to receive the 
web page data. It says, "recv: Connection reset by peer". Anybody know 
what could cause that kind of error? I assume it's a socket setting or 
something, but I can't seem to make it work.





.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: recv: Connection reset by peer
Date: Mon, 15 Jan 2007 18:28:46 -0800
Lines: 15
Distribution: su
Message-ID: <eohd8n$1oe$1@news.Stanford.EDU>
References: <eohcda$s9n$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168914519 1806 127.0.0.1 (16 Jan 2007 02:28:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eohcda$s9n$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10989

Adam Cohen wrote:
> After I send a GET request to certain sites (actually, I've only 
> observed this with google.com (66.102.7.99) -- yahoo.com and other sites 
> don't exhibit this), I get an error while trying to receive the web page 
> data. It says, "recv: Connection reset by peer". Anybody know what could 
> cause that kind of error? I assume it's a socket setting or something, 
> but I can't seem to make it work.
> 

If your able to download webpages from other sites besides google, i 
would recommend that you take a look and ensure your requests are 
properly formatted per the rfc, perhaps compare a request from your 
webbrowser directly to google versus one you make through a proxy.

-David
.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: How much to read()
Date: Mon, 15 Jan 2007 20:58:46 -0800
Lines: 8
Distribution: su
Message-ID: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1168923528 10388 171.64.66.201 (16 Jan 2007 04:58:48 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:10990


The read system call in man page section 2 indicates that we have to 
specify how much to read from the socket/descriptor. How do we know in 
advance how much the HTTP Request sent in is or how long a server's 
response is? Do we "try" to read as much as possible, up to ssize_max 
(something like that? I forgot), and then process the buffer?

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 21:12:15 -0800
Lines: 136
Distribution: su
Message-ID: <eohms2$b2q$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eofjbc$qg9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168924354 11354 128.12.194.72 (16 Jan 2007 05:12:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eofjbc$qg9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10991

Okay, my proxy is (marginally) working now, and I'm getting the same 
error as Alex when I run the grading script. Could the TAs please look 
into this?

-Yangfan

Paul Tarjan (TA) wrote:
> The important error line that is the last one:
> 
>  > IOError: [Errno socket error] (111, 'Connection refused')
> 
> That means that it is unable to connect to anything on that port. Are 
> you sure your running your proxy on that port? Might you be binding the 
> port in the wrong 'endian'ness? There is a function that you should be 
> using whenever you are taking data from the host and changing it to 
> network byte ordering.
> 
> See if you can bind to port 1. If you can, you are doing the endianness 
> wrong, since a non-root user can't bind to port < 1024.
> 
> 
> 
> 
> Alex wrote:
> 
>> I gave a port in the valid range and I still see this issue. I was 
>> able to run my proxy on that port and use telnet and do GET correctly 
>> but I'm still having problems with the grading script.
>>
>> vine7:~/proj1> ./grade proxy.c 32454
>> Binary: proxy.c
>> Running on port 32454
>> Traceback (most recent call last):
>>   File "./grade", line 97, in ?
>>     main()
>>   File "./grade", line 42, in main
>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 82, in urlopen
>>     return opener.open(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 190, in open
>>     return getattr(self, name)(url)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>> line 313, in open_http
>>     h.endheaders()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 798, in endheaders
>>     self._send_output()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 679, in _send_output
>>     self.send(msg)
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 646, in send
>>     self.connect()
>>   File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>> line 630, in connect
>>     raise socket.error, msg
>> IOError: [Errno socket error] (111, 'Connection refused')
>>
>> Alex
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>
>>> TCP and UDP port numbers are 16-bit values, which means the maximum 
>>> value is
>>> 65535.  Try something between 1024 and 65535.  You also might want to 
>>> check
>>> to make sure that you're checking all your socket return values and 
>>> compiler
>>> warnings.
>>>
>>> --Justin
>>>
>>>
>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>> <axle@sonic.net> wrote:
>>>
>>>> I was trying to run the grading script on my proxy and I get the 
>>>> messages
>>>> below. Why is this happening?
>>>>
>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>> Binary: proxy.c
>>>> Running on port 98235
>>>> Traceback (most recent call last):
>>>>   File "./grade", line 100, in ?
>>>>     main()
>>>>   File "./grade", line 45, in main
>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 82, in urlopen
>>>>     return opener.open(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 190, in open
>>>>     return getattr(self, name)(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 313, in open_http
>>>>     h.endheaders()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 798, in endheaders
>>>>     self._send_output()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 679, in _send_output
>>>>     self.send(msg)
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 646, in send
>>>>     self.connect()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>>> line
>>>> 630, in connect
>>>>     raise socket.error, msg
>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>
>>>>
>>>
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 21:30:05 -0800
Lines: 146
Distribution: su
Message-ID: <C1D1A2DD.757B%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eofjbc$qg9$1@news.Stanford.EDU> <eohms2$b2q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168925406 13026 127.0.0.1 (16 Jan 2007 05:30:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: Acc5L2CVnw+6iKUiEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10992

I just ran it again.  It works.

--Justin


On 1/15/07 9:12 PM, in article eohms2$b2q$1@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> Okay, my proxy is (marginally) working now, and I'm getting the same
> error as Alex when I run the grading script. Could the TAs please look
> into this?
> 
> -Yangfan
> 
> Paul Tarjan (TA) wrote:
>> The important error line that is the last one:
>> 
>>> IOError: [Errno socket error] (111, 'Connection refused')
>> 
>> That means that it is unable to connect to anything on that port. Are
>> you sure your running your proxy on that port? Might you be binding the
>> port in the wrong 'endian'ness? There is a function that you should be
>> using whenever you are taking data from the host and changing it to
>> network byte ordering.
>> 
>> See if you can bind to port 1. If you can, you are doing the endianness
>> wrong, since a non-root user can't bind to port < 1024.
>> 
>> 
>> 
>> 
>> Alex wrote:
>> 
>>> I gave a port in the valid range and I still see this issue. I was
>>> able to run my proxy on that port and use telnet and do GET correctly
>>> but I'm still having problems with the grading script.
>>> 
>>> vine7:~/proj1> ./grade proxy.c 32454
>>> Binary: proxy.c
>>> Running on port 32454
>>> Traceback (most recent call last):
>>>   File "./grade", line 97, in ?
>>>     main()
>>>   File "./grade", line 42, in main
>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 82, in urlopen
>>>     return opener.open(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 190, in open
>>>     return getattr(self, name)(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 313, in open_http
>>>     h.endheaders()
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 798, in endheaders
>>>     self._send_output()
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 679, in _send_output
>>>     self.send(msg)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 646, in send
>>>     self.connect()
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 630, in connect
>>>     raise socket.error, msg
>>> IOError: [Errno socket error] (111, 'Connection refused')
>>> 
>>> Alex
>>> 
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>> 
>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>> value is
>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>> check
>>>> to make sure that you're checking all your socket return values and
>>>> compiler
>>>> warnings.
>>>> 
>>>> --Justin
>>>> 
>>>> 
>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>> <axle@sonic.net> wrote:
>>>> 
>>>>> I was trying to run the grading script on my proxy and I get the
>>>>> messages
>>>>> below. Why is this happening?
>>>>> 
>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>> Binary: proxy.c
>>>>> Running on port 98235
>>>>> Traceback (most recent call last):
>>>>>   File "./grade", line 100, in ?
>>>>>     main()
>>>>>   File "./grade", line 45, in main
>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>   File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 82, in urlopen
>>>>>     return opener.open(url)
>>>>>   File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 190, in open
>>>>>     return getattr(self, name)(url)
>>>>>   File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 313, in open_http
>>>>>     h.endheaders()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 798, in endheaders
>>>>>     self._send_output()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 679, in _send_output
>>>>>     self.send(msg)
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 646, in send
>>>>>     self.connect()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 630, in connect
>>>>>     raise socket.error, msg
>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 22:48:23 -0800
Lines: 169
Distribution: su
Message-ID: <eohsgb$i78$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eofjbc$qg9$1@news.Stanford.EDU> <eohms2$b2q$1@news.Stanford.EDU> <C1D1A2DD.757B%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168930123 18664 128.12.194.72 (16 Jan 2007 06:48:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1D1A2DD.757B%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:10993

Ah. I see it.

I probably wasn't paying attention when you guys mentioned that the 
proxy should accept requests continuously. The grading script will crash 
otherwise.

One other issue though:

Basic HTTP transactions: 4 of 5 tests passed
Summary:
         4 of 5 tests passed.
Base Score: 0/10 (Remember, one point is based on style!)

If I pass 4 out of the 5 basic tests, then why is my base score still 0?

-Yangfan

Justin Pettit wrote:
> I just ran it again.  It works.
> 
> --Justin
> 
> 
> On 1/15/07 9:12 PM, in article eohms2$b2q$1@news.Stanford.EDU, "Yangfan
> Wang" <yfw@stanford.edu> wrote:
> 
> 
>>Okay, my proxy is (marginally) working now, and I'm getting the same
>>error as Alex when I run the grading script. Could the TAs please look
>>into this?
>>
>>-Yangfan
>>
>>Paul Tarjan (TA) wrote:
>>
>>>The important error line that is the last one:
>>>
>>>
>>>>IOError: [Errno socket error] (111, 'Connection refused')
>>>
>>>That means that it is unable to connect to anything on that port. Are
>>>you sure your running your proxy on that port? Might you be binding the
>>>port in the wrong 'endian'ness? There is a function that you should be
>>>using whenever you are taking data from the host and changing it to
>>>network byte ordering.
>>>
>>>See if you can bind to port 1. If you can, you are doing the endianness
>>>wrong, since a non-root user can't bind to port < 1024.
>>>
>>>
>>>
>>>
>>>Alex wrote:
>>>
>>>
>>>>I gave a port in the valid range and I still see this issue. I was
>>>>able to run my proxy on that port and use telnet and do GET correctly
>>>>but I'm still having problems with the grading script.
>>>>
>>>>vine7:~/proj1> ./grade proxy.c 32454
>>>>Binary: proxy.c
>>>>Running on port 32454
>>>>Traceback (most recent call last):
>>>>  File "./grade", line 97, in ?
>>>>    main()
>>>>  File "./grade", line 42, in main
>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>line 82, in urlopen
>>>>    return opener.open(url)
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>line 190, in open
>>>>    return getattr(self, name)(url)
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>line 313, in open_http
>>>>    h.endheaders()
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>line 798, in endheaders
>>>>    self._send_output()
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>line 679, in _send_output
>>>>    self.send(msg)
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>line 646, in send
>>>>    self.connect()
>>>>  File 
>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>line 630, in connect
>>>>    raise socket.error, msg
>>>>IOError: [Errno socket error] (111, 'Connection refused')
>>>>
>>>>Alex
>>>>
>>>>"Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>
>>>>
>>>>>TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>>value is
>>>>>65535.  Try something between 1024 and 65535.  You also might want to
>>>>>check
>>>>>to make sure that you're checking all your socket return values and
>>>>>compiler
>>>>>warnings.
>>>>>
>>>>>--Justin
>>>>>
>>>>>
>>>>>On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>><axle@sonic.net> wrote:
>>>>>
>>>>>
>>>>>>I was trying to run the grading script on my proxy and I get the
>>>>>>messages
>>>>>>below. Why is this happening?
>>>>>>
>>>>>>vine7:~/proj1> ./grade proxy.c 98235
>>>>>>Binary: proxy.c
>>>>>>Running on port 98235
>>>>>>Traceback (most recent call last):
>>>>>>  File "./grade", line 100, in ?
>>>>>>    main()
>>>>>>  File "./grade", line 45, in main
>>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>  File 
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>line 82, in urlopen
>>>>>>    return opener.open(url)
>>>>>>  File 
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>line 190, in open
>>>>>>    return getattr(self, name)(url)
>>>>>>  File 
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>line 313, in open_http
>>>>>>    h.endheaders()
>>>>>>  File
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>line
>>>>>>798, in endheaders
>>>>>>    self._send_output()
>>>>>>  File
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>line
>>>>>>679, in _send_output
>>>>>>    self.send(msg)
>>>>>>  File
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>line
>>>>>>646, in send
>>>>>>    self.connect()
>>>>>>  File
>>>>>>"/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>line
>>>>>>630, in connect
>>>>>>    raise socket.error, msg
>>>>>>IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>
>>>>>>
>>>>>
>>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Mon, 15 Jan 2007 22:55:02 -0800
Lines: 180
Distribution: su
Message-ID: <C1D1B6C6.7582%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eofjbc$qg9$1@news.Stanford.EDU> <eohms2$b2q$1@news.Stanford.EDU> <C1D1A2DD.757B%jpettit@stanford.edu> <eohsgb$i78$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168930499 19100 127.0.0.1 (16 Jan 2007 06:54:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: Acc5Oz6hfTXCR6UuEduhVAARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10994

Yes, THAT is a bug in the grading script.  Don't pay attention to the
returned score right now.

--Justin


On 1/15/07 10:48 PM, in article eohsgb$i78$1@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> Ah. I see it.
> 
> I probably wasn't paying attention when you guys mentioned that the
> proxy should accept requests continuously. The grading script will crash
> otherwise.
> 
> One other issue though:
> 
> Basic HTTP transactions: 4 of 5 tests passed
> Summary:
>          4 of 5 tests passed.
> Base Score: 0/10 (Remember, one point is based on style!)
> 
> If I pass 4 out of the 5 basic tests, then why is my base score still 0?
> 
> -Yangfan
> 
> Justin Pettit wrote:
>> I just ran it again.  It works.
>> 
>> --Justin
>> 
>> 
>> On 1/15/07 9:12 PM, in article eohms2$b2q$1@news.Stanford.EDU, "Yangfan
>> Wang" <yfw@stanford.edu> wrote:
>> 
>> 
>>> Okay, my proxy is (marginally) working now, and I'm getting the same
>>> error as Alex when I run the grading script. Could the TAs please look
>>> into this?
>>> 
>>> -Yangfan
>>> 
>>> Paul Tarjan (TA) wrote:
>>> 
>>>> The important error line that is the last one:
>>>> 
>>>> 
>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>> 
>>>> That means that it is unable to connect to anything on that port. Are
>>>> you sure your running your proxy on that port? Might you be binding the
>>>> port in the wrong 'endian'ness? There is a function that you should be
>>>> using whenever you are taking data from the host and changing it to
>>>> network byte ordering.
>>>> 
>>>> See if you can bind to port 1. If you can, you are doing the endianness
>>>> wrong, since a non-root user can't bind to port < 1024.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Alex wrote:
>>>> 
>>>> 
>>>>> I gave a port in the valid range and I still see this issue. I was
>>>>> able to run my proxy on that port and use telnet and do GET correctly
>>>>> but I'm still having problems with the grading script.
>>>>> 
>>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>>> Binary: proxy.c
>>>>> Running on port 32454
>>>>> Traceback (most recent call last):
>>>>>  File "./grade", line 97, in ?
>>>>>    main()
>>>>>  File "./grade", line 42, in main
>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 82, in urlopen
>>>>>    return opener.open(url)
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 190, in open
>>>>>    return getattr(self, name)(url)
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 313, in open_http
>>>>>    h.endheaders()
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 798, in endheaders
>>>>>    self._send_output()
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 679, in _send_output
>>>>>    self.send(msg)
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 646, in send
>>>>>    self.connect()
>>>>>  File 
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 630, in connect
>>>>>    raise socket.error, msg
>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>> 
>>>>> Alex
>>>>> 
>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>> 
>>>>> 
>>>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>>> value is
>>>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>>>> check
>>>>>> to make sure that you're checking all your socket return values and
>>>>>> compiler
>>>>>> warnings.
>>>>>> 
>>>>>> --Justin
>>>>>> 
>>>>>> 
>>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>>> <axle@sonic.net> wrote:
>>>>>> 
>>>>>> 
>>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>>> messages
>>>>>>> below. Why is this happening?
>>>>>>> 
>>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>>> Binary: proxy.c
>>>>>>> Running on port 98235
>>>>>>> Traceback (most recent call last):
>>>>>>>  File "./grade", line 100, in ?
>>>>>>>    main()
>>>>>>>  File "./grade", line 45, in main
>>>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>  File 
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 82, in urlopen
>>>>>>>    return opener.open(url)
>>>>>>>  File 
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 190, in open
>>>>>>>    return getattr(self, name)(url)
>>>>>>>  File 
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 313, in open_http
>>>>>>>    h.endheaders()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 798, in endheaders
>>>>>>>    self._send_output()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 679, in _send_output
>>>>>>>    self.send(msg)
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 646, in send
>>>>>>>    self.connect()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 630, in connect
>>>>>>>    raise socket.error, msg
>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Mon, 15 Jan 2007 23:22:26 -0800
Lines: 13
Distribution: su
Message-ID: <eohufb$k3i$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168932139 20594 127.0.0.1 (16 Jan 2007 07:22:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:10995

Ryan Chen wrote:
> 
> The read system call in man page section 2 indicates that we have to 
> specify how much to read from the socket/descriptor. How do we know in 
> advance how much the HTTP Request sent in is or how long a server's 
> response is? Do we "try" to read as much as possible, up to ssize_max 
> (something like that? I forgot), and then process the buffer?
> 
> Thanks.

Yes.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Tue, 16 Jan 2007 00:53:12 -0800
Lines: 59
Distribution: su
Message-ID: <eoi3ps$su3$1@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU> <C1D10C47.752D%jpettit@stanford.edu> <eogps9$asj$1@news.Stanford.EDU> <C1D13E86.7558%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1168937596 29635 127.0.0.1 (16 Jan 2007 08:53:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:10996

How do you implement SO_REUSEADDR?  I thought it was in socket.h.  I'm 
tryinng the code below, but I get the message "proxy.c:(.text+0x2ae): 
undefined reference to 'setsocketopt'"

setsockopt_ret = setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, (void *) 
&sock_opt, sizeof(sock_opt));

--Brian

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D13E86.7558%jpettit@stanford.edu...
> The chance of having a problem is really tiny with TCP.  When the process
> dies, the kernel will mark all of the process's connections as not
> available.  In order for old traffic to make it to the new process, a new
> connection would have to match an old one's 5-tuple (source IP address,
> destination IP address, source port, destination port, and TCP) and fall
> within the TCP window.  Every TCP server I have ever written has used
> SO_REUSEADDR, and I've never had a problem.
>
> However, UDP traffic is stateless, and the kernel has no way of 
> determining
> if the traffic was for the old or new process.  So, if you're using UDP,
> your application will need to keep track of whether it knows anything 
> about
> this connection (e.g. sequence numbers in the packets).  None of the
> assignments in this class use UDP.
>
> --Justin
>
>
> On 1/15/07 12:58 PM, in article eogps9$asj$1@news.Stanford.EDU, "Randy
> Jennings" <randyj@stanford.edu> wrote:
>
>>> This is due to a restriction on reusing a bound port in TCP.  The kernel
>>> wants to wait a few seconds before reusing a port to make sure that no
>>> more
>>> traffic related to old program is received and handed to the new one.
>>> You can get around this by changing your listening port.  However, a
>>> cleaner
>>> solution is to look into the SO_REUSEADDR socket option, which you can
>>> read
>>> about in the Stevens book or search the web.
>> Justin,
>>
>> I have been thinking about this (SO_REUSEADDR).  Is this really a cleaner
>> solution, or does it allow garbage to show up on the newly opened 
>> connection
>> (e.g. what the kernel was trying to prevent)?
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Tue, 16 Jan 2007 01:05:29 -0800
Lines: 59
Distribution: su
Message-ID: <eoi4gr$6n$1@news.Stanford.EDU>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU> <C1D10C47.752D%jpettit@stanford.edu> <eogps9$asj$1@news.Stanford.EDU> <C1D13E86.7558%jpettit@stanford.edu> <eoi3ps$su3$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1168938331 215 128.12.104.53 (16 Jan 2007 09:05:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:10997

Try setsockopt instead of setsocketopt in your actual code...

P.

On 2007-01-16 00:53:12 -0800, "Brian Thompson" 
<Brian.C.Thompson@Boeing.com> said:

> How do you implement SO_REUSEADDR?  I thought it was in socket.h.  I'm 
> tryinng the code below, but I get the message "proxy.c:(.text+0x2ae): 
> undefined reference to 'setsocketopt'"
> 
> setsockopt_ret = setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, (void *) 
> &sock_opt, sizeof(sock_opt));
> 
> --Brian
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1D13E86.7558%jpettit@stanford.edu...
>> The chance of having a problem is really tiny with TCP.  When the process
>> dies, the kernel will mark all of the process's connections as not
>> available.  In order for old traffic to make it to the new process, a new
>> connection would have to match an old one's 5-tuple (source IP address,
>> destination IP address, source port, destination port, and TCP) and fall
>> within the TCP window.  Every TCP server I have ever written has used
>> SO_REUSEADDR, and I've never had a problem.
>> 
>> However, UDP traffic is stateless, and the kernel has no way of determining
>> if the traffic was for the old or new process.  So, if you're using UDP,
>> your application will need to keep track of whether it knows anything about
>> this connection (e.g. sequence numbers in the packets).  None of the
>> assignments in this class use UDP.
>> 
>> --Justin
>> 
>> 
>> On 1/15/07 12:58 PM, in article eogps9$asj$1@news.Stanford.EDU, "Randy
>> Jennings" <randyj@stanford.edu> wrote:
>> 
>>>> This is due to a restriction on reusing a bound port in TCP.  The kernel
>>>> wants to wait a few seconds before reusing a port to make sure that no
>>>> more
>>>> traffic related to old program is received and handed to the new one.
>>>> You can get around this by changing your listening port.  However, a
>>>> cleaner
>>>> solution is to look into the SO_REUSEADDR socket option, which you can
>>>> read
>>>> about in the Stevens book or search the web.
>>> Justin,
>>> 
>>> I have been thinking about this (SO_REUSEADDR).  Is this really a cleaner
>>> solution, or does it allow garbage to show up on the newly opened connection
>>> (e.g. what the kernel was trying to prevent)?
>>> 
>>> Sincerely,
>>> Randy Jennings
>>> 
>>> The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet Error
Date: Tue, 16 Jan 2007 01:29:23 -0800
Lines: 75
Distribution: su
Message-ID: <C1D1DAF3.758D%jpettit@stanford.edu>
References: <paun-C442BE.23113414012007@nntp.stanford.edu> <eofk3u$rrk$3@news.Stanford.EDU> <eofmfl$1l0$2@news.Stanford.EDU> <C1D10C47.752D%jpettit@stanford.edu> <eogps9$asj$1@news.Stanford.EDU> <C1D13E86.7558%jpettit@stanford.edu> <eoi3ps$su3$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168939765 2259 127.0.0.1 (16 Jan 2007 09:29:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Telnet Error
Thread-Index: Acc5UM6eDQ/xgKVEEdufOgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:10998

I agree with Peter.  It looks like there's some sort of disconnect between
your code snippet and your error message.  I don't see anything wrong with
what you've shown. 

If you haven't set your dependencies correctly in your makefile, then fixed
typos may still show linker problems.  You may want to "make clean" and
remove any old object files.

--Justin


On 1/16/07 12:53 AM, in article eoi3ps$su3$1@news.Stanford.EDU, "Brian
Thompson" <Brian.C.Thompson@Boeing.com> wrote:

> How do you implement SO_REUSEADDR?  I thought it was in socket.h.  I'm
> tryinng the code below, but I get the message "proxy.c:(.text+0x2ae):
> undefined reference to 'setsocketopt'"
> 
> setsockopt_ret = setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, (void *)
> &sock_opt, sizeof(sock_opt));
> 
> --Brian
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D13E86.7558%jpettit@stanford.edu...
>> The chance of having a problem is really tiny with TCP.  When the process
>> dies, the kernel will mark all of the process's connections as not
>> available.  In order for old traffic to make it to the new process, a new
>> connection would have to match an old one's 5-tuple (source IP address,
>> destination IP address, source port, destination port, and TCP) and fall
>> within the TCP window.  Every TCP server I have ever written has used
>> SO_REUSEADDR, and I've never had a problem.
>> 
>> However, UDP traffic is stateless, and the kernel has no way of
>> determining
>> if the traffic was for the old or new process.  So, if you're using UDP,
>> your application will need to keep track of whether it knows anything
>> about
>> this connection (e.g. sequence numbers in the packets).  None of the
>> assignments in this class use UDP.
>> 
>> --Justin
>> 
>> 
>> On 1/15/07 12:58 PM, in article eogps9$asj$1@news.Stanford.EDU, "Randy
>> Jennings" <randyj@stanford.edu> wrote:
>> 
>>>> This is due to a restriction on reusing a bound port in TCP.  The kernel
>>>> wants to wait a few seconds before reusing a port to make sure that no
>>>> more
>>>> traffic related to old program is received and handed to the new one.
>>>> You can get around this by changing your listening port.  However, a
>>>> cleaner
>>>> solution is to look into the SO_REUSEADDR socket option, which you can
>>>> read
>>>> about in the Stevens book or search the web.
>>> Justin,
>>> 
>>> I have been thinking about this (SO_REUSEADDR).  Is this really a cleaner
>>> solution, or does it allow garbage to show up on the newly opened
>>> connection
>>> (e.g. what the kernel was trying to prevent)?
>>> 
>>> Sincerely,
>>> Randy Jennings
>>> 
>>> The squirrels are your friends!
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Tue, 16 Jan 2007 10:26:39 -0800
Lines: 18
Distribution: su
Message-ID: <eoj5da$eag$1@news.Stanford.EDU>
References: <eocdk0$6m6$1@news.Stanford.EDU> <C1CF259C.74E6%jpettit@stanford.edu> <paun-DCC8AE.23060014012007@nntp.stanford.edu> <eoglm8$76b$1@news.Stanford.EDU>
NNTP-Posting-Host: dhcpvisitor217232.slac.stanford.edu
X-Trace: news.Stanford.EDU 1168972010 14672 198.129.217.232 (16 Jan 2007 18:26:50 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:10999

Try to use 'ifconfig' on the proxy server on which you bind the proxy.

 then use telnet <IP_ADDRESS_OF_SERVER> <port> instead of localhost.

best regards..
Asif


"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:eoglm8$76b$1@news.Stanford.EDU...
> When you bind the listening socket, do you set it to accept any IP? 
> Something like the following:
>
> servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
>
> Greg 


.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: grading script
Date: Tue, 16 Jan 2007 11:03:48 -0800
Lines: 126
Distribution: su
Message-ID: <eoj7in$go8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168974231 17160 127.0.0.1 (16 Jan 2007 19:03:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11000

Hello,

I'm running the grading script using

	./proxy_grader.py proxy 1224

and am getting

	Binary: proxy
	Running on port 1224
	Basic HTTP transactions: 5 of 5 tests passed
	Summary:
         	5 of 5 tests passed.
	Base Score: 8/10 (Remember, one point is based on style!)

However, I changed my code to always use the url http://www.google.com/, 
so I should be passing only one of the five tests.

Am I using the script incorrectly?

Thanks,
Yuliya

P.S.

The grading script I have is


#!/usr/bin/env python

import urllib
import sys
import os
import signal
import time
try:
      import proxy_grade_private
      use_private = True
except ImportError:
      use_private = False

# You can create additional automated tests for your proxy by
# adding URLs to this array.  This will have no effect on your
# grade, but may be helpful in testing and debugging your proxy.
pub_urls = ['http://www.google.com/', 'HTTP://www.stanford.edu/',
                'http://WWW.microsoft.com/en/us/default.aspx',
                'http://search.yahoo.com/search?p=proxy&ei=UTF-8',
                'http://yuba.stanford.edu/vns/images/su.gif']

def main():
      global pub_urls
      try:
           proxy_bin = sys.argv[1]
           port = sys.argv[2]
      except IndexError:
           usage()
           sys.exit(2)

      print 'Binary: %s' % proxy_bin
      print 'Running on port %s' % port

      # Start the proxy running in the background
      cid = os.spawnl(os.P_NOWAIT, proxy_bin, proxy_bin, port)
      # Give the proxy time to start up and start listening on the port
      time.sleep(2)
      proxy_map = {'http':'http://localhost:' + port}

      foblist = []
      for url in pub_urls:
           foblist.append(urllib.urlopen(url, None, proxy_map))

      passcount = 0
      for n in range(len(foblist)):
           proxy_file = foblist[n]
           lines = proxy_file.readlines()
           if (len(lines) == 0):
                print "No data received for " + pub_urls[n]
                continue

           direct_file = urllib.urlopen(pub_urls[n])
           direct_lines = direct_file.readlines()

           for (prox_line, dir_line) in zip(lines, direct_lines):
                if prox_line != dir_line:
                     direct_file.close()
                     continue

           direct_file.close()
           passcount += 1

      for fob in foblist:
           fob.close()

      print r'Basic HTTP transactions: %d of %d tests passed' % 
(passcount, len(pub_urls))


      if (use_private):
           priv_passed = proxy_grade_private.runall(port, cid)


      # Cleanup
      os.kill(cid, signal.SIGINT)
      os.kill(cid, signal.SIGKILL)
      os.waitpid(cid, 0)

      print 'Summary: '
      print '\t%d of %d tests passed.' % (passcount, len(pub_urls))
      score = 0
      if (use_private):
           if (priv_passed):
                print '\t100% of extended tests passed.'
                score += 1
           else:
                print'\tNot all extended tests passed.'

      score += (passcount / len(pub_urls)) * 8
      print 'Base Score: %d/10 (Remember, one point is based on style!)' 
% score

def usage():
      print "Usage: proxy_grader.py path/to/proxy/binary port"


if __name__ == '__main__':
      main()
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cannot telnet to localhost?
Date: Tue, 16 Jan 2007 13:23:32 -0800
Lines: 18
Distribution: su
Message-ID: <C1D28254.75CF%jpettit@stanford.edu>
References: <eocdk0$6m6$1@news.Stanford.EDU> <C1CF259C.74E6%jpettit@stanford.edu> <paun-DCC8AE.23060014012007@nntp.stanford.edu> <eoglm8$76b$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168982614 29174 127.0.0.1 (16 Jan 2007 21:23:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Cannot telnet to localhost?
Thread-Index: Acc5tJKc0PN6RaWnEdufuQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11001

I would recommend doing this, since it will cause your server to bind all
interfaces.  Specifying an interface can be useful if you want to present
different services to different networks.

--Justin


On 1/15/07 11:46 AM, in article eoglm8$76b$1@news.Stanford.EDU, "Greg
Nelson" <grourk@stanford.edu> wrote:

> When you bind the listening socket, do you set it to accept any IP?
> Something like the following:
> 
> servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
> 
> Greg


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 15:28:11 -0800
Lines: 5
Distribution: su
Message-ID: <eojn4s$6um$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168990173 7126 171.64.74.54 (16 Jan 2007 23:29:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eoj7in$go8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11002

There was a bug in the grading script that was causing it to mis-report 
some test results.  Please download the new version of the script from 
http://yuba.stanford.edu/vns/proxy_grader.py

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Updated Grading Script
Date: Tue, 16 Jan 2007 15:30:41 -0800
Lines: 8
Distribution: su
Message-ID: <eojn9j$6um$2@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168990325 7126 171.64.74.54 (16 Jan 2007 23:32:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11003

The public testing script has been revised to address a couple of bugs 
that have shown up.  Please download the latest version of the script from:

http://yuba.stanford.edu/vns/proxy_grader.py

Note that one of the URLs in the script has been changed.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 16:08:56 -0800
Lines: 112
Distribution: su
Message-ID: <eojpes$9ah$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU> <eojn4s$6um$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168992540 9553 127.0.0.1 (17 Jan 2007 00:09:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eojn4s$6um$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11004

Clay Collier wrote:
> There was a bug in the grading script that was causing it to mis-report 
> some test results.  Please download the new version of the script from 
> http://yuba.stanford.edu/vns/proxy_grader.py
> 
> Clay

For some reason I am still passing all of the tests.  When I change the 
url to some bad site (i.e. http://cat/), the grader complains.  However, 
when I set it to http://www.google.com/, I pass all of the tests. Once, 
again the script I used (newly downloaded) was:


#!/usr/bin/env python

import urllib
import sys
import os
import signal
import time
try:
      import proxy_grade_private
      use_private = True
except ImportError:
      use_private = False

# You can create additional automated tests for your proxy by
# adding URLs to this array.  This will have no effect on your
# grade, but may be helpful in testing and debugging your proxy.
pub_urls = ['http://www.google.com/', 'HTTP://www.stanford.edu/',
                'http://WWW.microsoft.com/en/us/default.aspx',
                'http://search.yahoo.com/search?p=proxy&ei=UTF-8',
                'http://yuba.stanford.edu/vns/images/su.gif']

def main():
      global pub_urls
      try:
           proxy_bin = sys.argv[1]
           port = sys.argv[2]
      except IndexError:
           usage()
           sys.exit(2)

      print 'Binary: %s' % proxy_bin
      print 'Running on port %s' % port

      # Start the proxy running in the background
      cid = os.spawnl(os.P_NOWAIT, proxy_bin, proxy_bin, port)
      # Give the proxy time to start up and start listening on the port
      time.sleep(2)
      proxy_map = {'http':'http://localhost:' + port}

      foblist = []
      for url in pub_urls:
           foblist.append(urllib.urlopen(url, None, proxy_map))

      passcount = 0
      for n in range(len(foblist)):
           proxy_file = foblist[n]
           lines = proxy_file.readlines()
           if (len(lines) == 0):
                print "No data received for " + pub_urls[n]
                continue

           direct_file = urllib.urlopen(pub_urls[n])
           direct_lines = direct_file.readlines()

           for (prox_line, dir_line) in zip(lines, direct_lines):
                if prox_line != dir_line:
                     direct_file.close()
                     continue

           direct_file.close()
           passcount += 1

      for fob in foblist:
           fob.close()

      print r'Basic HTTP transactions: %d of %d tests passed' % 
(passcount, len(pub_urls))


      if (use_private):
           priv_passed = proxy_grade_private.runall(port, cid)


      # Cleanup
      os.kill(cid, signal.SIGINT)
      os.kill(cid, signal.SIGKILL)
      os.waitpid(cid, 0)

      print 'Summary: '
      print '\t%d of %d tests passed.' % (passcount, len(pub_urls))
      score = 0
      if (use_private):
           if (priv_passed):
                print '\t100% of extended tests passed.'
                score += 1
           else:
                print'\tNot all extended tests passed.'

      score += (passcount / len(pub_urls)) * 8
      print 'Base Score: %d/10 (Remember, one point is based on style!)' 
% score

def usage():
      print "Usage: proxy_grader.py path/to/proxy/binary port"


if __name__ == '__main__':
      main()

.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 16:12:00 -0800
Lines: 120
Distribution: su
Message-ID: <eojpn1$9c1$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU> <eojn4s$6um$1@news.Stanford.EDU> <eojpes$9ah$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1168992802 9601 171.64.74.54 (17 Jan 2007 00:13:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eojpes$9ah$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11005

The version that you have attached there is the old version of the 
script- your browser may have cached the older version.  Try refreshing 
the page- the new version of the script has the revision number and the 
last change date at the top of the file.

Clay

Yuliya Sarkisyan wrote:
> Clay Collier wrote:
>> There was a bug in the grading script that was causing it to 
>> mis-report some test results.  Please download the new version of the 
>> script from http://yuba.stanford.edu/vns/proxy_grader.py
>>
>> Clay
> 
> For some reason I am still passing all of the tests.  When I change the 
> url to some bad site (i.e. http://cat/), the grader complains.  However, 
> when I set it to http://www.google.com/, I pass all of the tests. Once, 
> again the script I used (newly downloaded) was:
> 
> 
> #!/usr/bin/env python
> 
> import urllib
> import sys
> import os
> import signal
> import time
> try:
>      import proxy_grade_private
>      use_private = True
> except ImportError:
>      use_private = False
> 
> # You can create additional automated tests for your proxy by
> # adding URLs to this array.  This will have no effect on your
> # grade, but may be helpful in testing and debugging your proxy.
> pub_urls = ['http://www.google.com/', 'HTTP://www.stanford.edu/',
>                'http://WWW.microsoft.com/en/us/default.aspx',
>                'http://search.yahoo.com/search?p=proxy&ei=UTF-8',
>                'http://yuba.stanford.edu/vns/images/su.gif']
> 
> def main():
>      global pub_urls
>      try:
>           proxy_bin = sys.argv[1]
>           port = sys.argv[2]
>      except IndexError:
>           usage()
>           sys.exit(2)
> 
>      print 'Binary: %s' % proxy_bin
>      print 'Running on port %s' % port
> 
>      # Start the proxy running in the background
>      cid = os.spawnl(os.P_NOWAIT, proxy_bin, proxy_bin, port)
>      # Give the proxy time to start up and start listening on the port
>      time.sleep(2)
>      proxy_map = {'http':'http://localhost:' + port}
> 
>      foblist = []
>      for url in pub_urls:
>           foblist.append(urllib.urlopen(url, None, proxy_map))
> 
>      passcount = 0
>      for n in range(len(foblist)):
>           proxy_file = foblist[n]
>           lines = proxy_file.readlines()
>           if (len(lines) == 0):
>                print "No data received for " + pub_urls[n]
>                continue
> 
>           direct_file = urllib.urlopen(pub_urls[n])
>           direct_lines = direct_file.readlines()
> 
>           for (prox_line, dir_line) in zip(lines, direct_lines):
>                if prox_line != dir_line:
>                     direct_file.close()
>                     continue
> 
>           direct_file.close()
>           passcount += 1
> 
>      for fob in foblist:
>           fob.close()
> 
>      print r'Basic HTTP transactions: %d of %d tests passed' % 
> (passcount, len(pub_urls))
> 
> 
>      if (use_private):
>           priv_passed = proxy_grade_private.runall(port, cid)
> 
> 
>      # Cleanup
>      os.kill(cid, signal.SIGINT)
>      os.kill(cid, signal.SIGKILL)
>      os.waitpid(cid, 0)
> 
>      print 'Summary: '
>      print '\t%d of %d tests passed.' % (passcount, len(pub_urls))
>      score = 0
>      if (use_private):
>           if (priv_passed):
>                print '\t100% of extended tests passed.'
>                score += 1
>           else:
>                print'\tNot all extended tests passed.'
> 
>      score += (passcount / len(pub_urls)) * 8
>      print 'Base Score: %d/10 (Remember, one point is based on style!)' 
> % score
> 
> def usage():
>      print "Usage: proxy_grader.py path/to/proxy/binary port"
> 
> 
> if __name__ == '__main__':
>      main()
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 18:37:25 -0800
Lines: 167
Distribution: su
Message-ID: <eok259$grf$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU> <eojn4s$6um$1@news.Stanford.EDU> <eojpes$9ah$1@news.Stanford.EDU> <eojpn1$9c1$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169001449 17263 127.0.0.1 (17 Jan 2007 02:37:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eojpn1$9c1$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11006

It seems that the page at www.google.com keeps changing and is sometimes 
failing the first case of grading script.

The correct response portion of result sometimes says that the page 
should end with

Language Tools</a></font></td></tr></table></form><br><table><tr><td 
valign=center><img src="/images/hpp-cart.gif" alt="" width=40 
height=22></td><td valign=center><font size=-1>Google will <b>give you 
$10</b><br>to spend when you use <a 
href="/checkout/signupbonus_hpp.html#utm_campaign=acct10&utm_source=hpp">Google 
Checkout</a>.</font></td></tr></table><br><br><font size=-1><a 
href="/intl/en/ads/">Advertising Programs</a> - <a 
href=/services/>Business Solutions</a> - <a 
href=/intl/en/about.html>About Google</a><p><a 
href="/jobs/universities.html"><b>Graduating?  Come work with 
us.</b></a></font><p><font size=-2>©2007 
Google</font></p></center></body></html>


and sometimes that the page should end with

Language Tools</a></font></td></tr></table></form><br><br><font 
size=-1><a href="/intl/en/ads/">Advertising Programs</a> - <a 
href=/services/>Business Solutions</a> - <a 
href=/intl/en/about.html>About Google</a><p><a 
href="/jobs/universities.html"><b>Graduating?  Come work with 
us.</b></a></font><p><font size=-2>©2007 
Google</font></p></center></body></html>


The portion

<table><tr><td valign=center><img src="/images/hpp-cart.gif" alt="" 
width=40 height=22></td><td valign=center><font size=-1>Google will 
<b>give you $10</b><br>to spend when you use <a 
href="/checkout/signupbonus_hpp.html#utm_campaign=acct10&utm_source=hpp">Google 
Checkout</a>.</font></td></tr></table>

is sometimes present and sometimes not.


Could the google link be changed to some other stable website so that 
the grading script's results are consistent?


Clay Collier wrote:
> The version that you have attached there is the old version of the 
> script- your browser may have cached the older version.  Try refreshing 
> the page- the new version of the script has the revision number and the 
> last change date at the top of the file.
> 
> Clay
> 
> Yuliya Sarkisyan wrote:
>> Clay Collier wrote:
>>> There was a bug in the grading script that was causing it to 
>>> mis-report some test results.  Please download the new version of the 
>>> script from http://yuba.stanford.edu/vns/proxy_grader.py
>>>
>>> Clay
>>
>> For some reason I am still passing all of the tests.  When I change 
>> the url to some bad site (i.e. http://cat/), the grader complains.  
>> However, when I set it to http://www.google.com/, I pass all of the 
>> tests. Once, again the script I used (newly downloaded) was:
>>
>>
>> #!/usr/bin/env python
>>
>> import urllib
>> import sys
>> import os
>> import signal
>> import time
>> try:
>>      import proxy_grade_private
>>      use_private = True
>> except ImportError:
>>      use_private = False
>>
>> # You can create additional automated tests for your proxy by
>> # adding URLs to this array.  This will have no effect on your
>> # grade, but may be helpful in testing and debugging your proxy.
>> pub_urls = ['http://www.google.com/', 'HTTP://www.stanford.edu/',
>>                'http://WWW.microsoft.com/en/us/default.aspx',
>>                'http://search.yahoo.com/search?p=proxy&ei=UTF-8',
>>                'http://yuba.stanford.edu/vns/images/su.gif']
>>
>> def main():
>>      global pub_urls
>>      try:
>>           proxy_bin = sys.argv[1]
>>           port = sys.argv[2]
>>      except IndexError:
>>           usage()
>>           sys.exit(2)
>>
>>      print 'Binary: %s' % proxy_bin
>>      print 'Running on port %s' % port
>>
>>      # Start the proxy running in the background
>>      cid = os.spawnl(os.P_NOWAIT, proxy_bin, proxy_bin, port)
>>      # Give the proxy time to start up and start listening on the port
>>      time.sleep(2)
>>      proxy_map = {'http':'http://localhost:' + port}
>>
>>      foblist = []
>>      for url in pub_urls:
>>           foblist.append(urllib.urlopen(url, None, proxy_map))
>>
>>      passcount = 0
>>      for n in range(len(foblist)):
>>           proxy_file = foblist[n]
>>           lines = proxy_file.readlines()
>>           if (len(lines) == 0):
>>                print "No data received for " + pub_urls[n]
>>                continue
>>
>>           direct_file = urllib.urlopen(pub_urls[n])
>>           direct_lines = direct_file.readlines()
>>
>>           for (prox_line, dir_line) in zip(lines, direct_lines):
>>                if prox_line != dir_line:
>>                     direct_file.close()
>>                     continue
>>
>>           direct_file.close()
>>           passcount += 1
>>
>>      for fob in foblist:
>>           fob.close()
>>
>>      print r'Basic HTTP transactions: %d of %d tests passed' % 
>> (passcount, len(pub_urls))
>>
>>
>>      if (use_private):
>>           priv_passed = proxy_grade_private.runall(port, cid)
>>
>>
>>      # Cleanup
>>      os.kill(cid, signal.SIGINT)
>>      os.kill(cid, signal.SIGKILL)
>>      os.waitpid(cid, 0)
>>
>>      print 'Summary: '
>>      print '\t%d of %d tests passed.' % (passcount, len(pub_urls))
>>      score = 0
>>      if (use_private):
>>           if (priv_passed):
>>                print '\t100% of extended tests passed.'
>>                score += 1
>>           else:
>>                print'\tNot all extended tests passed.'
>>
>>      score += (passcount / len(pub_urls)) * 8
>>      print 'Base Score: %d/10 (Remember, one point is based on 
>> style!)' % score
>>
>> def usage():
>>      print "Usage: proxy_grader.py path/to/proxy/binary port"
>>
>>
>> if __name__ == '__main__':
>>      main()
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 18:52:02 -0800
Lines: 8
Distribution: su
Message-ID: <eok2v5$hgv$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU> <eojn4s$6um$1@news.Stanford.EDU> <eojpes$9ah$1@news.Stanford.EDU> <eojpn1$9c1$1@news.Stanford.EDU> <eok259$grf$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169002277 17951 127.0.0.1 (17 Jan 2007 02:51:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <eok259$grf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11007

I just discovered this as well.  Spent about five minutes of pulling my 
hair out since the script would report 5 of 5 and one second later would 
report 4 of 5 without any changes to my proxy.

Hopefully the TAs will be aware of this little promotion Google seems to 
be showing for random page views.

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script
Date: Tue, 16 Jan 2007 19:29:08 -0800
Lines: 6
Distribution: su
Message-ID: <eok58n$j7b$1@news.Stanford.EDU>
References: <eoj7in$go8$1@news.Stanford.EDU> <eojn4s$6um$1@news.Stanford.EDU> <eojpes$9ah$1@news.Stanford.EDU> <eojpn1$9c1$1@news.Stanford.EDU> <eok259$grf$1@news.Stanford.EDU> <eok2v5$hgv$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169004631 19691 171.64.74.54 (17 Jan 2007 03:30:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eok2v5$hgv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11008

Yes, Google is apparently having a bit of fun with their front page. 
Thanks for bringing this to our attention.  For the time being, try 
changing the Google URL to http://labs.google.com/.  I'll post a 
revision to the grading script as well.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 22:27:10 -0800
Lines: 18
Distribution: su
Message-ID: <eokfjt$rgu$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169015229 28190 128.12.194.72 (17 Jan 2007 06:27:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eojn9j$6um$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11009

Clay Collier wrote:
> The public testing script has been revised to address a couple of bugs 
> that have shown up.  Please download the latest version of the script from:
> 
> http://yuba.stanford.edu/vns/proxy_grader.py
> 
> Note that one of the URLs in the script has been changed.
> 
> Clay

Hi Clay,

has this script been tested on GET HTTP://www.stanford.edu/ HTTP/1.0?

It works just fine with my proxy if I type it in manually, but the 
auto-grader is choking on this test for some reason.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 22:53:10 -0800
Lines: 29
Distribution: su
Message-ID: <eokh7b$skp$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU> <eokfjt$rgu$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169016875 29337 171.64.74.54 (17 Jan 2007 06:54:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eokfjt$rgu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11010

All the URLs in the script should work correctly.  Are you just failing 
the test, or is the script actually exiting with an error?  If it's the 
former, take a look at what the script is actually sending to your proxy 
(try printing the actual request as the proxy sees it), and the data 
that you are sending back.  If it's the latter, please send along 
whatever error you're seeing.

Clay

Yangfan Wang wrote:
> Clay Collier wrote:
>> The public testing script has been revised to address a couple of bugs 
>> that have shown up.  Please download the latest version of the script 
>> from:
>>
>> http://yuba.stanford.edu/vns/proxy_grader.py
>>
>> Note that one of the URLs in the script has been changed.
>>
>> Clay
> 
> Hi Clay,
> 
> has this script been tested on GET HTTP://www.stanford.edu/ HTTP/1.0?
> 
> It works just fine with my proxy if I type it in manually, but the 
> auto-grader is choking on this test for some reason.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 23:15:23 -0800
Lines: 52
Distribution: su
Message-ID: <eokie9$cn$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU> <eokfjt$rgu$1@news.Stanford.EDU> <eokh7b$skp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169018121 407 128.12.194.72 (17 Jan 2007 07:15:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eokh7b$skp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11011

Huh. It doesn't crash anymore. It must have been my bug.

I'm still failing the test though. My proxy is getting the right 
response message back from stanford.edu, and forwarded the header 
correctly. Stanford doesn't specify message body length, so I had to get 
creative. However, I believe I'm sending the body back correctly as well:

 >>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<<< <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

I'm actually sending back the entire HTML page rather than just the 
first line. I'm not sure why the grader is only printing the first line 
when it should expect the entire page.

-Yangfan

Clay Collier wrote:
> All the URLs in the script should work correctly.  Are you just failing 
> the test, or is the script actually exiting with an error?  If it's the 
> former, take a look at what the script is actually sending to your proxy 
> (try printing the actual request as the proxy sees it), and the data 
> that you are sending back.  If it's the latter, please send along 
> whatever error you're seeing.
> 
> Clay
> 
> Yangfan Wang wrote:
> 
>> Clay Collier wrote:
>>
>>> The public testing script has been revised to address a couple of 
>>> bugs that have shown up.  Please download the latest version of the 
>>> script from:
>>>
>>> http://yuba.stanford.edu/vns/proxy_grader.py
>>>
>>> Note that one of the URLs in the script has been changed.
>>>
>>> Clay
>>
>>
>> Hi Clay,
>>
>> has this script been tested on GET HTTP://www.stanford.edu/ HTTP/1.0?
>>
>> It works just fine with my proxy if I type it in manually, but the 
>> auto-grader is choking on this test for some reason.
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 23:22:32 -0800
Lines: 19
Distribution: su
Message-ID: <eokirp$pt$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169018554 829 127.0.0.1 (17 Jan 2007 07:22:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11012

Is this the latest version?

#$Rev: 1265 $
#$LastChangedDate: 2007-01-16 19:30:08 -0800 (Tue, 16 Jan 2007) $


"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eojn9j$6um$2@news.Stanford.EDU...
> The public testing script has been revised to address a couple of bugs 
> that have shown up.  Please download the latest version of the script 
> from:
>
> http://yuba.stanford.edu/vns/proxy_grader.py
>
> Note that one of the URLs in the script has been changed.
>
> Clay 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 23:25:02 -0800
Lines: 38
Distribution: su
Message-ID: <eokj0d$th$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU> <eokfjt$rgu$1@news.Stanford.EDU> <eokh7b$skp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169018701 945 128.12.194.72 (17 Jan 2007 07:25:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eokh7b$skp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11013

Never mind. I just had to improve my algorithm. The autograder is very 
delicate. :p

-Yangfan

Clay Collier wrote:
> All the URLs in the script should work correctly.  Are you just failing 
> the test, or is the script actually exiting with an error?  If it's the 
> former, take a look at what the script is actually sending to your proxy 
> (try printing the actual request as the proxy sees it), and the data 
> that you are sending back.  If it's the latter, please send along 
> whatever error you're seeing.
> 
> Clay
> 
> Yangfan Wang wrote:
> 
>> Clay Collier wrote:
>>
>>> The public testing script has been revised to address a couple of 
>>> bugs that have shown up.  Please download the latest version of the 
>>> script from:
>>>
>>> http://yuba.stanford.edu/vns/proxy_grader.py
>>>
>>> Note that one of the URLs in the script has been changed.
>>>
>>> Clay
>>
>>
>> Hi Clay,
>>
>> has this script been tested on GET HTTP://www.stanford.edu/ HTTP/1.0?
>>
>> It works just fine with my proxy if I type it in manually, but the 
>> auto-grader is choking on this test for some reason.
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: running on cluster
Date: Tue, 16 Jan 2007 23:36:55 -0800
Lines: 29
Distribution: su
Message-ID: <eokjju$1jq$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169019327 1658 128.12.134.140 (17 Jan 2007 07:35:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11014

Hi,

My proxy works fine when I compile and run it on my Linux machine at
home. But when I move the source code and the makefile, and compile it
on the cluster machines (myth or vine), the proxy_grader script fails.
The error is a weird error:

Running on port 1344
Connecting to 216.239.53.132
Error connecting to address: Socket operation on non-socket
Connecting to 171.67.22.33
Error connecting to address: Socket operation on non-socket
Connecting to 207.46.199.60
Error connecting to address: Bad file descriptor
Connecting to 207.46.225.60
Error connecting to address: Bad file descriptor
Connecting to 207.46.18.30
Error connecting to address: Bad file descriptor
....

sometimes i also get:
Error connecting to address: Transport endpoint is already connected

The phrases after the colon are the outputs of perror.
Has anybody run into something similar? Why would the it run perfectly
at the Linux machine at home and not on the cluster?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Updated Grading Script
Date: Tue, 16 Jan 2007 23:45:29 -0800
Lines: 23
Distribution: su
Message-ID: <eokk9f$22i$1@news.Stanford.EDU>
References: <eojn9j$6um$2@news.Stanford.EDU> <eokirp$pt$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169020016 2130 171.64.74.54 (17 Jan 2007 07:46:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eokirp$pt$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11015

Yes, Revision 1265 is the latest version.

Clay
Riju Kallivalappil wrote:
> Is this the latest version?
> 
> #$Rev: 1265 $
> #$LastChangedDate: 2007-01-16 19:30:08 -0800 (Tue, 16 Jan 2007) $
> 
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eojn9j$6um$2@news.Stanford.EDU...
>> The public testing script has been revised to address a couple of bugs 
>> that have shown up.  Please download the latest version of the script 
>> from:
>>
>> http://yuba.stanford.edu/vns/proxy_grader.py
>>
>> Note that one of the URLs in the script has been changed.
>>
>> Clay 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running on cluster
Date: Tue, 16 Jan 2007 23:53:32 -0800
Lines: 44
Distribution: su
Message-ID: <eokkoh$4rl$1@news.Stanford.EDU>
References: <eokjju$1jq$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169020499 4981 171.64.74.54 (17 Jan 2007 07:54:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eokjju$1jq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11016

The 'socket operation on a non-socket' and 'bad file descriptor' 
messages both seem to indicate that you're passing either a socket that 
hasn't been established correctly, or an integer that isn't really a 
socket descriptor to a socket function.

Make sure you're checking the return values from socket(), accept(), and 
connect() and that you're using the htons/l() functions appropriately. 
Also, take a look with gdb or printf and see what actual integer you're 
passing as a file/socket descriptor to the function that is raising the 
error, and make sure that it's a legal value that you're getting back 
from accept() or socket().

Clay

Jad Naous wrote:
> Hi,
> 
> My proxy works fine when I compile and run it on my Linux machine at
> home. But when I move the source code and the makefile, and compile it
> on the cluster machines (myth or vine), the proxy_grader script fails.
> The error is a weird error:
> 
> Running on port 1344
> Connecting to 216.239.53.132
> Error connecting to address: Socket operation on non-socket
> Connecting to 171.67.22.33
> Error connecting to address: Socket operation on non-socket
> Connecting to 207.46.199.60
> Error connecting to address: Bad file descriptor
> Connecting to 207.46.225.60
> Error connecting to address: Bad file descriptor
> Connecting to 207.46.18.30
> Error connecting to address: Bad file descriptor
> ...
> 
> sometimes i also get:
> Error connecting to address: Transport endpoint is already connected
> 
> The phrases after the colon are the outputs of perror.
> Has anybody run into something similar? Why would the it run perfectly
> at the Linux machine at home and not on the cluster?
> 
> Thanks,
> Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Matt Page" <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 02:24:01 -0800
Lines: 18
Distribution: su
Message-ID: <eoktg5$dlm$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
X-Trace: news.Stanford.EDU 1169029445 14006 128.12.104.45 (17 Jan 2007 10:24:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11017

Hey All,

I have 2 questions:

1) Are we required to parse/validate the responses
returned from the remote webserver? If so, how should we
proceed if they return a malformed response?

2) I'm having some serious weirdness when testing using Yahoo.
I can forward the request perfectly fine but read/recv blocks
infinitely when I try and get the response. I'm positive the response
is being sent as I can see it go over the wire using ethereal.
Any ideas?

Thanks,
Matt 


.

Path: shelby.stanford.edu!not-for-mail
From: "Madeleine Lam" <mlamone@cisco.com>
Newsgroups: su.class.cs244a
Subject: www.cnn.com
Date: Wed, 17 Jan 2007 03:09:36 -0800
Lines: 28
Distribution: su
Message-ID: <eol05i$g9o$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169032178 16696 127.0.0.1 (17 Jan 2007 11:09:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4968.1600
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4971.600
Xref: shelby.stanford.edu su.class.cs244a:11018

Hi,

What is the tricky reason of using www.cnn.com?

I am getting:

proxy: >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html
lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather,
Entertainment & Video News</title>     <meta http-equiv="content-type"
content="text/html; charset=iso-8859-1">


I tried manually
telnet www.cnn.com 80
GET / HTTP/1.0
and still got "-//W3C//DTD HTML 4.01 Transitional//EN"

Also tried manually run my code using "GET http://www.cnn.com HTTP/1.0" and
still got the same W3C output

Does the grading script expect "-//IETF//DTD HTML 2.0//EN" ?


Thanks.


.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 03:30:25 -0800
Lines: 20
Distribution: su
Message-ID: <eol1cr$hbb$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1169033435 17771 171.64.75.59 (17 Jan 2007 11:30:35 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11019


Hi,

I was running proxy_grader.py and noticed that it was sending
the following request to my proxy:

GET / HTTP/1.0
Host: labs.google.com
User-agent: Python-urllib/1.16

The Host: header was unfamiliar - I couldn't find it in the RFC.
In fact, "HTTP Made Really Easy" says that the Host: header is a HTTP/1.1 
feature.

Should I nontheless support this header?

-Steven



.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 10:38:25 -0800
Lines: 22
Distribution: su
Message-ID: <eolqen$aql$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169059095 11093 127.0.0.1 (17 Jan 2007 18:38:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoktg5$dlm$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11020

Matt Page wrote:
> Hey All,
> 
> I have 2 questions:
> 
> 1) Are we required to parse/validate the responses
> returned from the remote webserver? If so, how should we
> proceed if they return a malformed response?

No just shuttle it directly from the remote server to the client.

> 
> 2) I'm having some serious weirdness when testing using Yahoo.
> I can forward the request perfectly fine but read/recv blocks
> infinitely when I try and get the response. I'm positive the response
> is being sent as I can see it go over the wire using ethereal.
> Any ideas?

Make sure if you are calling recv and it returns 0 that means the 
connection has been closed..

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: www.cnn.com
Date: Wed, 17 Jan 2007 10:39:29 -0800
Lines: 32
Distribution: su
Message-ID: <eolqgn$aql$2@news.Stanford.EDU>
References: <eol05i$g9o$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169059159 11093 127.0.0.1 (17 Jan 2007 18:39:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eol05i$g9o$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11021

Madeleine Lam wrote:
> Hi,
> 
> What is the tricky reason of using www.cnn.com?
> 
> I am getting:
> 
> proxy: >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> 
> <<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html
> lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather,
> Entertainment & Video News</title>     <meta http-equiv="content-type"
> content="text/html; charset=iso-8859-1">
> 
> 
> I tried manually
> telnet www.cnn.com 80
> GET / HTTP/1.0
> and still got "-//W3C//DTD HTML 4.01 Transitional//EN"
> 
> Also tried manually run my code using "GET http://www.cnn.com HTTP/1.0" and
> still got the same W3C output
> 
> Does the grading script expect "-//IETF//DTD HTML 2.0//EN" ?
> 
> 
> Thanks.

Whatever the remote server sends you just forward that to the client and 
dont worry about it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Lin Kuang" <lkuang@cisco.com>
Newsgroups: su.class.cs244a
Subject: peer is a server or another proxy
Date: Wed, 17 Jan 2007 10:53:07 -0800
Lines: 9
Distribution: su
Message-ID: <eolrak$blk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169059988 11956 127.0.0.1 (17 Jan 2007 18:53:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Xref: shelby.stanford.edu su.class.cs244a:11022

Hi TAs,

Something come up in my mind and I'd like to get an clarification. For this
assignment, do we need to handle both the cases  when the "server" is a real
server and when it is another proxy? Thank you for your input.

Lin


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: peer is a server or another proxy
Date: Wed, 17 Jan 2007 10:54:23 -0800
Lines: 12
Distribution: su
Message-ID: <eolrcl$bmc$1@news.Stanford.EDU>
References: <eolrak$blk$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169060053 11980 127.0.0.1 (17 Jan 2007 18:54:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eolrak$blk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11023

Lin Kuang wrote:
> Hi TAs,
> 
> Something come up in my mind and I'd like to get an clarification. For this
> assignment, do we need to handle both the cases  when the "server" is a real
> server and when it is another proxy? Thank you for your input.
> 
> Lin

No, you assume the other end is the actual web server.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 10:55:46 -0800
Lines: 18
Distribution: su
Message-ID: <eolrf8$bmc$2@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169060136 11980 127.0.0.1 (17 Jan 2007 18:55:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eol1cr$hbb$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11024

Euijong Whang wrote:
> Hi,
> 
> I was running proxy_grader.py and noticed that it was sending
> the following request to my proxy:
> 
> GET / HTTP/1.0
> Host: labs.google.com
> User-agent: Python-urllib/1.16
> 
> The Host: header was unfamiliar - I couldn't find it in the RFC.
> In fact, "HTTP Made Really Easy" says that the Host: header is a HTTP/1.1 
> feature.

So what does that tell you about this request?

-David

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 11:11:09 -0800
Lines: 14
Distribution: su
Message-ID: <eolscf$co2$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU> <eolqen$aql$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169061071 13058 127.0.0.1 (17 Jan 2007 19:11:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11025

>> I have 2 questions:
>>
>> 1) Are we required to parse/validate the responses
>> returned from the remote webserver? If so, how should we
>> proceed if they return a malformed response?
>
> No just shuttle it directly from the remote server to the client.
>

But, wouldn't this break one of the fundamental guidelines for this 
assignment, viz., "be lenient about what you accept, but strict about what 
you send"? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: implications of grading script (or in quest of the correct HTTP version)
Date: Wed, 17 Jan 2007 11:12:42 -0800
Lines: 24
Distribution: su
Message-ID: <eolse2$cqc$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169061122 13132 127.0.0.1 (17 Jan 2007 19:12:02 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11026

I was just thinking about how the public grading script is implemented.

Currently, it does a comparison with what is returned from the webpage.  If 
we do not return exactly what those web pages do, we do not pass the test.

However, this seems to conflict with our mandate to clean up whatever passes 
back.  We could write our own test that checks for a cleaned up response. 
However, that seems, not just like extra work, but the test code would be at 
least as buggy as our actual code.

It seems that, to be safe, we should not modify anything returned from the 
web server.

Another note, I do not see how the response should be exactly the same, 
because I see nothing in the python code that sets the HTTP version to 1.0. 
Is direct_file = urllib.urlopen(pub_urls[n] set up for HTTP/1.0?  I have not 
checked it myself yet.

Just some thoughts.

Sincerely,
Randy Jennings 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 11:16:24 -0800
Lines: 31
Distribution: su
Message-ID: <eolskv$d0r$1@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169061343 13339 127.0.0.1 (17 Jan 2007 19:15:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11027

The request is originally HTTP/1.1 or buggy of course.

The web page says we are supposed to be able to support HTTP/1.0.  Are you 
saying we need to support converting HTTP/1.1 to HTTP/1.0?  That does not 
seem to be what is specified on the assignment.

Sincerely,
Randy Jennings

"David Erickson" <derickso@stanford.edu> wrote in message 
news:eolrf8$bmc$2@news.Stanford.EDU...
> Euijong Whang wrote:
>> Hi,
>>
>> I was running proxy_grader.py and noticed that it was sending
>> the following request to my proxy:
>>
>> GET / HTTP/1.0
>> Host: labs.google.com
>> User-agent: Python-urllib/1.16
>>
>> The Host: header was unfamiliar - I couldn't find it in the RFC.
>> In fact, "HTTP Made Really Easy" says that the Host: header is a HTTP/1.1 
>> feature.
>
> So what does that tell you about this request?
>
> -David
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 11:15:55 -0800
Lines: 17
Distribution: su
Message-ID: <eolsl1$ctk$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU> <eolqen$aql$1@news.Stanford.EDU> <eolscf$co2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169061345 13236 127.0.0.1 (17 Jan 2007 19:15:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eolscf$co2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11028

Riju Kallivalappil wrote:
>>> I have 2 questions:
>>>
>>> 1) Are we required to parse/validate the responses
>>> returned from the remote webserver? If so, how should we
>>> proceed if they return a malformed response?
>> No just shuttle it directly from the remote server to the client.
>>
> 
> But, wouldn't this break one of the fundamental guidelines for this 
> assignment, viz., "be lenient about what you accept, but strict about what 
> you send"? 

As far as I am aware this comment is in relation to what you accept from 
the client and the request you send to the remote server.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 11:17:56 -0800
Lines: 28
Distribution: su
Message-ID: <eolsnr$d2o$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU> <eolqen$aql$1@news.Stanford.EDU> <eolscf$co2$1@news.Stanford.EDU> <eolsl1$ctk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169061435 13400 127.0.0.1 (17 Jan 2007 19:17:15 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11029

That is not what was said in the help session.  However, that seems to be 
the only realistic conclusion.

Sincerely,
Randy Jennings

The squirrels are your friends!
"David Erickson" <derickso@stanford.edu> wrote in message 
news:eolsl1$ctk$1@news.Stanford.EDU...
> Riju Kallivalappil wrote:
>>>> I have 2 questions:
>>>>
>>>> 1) Are we required to parse/validate the responses
>>>> returned from the remote webserver? If so, how should we
>>>> proceed if they return a malformed response?
>>> No just shuttle it directly from the remote server to the client.
>>>
>>
>> But, wouldn't this break one of the fundamental guidelines for this 
>> assignment, viz., "be lenient about what you accept, but strict about 
>> what you send"?
>
> As far as I am aware this comment is in relation to what you accept from 
> the client and the request you send to the remote server.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 11:18:50 -0800
Lines: 34
Distribution: su
Message-ID: <eolsqg$ctk$2@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169061520 13236 127.0.0.1 (17 Jan 2007 19:18:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eolskv$d0r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11030

Randy Jennings wrote:
> The request is originally HTTP/1.1 or buggy of course.
> 
> The web page says we are supposed to be able to support HTTP/1.0.  Are you 
> saying we need to support converting HTTP/1.1 to HTTP/1.0?  That does not 
> seem to be what is specified on the assignment.
> 
> Sincerely,
> Randy Jennings
> 
> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:eolrf8$bmc$2@news.Stanford.EDU...
>> Euijong Whang wrote:
>>> Hi,
>>>
>>> I was running proxy_grader.py and noticed that it was sending
>>> the following request to my proxy:
>>>
>>> GET / HTTP/1.0
>>> Host: labs.google.com
>>> User-agent: Python-urllib/1.16
>>>
>>> The Host: header was unfamiliar - I couldn't find it in the RFC.
>>> In fact, "HTTP Made Really Easy" says that the Host: header is a HTTP/1.1 
>>> feature.
>> So what does that tell you about this request?
>>
>> -David
>>

No I am definitely not saying that, if the incoming request is missing 
invalid (according to the spec you are implementing), then what do you do?

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: www.cnn.com
Date: Wed, 17 Jan 2007 11:24:08 -0800
Lines: 52
Distribution: su
Message-ID: <eolt4j$dh1$1@news.Stanford.EDU>
References: <eol05i$g9o$1@news.Stanford.EDU> <eolqgn$aql$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169061843 13857 128.12.194.72 (17 Jan 2007 19:24:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eolqgn$aql$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11031

David Erickson wrote:
> Madeleine Lam wrote:
> 
>> Hi,
>>
>> What is the tricky reason of using www.cnn.com?
>>
>> I am getting:
>>
>> proxy: >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>
>> <<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html
>> lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather,
>> Entertainment & Video News</title>     <meta 
>> http-equiv="content-type"
>> content="text/html; charset=iso-8859-1">
>>
>>
>> I tried manually
>> telnet www.cnn.com 80
>> GET / HTTP/1.0
>> and still got "-//W3C//DTD HTML 4.01 Transitional//EN"
>>
>> Also tried manually run my code using "GET http://www.cnn.com 
>> HTTP/1.0" and
>> still got the same W3C output
>>
>> Does the grading script expect "-//IETF//DTD HTML 2.0//EN" ?
>>
>>
>> Thanks.
> 
> 
> Whatever the remote server sends you just forward that to the client and 
> dont worry about it.
> 
> -David

David,

the cnn.com website is changing dynamically. I believe sometimes it 
would confuse the grader since the returned HTML page would be different 
when the proxy fetches it and when the grader itself fetches it.

So I would get 4 out of 5 and then 5 out of 5 one second later. :(

This might be true for other "portal" websites as well, obviously.

One way around this would be to run the auto-grader 2 or 3 times for 
each student.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 11:26:24 -0800
Lines: 43
Distribution: su
Message-ID: <eolt94$dk1$1@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169061989 13953 127.0.0.1 (17 Jan 2007 19:26:29 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11032

This is what RFC 1945 say about headers that are unknown. In HTTP/1.0 "Host" 
is an unknown header.

Section 5.2
"Unrecognized header fields are treated as  Entity-Header fields."

-riju

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:eolskv$d0r$1@news.Stanford.EDU...
> The request is originally HTTP/1.1 or buggy of course.
>
> The web page says we are supposed to be able to support HTTP/1.0.  Are you 
> saying we need to support converting HTTP/1.1 to HTTP/1.0?  That does not 
> seem to be what is specified on the assignment.
>
> Sincerely,
> Randy Jennings
>
> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:eolrf8$bmc$2@news.Stanford.EDU...
>> Euijong Whang wrote:
>>> Hi,
>>>
>>> I was running proxy_grader.py and noticed that it was sending
>>> the following request to my proxy:
>>>
>>> GET / HTTP/1.0
>>> Host: labs.google.com
>>> User-agent: Python-urllib/1.16
>>>
>>> The Host: header was unfamiliar - I couldn't find it in the RFC.
>>> In fact, "HTTP Made Really Easy" says that the Host: header is a 
>>> HTTP/1.1 feature.
>>
>> So what does that tell you about this request?
>>
>> -David
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Lin Kuang" <lkuang@cisco.com>
Newsgroups: su.class.cs244a
Subject: checking the syntax of the Header in client request
Date: Wed, 17 Jan 2007 11:32:11 -0800
Lines: 10
Distribution: su
Message-ID: <eoltjs$e13$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169062332 14371 127.0.0.1 (17 Jan 2007 19:32:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Xref: shelby.stanford.edu su.class.cs244a:11033

Hi TA,

Something I am not sure about and hope you can shed some lights. Do our
proxies need to check the syntax for the Header (General-Header, or
Request-Header, etc) also in the client request, or we can assume the Header
is always of the right format? Thank you for your input.

Lin


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 11:39:03 -0800
Lines: 16
Distribution: su
Message-ID: <eoltvf$eap$1@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU> <eolsqg$ctk$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169062703 14681 127.0.0.1 (17 Jan 2007 19:38:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11034

> No I am definitely not saying that, if the incoming request is missing 
> invalid (according to the spec you are implementing), then what do you do?

I think something got lost between 'missing' and 'invalid', but I think you 
are (now) saying that Host: (while not making the request invalid (according 
to rfc1945, see other post by Riju)) does not compensate for not having the 
full url in the request line (invalid according to our project spec). 
However, that refers back to my previous (in time) post on implications of 
the grading script.

How is python being set to use HTTP/1.0 instead of HTTP/1.1?

Sincerely,
Randy Jennings


.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Checking end of optional message body
Date: Wed, 17 Jan 2007 11:58:20 -0800
Lines: 21
Distribution: su
Message-ID: <Pine.LNX.4.62.0701171148320.24170@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169063902 15827 171.64.66.201 (17 Jan 2007 19:58:22 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11035

Hi, I am curious about reading a client's response, how do we know whether 
it contains an optional message body or how long that message body is? 
Suppose a request is something like:

GET http://www.google.com HTTP/1.0<CR><LF>
<CR><LF>
<optional message body>

How do we know after the second <CR><LF> up there that there is still 
optional message body coming. In getting a response case, because once a 
response is sent from the server, the server closes the socket connection, 
so I can read all bytes until the socket is closed. But in getting the 
client's request case, how do I know it's the end of the request message 
because the socket keeps opened?

In a "telnet www.yahoo.com 80", we could just type "GET ......." and then 
hit "enter" twice and we will get a response, I believe in this case, the 
server sends back a response to us once two <CR><LF> is received, how does 
it know that we don't have "an optional message body"?

Thanks in advance for any clarification or errors I might have mentioned.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: checking the syntax of the Header in client request
Date: Wed, 17 Jan 2007 12:11:13 -0800
Lines: 15
Distribution: su
Message-ID: <45AE82E1.70803@stanford.edu>
References: <eoltjs$e13$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169064663 16480 127.0.0.1 (17 Jan 2007 20:11:03 GMT)
X-Complaints-To: news@news.stanford.edu
To: Lin Kuang <lkuang@cisco.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoltjs$e13$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11036

Lin Kuang wrote:
> Hi TA,
> 
> Something I am not sure about and hope you can shed some lights. Do our
> proxies need to check the syntax for the Header (General-Header, or
> Request-Header, etc) also in the client request, or we can assume the Header
> is always of the right format? Thank you for your input.
> 
> Lin
> 
> 

You most definitely cannot assume the header is always in the right format.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 12:12:52 -0800
Lines: 18
Distribution: su
Message-ID: <45AE8344.80907@stanford.edu>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU> <eolsqg$ctk$2@news.Stanford.EDU> <eoltvf$eap$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169064762 16480 127.0.0.1 (17 Jan 2007 20:12:42 GMT)
X-Complaints-To: news@news.stanford.edu
To: Randy Jennings <randyj@stanford.edu>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eoltvf$eap$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11037

Randy Jennings wrote:
>> No I am definitely not saying that, if the incoming request is missing 
>> invalid (according to the spec you are implementing), then what do you do?
> 
> I think something got lost between 'missing' and 'invalid', but I think you 
> are (now) saying that Host: (while not making the request invalid (according 
> to rfc1945, see other post by Riju)) does not compensate for not having the 
> full url in the request line (invalid according to our project spec). 
> However, that refers back to my previous (in time) post on implications of 
> the grading script.
> 
> How is python being set to use HTTP/1.0 instead of HTTP/1.1?
> 

I'm not positive which version python is sending requests as, but it 
does not appear to effect the response.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking end of optional message body
Date: Wed, 17 Jan 2007 12:25:29 -0800
Lines: 26
Distribution: su
Message-ID: <eom0nf$h4e$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701171148320.24170@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169065519 17550 127.0.0.1 (17 Jan 2007 20:25:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.62.0701171148320.24170@xenon.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11038

Ryan Chen wrote:
> Hi, I am curious about reading a client's response, how do we know 
> whether it contains an optional message body or how long that message 
> body is? Suppose a request is something like:
> 
> GET http://www.google.com HTTP/1.0<CR><LF>
> <CR><LF>
> <optional message body>
> 
> How do we know after the second <CR><LF> up there that there is still 
> optional message body coming. In getting a response case, because once a 
> response is sent from the server, the server closes the socket 
> connection, so I can read all bytes until the socket is closed. But in 
> getting the client's request case, how do I know it's the end of the 
> request message because the socket keeps opened?
> 
> In a "telnet www.yahoo.com 80", we could just type "GET ......." and 
> then hit "enter" twice and we will get a response, I believe in this 
> case, the server sends back a response to us once two <CR><LF> is 
> received, how does it know that we don't have "an optional message body"?
> 
> Thanks in advance for any clarification or errors I might have mentioned.

See section 7.2 of the RFC.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running on cluster
Date: Wed, 17 Jan 2007 12:32:16 -0800
Lines: 50
Distribution: su
Message-ID: <eom11m$h8j$1@news.Stanford.EDU>
References: <eokjju$1jq$1@news.Stanford.EDU> <eokkoh$4rl$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169065846 17683 128.12.134.140 (17 Jan 2007 20:30:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <eokkoh$4rl$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11039

Thanks,
it actually turned out that when copying the address using memcpy, I was
using the wrong length.
Jad.

Clay Collier wrote:
> The 'socket operation on a non-socket' and 'bad file descriptor'
> messages both seem to indicate that you're passing either a socket that
> hasn't been established correctly, or an integer that isn't really a
> socket descriptor to a socket function.
> 
> Make sure you're checking the return values from socket(), accept(), and
> connect() and that you're using the htons/l() functions appropriately.
> Also, take a look with gdb or printf and see what actual integer you're
> passing as a file/socket descriptor to the function that is raising the
> error, and make sure that it's a legal value that you're getting back
> from accept() or socket().
> 
> Clay
> 
> Jad Naous wrote:
>> Hi,
>>
>> My proxy works fine when I compile and run it on my Linux machine at
>> home. But when I move the source code and the makefile, and compile it
>> on the cluster machines (myth or vine), the proxy_grader script fails.
>> The error is a weird error:
>>
>> Running on port 1344
>> Connecting to 216.239.53.132
>> Error connecting to address: Socket operation on non-socket
>> Connecting to 171.67.22.33
>> Error connecting to address: Socket operation on non-socket
>> Connecting to 207.46.199.60
>> Error connecting to address: Bad file descriptor
>> Connecting to 207.46.225.60
>> Error connecting to address: Bad file descriptor
>> Connecting to 207.46.18.30
>> Error connecting to address: Bad file descriptor
>> ...
>>
>> sometimes i also get:
>> Error connecting to address: Transport endpoint is already connected
>>
>> The phrases after the colon are the outputs of perror.
>> Has anybody run into something similar? Why would the it run perfectly
>> at the Linux machine at home and not on the cluster?
>>
>> Thanks,
>> Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Lin Kuang" <lkuang@cisco.com>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 13:30:00 -0800
Lines: 35
Distribution: su
Message-ID: <eom4h2$l9f$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU> <eolqen$aql$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169069410 21807 127.0.0.1 (17 Jan 2007 21:30:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Xref: shelby.stanford.edu su.class.cs244a:11040

I thought that if the server is using a version higher than 1.0, the proxy
will need to return an error code to the client instead of forwarding the
respond...in this case, the proxy will need to parse the responds from the
server to check the verion....no?

so all the parse and validation is for request from client only?

--Lin

"David Erickson" <derickso@stanford.edu> wrote in message
news:eolqen$aql$1@news.Stanford.EDU...
> Matt Page wrote:
> > Hey All,
> >
> > I have 2 questions:
> >
> > 1) Are we required to parse/validate the responses
> > returned from the remote webserver? If so, how should we
> > proceed if they return a malformed response?
>
> No just shuttle it directly from the remote server to the client.
>
> >
> > 2) I'm having some serious weirdness when testing using Yahoo.
> > I can forward the request perfectly fine but read/recv blocks
> > infinitely when I try and get the response. I'm positive the response
> > is being sent as I can see it go over the wire using ethereal.
> > Any ideas?
>
> Make sure if you are calling recv and it returns 0 that means the
> connection has been closed..
>
> -David


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Client resetting connection to proxy
Date: Wed, 17 Jan 2007 14:48:27 -0700
Lines: 8
Distribution: su
Message-ID: <eom5jc$m6q$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169070508 22746 127.0.0.1 (17 Jan 2007 21:48:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11041

When my proxy is writing requested data to the client, sometimes it appears 
the client is resetting the connection before the proxy has sent all the 
data.  (The write call produces "Connection reset by peer.")  This only 
happens when sending data from certain Web sites, but they are mainstream 
sites.  Any ideas on what would cause the client to reset its connection 
with the proxy?


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking server responses/Yahoo weirdness
Date: Wed, 17 Jan 2007 14:01:12 -0800
Lines: 16
Distribution: su
Message-ID: <eom6ap$mma$1@news.Stanford.EDU>
References: <eoktg5$dlm$1@news.Stanford.EDU> <eolqen$aql$1@news.Stanford.EDU> <eom4h2$l9f$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169071257 23242 127.0.0.1 (17 Jan 2007 22:00:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eom4h2$l9f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11042

Lin Kuang wrote:
> I thought that if the server is using a version higher than 1.0, the proxy
> will need to return an error code to the client instead of forwarding the
> respond...in this case, the proxy will need to parse the responds from the
> server to check the verion....no?
> 
> so all the parse and validation is for request from client only?
> 
> --Lin

I did an informal survey of the public proxy scripts websites it queries 
and they all return a 1.1 response even though you send yours as 1.0, so 
  to answer your question, dont bother parsing the reply, just forward 
it directly on to the client.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Client resetting connection to proxy
Date: Wed, 17 Jan 2007 14:03:23 -0800
Lines: 14
Distribution: su
Message-ID: <eom6es$mma$2@news.Stanford.EDU>
References: <eom5jc$m6q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169071389 23242 127.0.0.1 (17 Jan 2007 22:03:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eom5jc$m6q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11043

Kevin Hart wrote:
> When my proxy is writing requested data to the client, sometimes it appears 
> the client is resetting the connection before the proxy has sent all the 
> data.  (The write call produces "Connection reset by peer.")  This only 
> happens when sending data from certain Web sites, but they are mainstream 
> sites.  Any ideas on what would cause the client to reset its connection 
> with the proxy?
> 
> 
Generally clients will read until they reach the size of the 
Content-Length header in the reply then close the connection, so make 
sure you don't have an error in your code causing you to write extra data.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: gif files
Date: Wed, 17 Jan 2007 23:01:09 +0000 (UTC)
Lines: 9
Distribution: su
Message-ID: <eom9rl$q9o$1@news.Stanford.EDU>
NNTP-Posting-Host: vine7.stanford.edu
X-Trace: news.Stanford.EDU 1169074869 26936 171.64.15.234 (17 Jan 2007 23:01:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11044

Hi,

Do we need to do anything special for the .gif files?
Somehow the last 'http://yuba.stanford.edu/vns/images/su.gif' is always
failing for me.

Thanks,
Dinesh

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gif files
Date: Wed, 17 Jan 2007 15:09:12 -0800
Lines: 15
Distribution: su
Message-ID: <eomaa9$qsh$1@news.Stanford.EDU>
References: <eom9rl$q9o$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169075338 27537 127.0.0.1 (17 Jan 2007 23:08:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eom9rl$q9o$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11045

Dinesh Gupta wrote:
> Hi,
> 
> Do we need to do anything special for the .gif files?
> Somehow the last 'http://yuba.stanford.edu/vns/images/su.gif' is always
> failing for me.
> 
> Thanks,
> Dinesh
> 

Just make sure you pass back to the client everything you receive from 
the server exactly as you receive it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Checking heading field values
Date: Wed, 17 Jan 2007 15:11:37 -0800
Lines: 18
Distribution: su
Message-ID: <eomae7$r6h$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169075463 27857 128.12.104.61 (17 Jan 2007 23:11:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11046

Hey All,

Are we supposed to be checking the field values for correctness in the
"field-name: field-value" pairs in the header? That is, I know we need 
to check that that headers are syntactically correct, but what about the
semantics of the field values?

For example, if we get the following "If-Modified-Since" header in the 
request:
GET http://www.xyz.com/index.html HTTP/1.0
If-Modified-Since: invalid-date-format

Should we return "Bad Request" to the client or forward to the server?
More generally, do we need to check that the field values are in 
compliance with what is laid out in the RFC? (I'm assuming yes.)

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Written assignment 1
Date: Wed, 17 Jan 2007 15:53:19 -0800
Lines: 7
Distribution: su
Message-ID: <eomcus$63$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169078044 195 171.64.74.36 (17 Jan 2007 23:54:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11047

Hi,

Is there a typo in problem 1? Part a seems to be missing the number of
students.

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 Q6 partB
Date: Wed, 17 Jan 2007 18:19:34 -0800
Lines: 5
Distribution: su
Message-ID: <eomlh5$8ac$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169086821 8524 171.64.74.36 (18 Jan 2007 02:20:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11048

Do we still assume that the average queue size is 128kbytes and the avg
pkt size is 260 bytes and no other packet drops?

Thanks,
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: errno
Date: Thu, 18 Jan 2007 02:46:52 +0000 (UTC)
Lines: 7
Distribution: su
Message-ID: <eomn2s$9fg$1@news.Stanford.EDU>
NNTP-Posting-Host: vine7.stanford.edu
X-Trace: news.Stanford.EDU 1169088412 9712 171.64.15.234 (18 Jan 2007 02:46:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11049

Hi,

I'm not able to see a valid errno. If the port is in use, bind fails
and returns < 0 but errno is 0. How can I capture correct errno?

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 Q9 part b
Date: Wed, 17 Jan 2007 19:00:34 -0800
Lines: 5
Distribution: su
Message-ID: <eomnu0$a8f$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169089280 10511 171.64.74.36 (18 Jan 2007 03:01:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11050

Do we need to give the arrival process? Are the units still bps or are
they packets per second?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Wed, 17 Jan 2007 19:43:20 -0800
Lines: 28
Distribution: su
Message-ID: <eomqct$c0v$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU> <eohufb$k3i$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1169091805 12319 128.12.83.54 (18 Jan 2007 03:43:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11051

Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" compile 
error, which doesn't go away even when I include <limits.h> or 
<sys/limits.h>

Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or 
something exceedingly large, and I don't really want to allocate a buffer 
that big.  Am I wrong on any of these points?  We can't exactly allocate a 
buffer that big...

--Alicia

"David Erickson" <derickso@stanford.edu> wrote in message 
news:eohufb$k3i$1@news.Stanford.EDU...
> Ryan Chen wrote:
>>
>> The read system call in man page section 2 indicates that we have to 
>> specify how much to read from the socket/descriptor. How do we know in 
>> advance how much the HTTP Request sent in is or how long a server's 
>> response is? Do we "try" to read as much as possible, up to ssize_max 
>> (something like that? I forgot), and then process the buffer?
>>
>> Thanks.
>
> Yes.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: errno
Date: Wed, 17 Jan 2007 19:51:03 -0800
Lines: 22
Distribution: su
Message-ID: <eomqrc$ci0$1@news.Stanford.EDU>
References: <eomn2s$9fg$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1169092268 12864 128.12.83.54 (18 Jan 2007 03:51:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11052

Use perror.

perror("Error occurred while blankety blank");

will output

Error occurred while blankety blank: error message from errno here

--Alicia


"Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
news:eomn2s$9fg$1@news.Stanford.EDU...
> Hi,
>
> I'm not able to see a valid errno. If the port is in use, bind fails
> and returns < 0 but errno is 0. How can I capture correct errno?
>
> Thanks,
> Dinesh 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 Q6 partB
Date: Wed, 17 Jan 2007 20:03:44 -0800
Lines: 10
Distribution: su
Message-ID: <eomrim$dcl$1@news.Stanford.EDU>
References: <eomlh5$8ac$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169093014 13717 127.0.0.1 (18 Jan 2007 04:03:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eomlh5$8ac$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11053

Jad Naous wrote:
> Do we still assume that the average queue size is 128kbytes and the avg
> pkt size is 260 bytes and no other packet drops?
> 
> Thanks,
> Jad

Yes.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 Q9 part b
Date: Wed, 17 Jan 2007 20:06:31 -0800
Lines: 11
Distribution: su
Message-ID: <eomrns$dcg$1@news.Stanford.EDU>
References: <eomnu0$a8f$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169093180 13712 127.0.0.1 (18 Jan 2007 04:06:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eomnu0$a8f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11054

Jad Naous wrote:
> Do we need to give the arrival process? 

You are given this, A(t)

> Are the units still bps or are
> they packets per second?

It depends on which equation you are referring to.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Written assignment 1
Date: Wed, 17 Jan 2007 20:07:27 -0800
Lines: 10
Distribution: su
Message-ID: <eomrpk$dcg$2@news.Stanford.EDU>
References: <eomcus$63$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169093236 13712 127.0.0.1 (18 Jan 2007 04:07:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eomcus$63$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11055

Jad Naous wrote:
> Hi,
> 
> Is there a typo in problem 1? Part a seems to be missing the number of
> students.

I'm waiting for a reply from Nick on whether this is just a general 
variable X or an actual number.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Checking heading field values
Date: Wed, 17 Jan 2007 20:09:51 -0800
Lines: 23
Distribution: su
Message-ID: <eomru4$dcg$3@news.Stanford.EDU>
References: <eomae7$r6h$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169093380 13712 127.0.0.1 (18 Jan 2007 04:09:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eomae7$r6h$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11056

Matt Page wrote:
> Hey All,
> 
> Are we supposed to be checking the field values for correctness in the
> "field-name: field-value" pairs in the header? That is, I know we need 
> to check that that headers are syntactically correct, but what about the
> semantics of the field values?
> 
> For example, if we get the following "If-Modified-Since" header in the 
> request:
> GET http://www.xyz.com/index.html HTTP/1.0
> If-Modified-Since: invalid-date-format
> 
> Should we return "Bad Request" to the client or forward to the server?
> More generally, do we need to check that the field values are in 
> compliance with what is laid out in the RFC? (I'm assuming yes.)
> 
> Thanks,
> Matt

For the headers just focus on syntax.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Wed, 17 Jan 2007 20:10:50 -0800
Lines: 13
Distribution: su
Message-ID: <eoms00$dcg$4@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU> <eohufb$k3i$1@news.Stanford.EDU> <eomqct$c0v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169093440 13712 127.0.0.1 (18 Jan 2007 04:10:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eomqct$c0v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11057

Alicia Chen wrote:
> Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" compile 
> error, which doesn't go away even when I include <limits.h> or 
> <sys/limits.h>
> 
> Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or 
> something exceedingly large, and I don't really want to allocate a buffer 
> that big.  Am I wrong on any of these points?  We can't exactly allocate a 
> buffer that big...

Check out the function realloc.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 Q9 part b
Date: Wed, 17 Jan 2007 20:28:50 -0800
Lines: 24
Distribution: su
Message-ID: <eomsv7$ek0$1@news.Stanford.EDU>
References: <eomnu0$a8f$1@news.Stanford.EDU> <eomrns$dcg$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169094439 14976 128.12.134.140 (18 Jan 2007 04:27:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <eomrns$dcg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11058

David Erickson wrote:
> Jad Naous wrote:
>> Do we need to give the arrival process? 
> 
> You are given this, A(t)

for part b we aren't given an explicit (equation form as a function of
time) A(t). Do we need to give it?

> 
>> Are the units still bps or are
>> they packets per second?
> 
> It depends on which equation you are referring to.

for part b, is D(t) in bps or packet/s? and X(t) is it in packets or in
bits?


> 
> -David

Thanks,\
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: errno
Date: Thu, 18 Jan 2007 04:49:41 +0000 (UTC)
Lines: 26
Distribution: su
Message-ID: <eomu95$fln$1@news.Stanford.EDU>
References: <eomn2s$9fg$1@news.Stanford.EDU> <eomqrc$ci0$1@news.Stanford.EDU>
NNTP-Posting-Host: vine7.stanford.edu
X-Trace: news.Stanford.EDU 1169095781 16055 171.64.15.234 (18 Jan 2007 04:49:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11059

Alicia Chen <achen530@stanford.edu> wrote:
> Use perror.

> perror("Error occurred while blankety blank");

> will output

> Error occurred while blankety blank: error message from errno here

> --Alicia

Thanks Alicia, but I wanted to know errno so that I could print
error messages at one place. 


> "Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
> news:eomn2s$9fg$1@news.Stanford.EDU...
> > Hi,
> >
> > I'm not able to see a valid errno. If the port is in use, bind fails
> > and returns < 0 but errno is 0. How can I capture correct errno?
> >
> > Thanks,
> > Dinesh 


.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Remote student turning in PS1
Date: Wed, 17 Jan 2007 21:05:16 -0800
Lines: 6
Distribution: su
Message-ID: <Pine.LNX.4.62.0701172103350.3567@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169096717 17000 171.64.66.201 (18 Jan 2007 05:05:17 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11061

Hi, I am an SCPD student and am wondering what is the best way to hand my 
first problem set to Judy Polenta. Can we have her email address so that 
remote students like me can send her our solution using email before the 
deadline?

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Remote student turning in PS1
Date: Wed, 17 Jan 2007 21:24:47 -0800
Lines: 21
Distribution: su
Message-ID: <C1D4449F.768A%jpettit@stanford.edu>
References: <Pine.LNX.4.62.0701172103350.3567@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169097891 17968 127.0.0.1 (18 Jan 2007 05:24:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Remote student turning in PS1
Thread-Index: Acc6wPfdNmCJrKa0Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11062

Just fill out the routing form and fax it to SCPD:

    http://scpd.stanford.edu/scpd/downloads/onlineRouteForm.pdf

They'll deliver it to us.

--Justin


On 1/17/07 9:05 PM, in article
Pine.LNX.4.62.0701172103350.3567@xenon.Stanford.EDU, "Ryan Chen"
<ryanchen@xenon.Stanford.EDU> wrote:

> Hi, I am an SCPD student and am wondering what is the best way to hand my
> first problem set to Judy Polenta. Can we have her email address so that
> remote students like me can send her our solution using email before the
> deadline?
> 
> Thanks.


.

Path: shelby.stanford.edu!not-for-mail
From: Shashidhar Shashidhar <bhandare@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 06:01:16 +0000 (UTC)
Lines: 8
Distribution: su
Message-ID: <eon2fc$j07$1@news.Stanford.EDU>
NNTP-Posting-Host: myth17.stanford.edu
X-Trace: news.Stanford.EDU 1169100076 19463 171.64.15.58 (18 Jan 2007 06:01:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11063

Hi,

Sometimes I see that the proxy gets stuck in read( ) system call and
what should we do here. When can this happen and how to come out of this
condition.

Thanks,
Shashidhar.
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 22:23:14 -0800
Lines: 30
Distribution: su
Message-ID: <eon3ot$k7k$1@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU> <eolsqg$ctk$2@news.Stanford.EDU> <eoltvf$eap$1@news.Stanford.EDU> <45AE8344.80907@stanford.edu>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1169101405 20724 171.64.75.59 (18 Jan 2007 06:23:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11064


So the original intent of my question was:
isn't your script supposed to be sending us HTTP/1.0 requests instead of 
HTTP/1.1 requests?
Please advise.
-Steven

"David Erickson" <derickso@stanford.edu> wrote in message 
news:45AE8344.80907@stanford.edu...
> Randy Jennings wrote:
>>> No I am definitely not saying that, if the incoming request is missing 
>>> invalid (according to the spec you are implementing), then what do you 
>>> do?
>>
>> I think something got lost between 'missing' and 'invalid', but I think 
>> you are (now) saying that Host: (while not making the request invalid 
>> (according to rfc1945, see other post by Riju)) does not compensate for 
>> not having the full url in the request line (invalid according to our 
>> project spec). However, that refers back to my previous (in time) post on 
>> implications of the grading script.
>>
>> How is python being set to use HTTP/1.0 instead of HTTP/1.1?
>>
>
> I'm not positive which version python is sending requests as, but it does 
> not appear to effect the response.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Wed, 17 Jan 2007 22:26:04 -0800
Lines: 11
Distribution: su
Message-ID: <eon3ts$k8s$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169101564 20764 127.0.0.1 (18 Jan 2007 06:26:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eon2fc$j07$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11065

Shashidhar Shashidhar wrote:
> Hi,
> 
> Sometimes I see that the proxy gets stuck in read( ) system call and
> what should we do here. When can this happen and how to come out of this
> condition.
> 
> Thanks,
> Shashidhar.

reading from the client or server?
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Wed, 17 Jan 2007 22:28:28 -0800
Lines: 10
Distribution: su
Message-ID: <eon42c$k8s$2@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU> <eolsqg$ctk$2@news.Stanford.EDU> <eoltvf$eap$1@news.Stanford.EDU> <45AE8344.80907@stanford.edu> <eon3ot$k7k$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169101708 20764 127.0.0.1 (18 Jan 2007 06:28:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eon3ot$k7k$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11066

Euijong Whang wrote:
> So the original intent of my question was:
> isn't your script supposed to be sending us HTTP/1.0 requests instead of 
> HTTP/1.1 requests?
> Please advise.
> -Steven

Drop Clay an email about it.

-David
.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Wed, 17 Jan 2007 22:39:46 -0800
Lines: 23
Distribution: su
Message-ID: <Pine.LNX.4.62.0701172238050.26374@xenon.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU>
 <eohufb$k3i$1@news.Stanford.EDU> <eomqct$c0v$1@news.Stanford.EDU>
 <eoms00$dcg$4@news.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169102388 21490 171.64.66.201 (18 Jan 2007 06:39:48 GMT)
X-Complaints-To: news@news.stanford.edu
To: David Erickson <derickso@stanford.edu>
In-Reply-To: <eoms00$dcg$4@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11067

Just so you know, I actually didn't use a variable named ssize_max in my 
implmentation. I was only saying allocate a buffer that can get as much 
as possible from the socket. Don't spend time looking up this ssize_max. 
Try think about how to recursively use the realloc or similar functions 
to implement this. Hopefully this clear some things up.

On Wed, 17 Jan 
2007, David Erickson wrote:

> Alicia Chen wrote:
>> Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" compile 
>> error, which doesn't go away even when I include <limits.h> or 
>> <sys/limits.h>
>> 
>> Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or 
>> something exceedingly large, and I don't really want to allocate a buffer 
>> that big.  Am I wrong on any of these points?  We can't exactly allocate a 
>> buffer that big...
>
> Check out the function realloc.
>
> -David
>
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Grade script hanging
Date: Wed, 17 Jan 2007 23:43:35 -0700
Lines: 14
Distribution: su
Message-ID: <eon4uo$l8h$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169102616 21777 127.0.0.1 (18 Jan 2007 06:43:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11068

I haven't used python before.  When I type "./proxy_grader.py proxy 5001" at 
the prompt on bramble, I get...

Binary: proxy
Running on port 5001

But then nothing happens.  How do you get visibility into what's going on? 
The call trace that appears when I hit ctrl-c isn't very enlightening.

(FYI, when I use my proxy on Linux at home with a Firefox browser, it seems 
to work fine.)



.

Path: shelby.stanford.edu!not-for-mail
From: Shashidhar Shashidhar <bhandare@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 07:14:40 +0000 (UTC)
Lines: 14
Distribution: su
Message-ID: <eon6p0$m45$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
X-Trace: news.Stanford.EDU 1169104480 22661 171.64.15.61 (18 Jan 2007 07:14:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11069

David Erickson <derickso@stanford.edu> wrote:
> Shashidhar Shashidhar wrote:
> > Hi,
> > 
> > Sometimes I see that the proxy gets stuck in read( ) system call and
> > what should we do here. When can this happen and how to come out of this
> > condition.
> > 
> > Thanks,
> > Shashidhar.

> reading from the client or server?

Mostly while reading from the client. Once saw from the client also.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Wed, 17 Jan 2007 23:55:09 -0800
Lines: 21
Distribution: su
Message-ID: <eon94t$rbe$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eon6p0$m45$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169106909 28014 127.0.0.1 (18 Jan 2007 07:55:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eon6p0$m45$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11070

Shashidhar Shashidhar wrote:
> David Erickson <derickso@stanford.edu> wrote:
>> Shashidhar Shashidhar wrote:
>>> Hi,
>>>
>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>> what should we do here. When can this happen and how to come out of this
>>> condition.
>>>
>>> Thanks,
>>> Shashidhar.
> 
>> reading from the client or server?
> 
> Mostly while reading from the client. Once saw from the client also.

Make sure you only read until you get the full request from the client, 
if you try and read beyond what the client is going to send it will hang 
until the client disconnects the socket.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Grade script hanging
Date: Wed, 17 Jan 2007 23:56:09 -0800
Lines: 19
Distribution: su
Message-ID: <eon96p$rbe$2@news.Stanford.EDU>
References: <eon4uo$l8h$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169106969 28014 127.0.0.1 (18 Jan 2007 07:56:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eon4uo$l8h$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11071

Kevin Hart wrote:
> I haven't used python before.  When I type "./proxy_grader.py proxy 5001" at 
> the prompt on bramble, I get...
> 
> Binary: proxy
> Running on port 5001
> 
> But then nothing happens.  How do you get visibility into what's going on? 
> The call trace that appears when I hit ctrl-c isn't very enlightening.
> 
> (FYI, when I use my proxy on Linux at home with a Firefox browser, it seems 
> to work fine.)
>

You can edit the script and have it dump what its doing to you if you'd 
like, but your better off I would imagine printing status from your 
proxy executable to the console.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 01:19:06 -0800
Lines: 31
Distribution: su
Message-ID: <eone2e$42e$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169111950 4174 127.0.0.1 (18 Jan 2007 09:19:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11072

I am runninng into the same problem with my proxy, I don't get a response 
from the server.  I show that I connect just fine using serive name of www 
on port 80.

As a check I have run the server.c and setup a server with a port of 8001. 
Then I ran my proxy on 8000 and telneted to localhost 8000, sent a message 
to localhost on port 8001, saw my message reach the server and then get a 
response.

I'm starting to think that there is something blocking the returns of the 
reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and then 
GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do I 
need to somehow mimic this to get my proxy to read the data?

--Brian

"David Erickson" <derickso@stanford.edu> wrote in message 
news:eon3ts$k8s$1@news.Stanford.EDU...
> Shashidhar Shashidhar wrote:
>> Hi,
>>
>> Sometimes I see that the proxy gets stuck in read( ) system call and
>> what should we do here. When can this happen and how to come out of this
>> condition.
>>
>> Thanks,
>> Shashidhar.
>
> reading from the client or server? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Is Host: header valid in HTTP/1.0?
Date: Thu, 18 Jan 2007 01:29:31 -0800
Lines: 24
Distribution: su
Message-ID: <eonem6$4ib$1@news.Stanford.EDU>
References: <eol1cr$hbb$1@news.Stanford.EDU> <eolrf8$bmc$2@news.Stanford.EDU> <eolskv$d0r$1@news.Stanford.EDU> <eolsqg$ctk$2@news.Stanford.EDU> <eoltvf$eap$1@news.Stanford.EDU> <45AE8344.80907@stanford.edu> <eon3ot$k7k$1@news.Stanford.EDU> <eon42c$k8s$2@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1169112582 4683 171.64.75.59 (18 Jan 2007 09:29:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11073


David,

My apologies.. I was printing out the request line after explicitly removing 
the host.
Totally my mistake.

-Steven


"David Erickson" <derickso@stanford.edu> wrote in message 
news:eon42c$k8s$2@news.Stanford.EDU...
> Euijong Whang wrote:
>> So the original intent of my question was:
>> isn't your script supposed to be sending us HTTP/1.0 requests instead of 
>> HTTP/1.1 requests?
>> Please advise.
>> -Steven
>
> Drop Clay an email about it.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 15:54:07 +0000 (UTC)
Lines: 44
Distribution: su
Message-ID: <eoo56v$qrp$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU>
NNTP-Posting-Host: myth25.stanford.edu
X-Trace: news.Stanford.EDU 1169135647 27513 171.64.15.40 (18 Jan 2007 15:54:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11074

Hi,

I'm also seeing this problem when I configured firefox to use my proxy.
It's stuck in read while reading from the remote server(yahoo). It
worked fine with cnn though. So it doesn't happen always but very
annoying when it happens. Please let me know how to come out of this read call.

Thanks,
Dinesh



Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
> I am runninng into the same problem with my proxy, I don't get a response 
> from the server.  I show that I connect just fine using serive name of www 
> on port 80.

> As a check I have run the server.c and setup a server with a port of 8001. 
> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a message 
> to localhost on port 8001, saw my message reach the server and then get a 
> response.

> I'm starting to think that there is something blocking the returns of the 
> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and then 
> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do I 
> need to somehow mimic this to get my proxy to read the data?

> --Brian

> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:eon3ts$k8s$1@news.Stanford.EDU...
> > Shashidhar Shashidhar wrote:
> >> Hi,
> >>
> >> Sometimes I see that the proxy gets stuck in read( ) system call and
> >> what should we do here. When can this happen and how to come out of this
> >> condition.
> >>
> >> Thanks,
> >> Shashidhar.
> >
> > reading from the client or server? 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 09:24:29 -0800
Lines: 44
Distribution: su
Message-ID: <C1D4ED4D.76BE%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169141073 3256 127.0.0.1 (18 Jan 2007 17:24:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7JYJYwQWx4KcYEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11075

You definitely should not send three "\r\n" to indicate the end of a
request--that's contrary to the RFC.  I just connected to www.yahoo.com over
a dozen times, and never had to hit enter more than twice.  Are you running
your tests on one of the Myths?

--Justin


On 1/18/07 1:19 AM, in article eone2e$42e$1@news.Stanford.EDU, "Brian
Thompson" <Brian.C.Thompson@Boeing.com> wrote:

> I am runninng into the same problem with my proxy, I don't get a response
> from the server.  I show that I connect just fine using serive name of www
> on port 80.
> 
> As a check I have run the server.c and setup a server with a port of 8001.
> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a message
> to localhost on port 8001, saw my message reach the server and then get a
> response.
> 
> I'm starting to think that there is something blocking the returns of the
> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and then
> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do I
> need to somehow mimic this to get my proxy to read the data?
> 
> --Brian
> 
> "David Erickson" <derickso@stanford.edu> wrote in message
> news:eon3ts$k8s$1@news.Stanford.EDU...
>> Shashidhar Shashidhar wrote:
>>> Hi,
>>> 
>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>> what should we do here. When can this happen and how to come out of this
>>> condition.
>>> 
>>> Thanks,
>>> Shashidhar.
>> 
>> reading from the client or server?
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 09:28:45 -0800
Lines: 61
Distribution: su
Message-ID: <C1D4EE4D.76C2%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169141326 3383 127.0.0.1 (18 Jan 2007 17:28:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7JhruWVQOgKcZEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11076

The best way to prevent blocking is to use the system call "select" or
"poll" to determine whether there is data to be read.  You can also mark the
socket as non-blocking.  However, you shouldn't need to do either of these
for this assignment.

As David mentioned earlier, make sure that you don't immediately try to
read() again after getting a zero return value, otherwise you'll block.

--Justin
 

On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
Gupta" <dineshg@Stanford.EDU> wrote:

> Hi,
> 
> I'm also seeing this problem when I configured firefox to use my proxy.
> It's stuck in read while reading from the remote server(yahoo). It
> worked fine with cnn though. So it doesn't happen always but very
> annoying when it happens. Please let me know how to come out of this read
> call.
> 
> Thanks,
> Dinesh
> 
> 
> 
> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>> I am runninng into the same problem with my proxy, I don't get a response
>> from the server.  I show that I connect just fine using serive name of www
>> on port 80.
> 
>> As a check I have run the server.c and setup a server with a port of 8001.
>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a message
>> to localhost on port 8001, saw my message reach the server and then get a
>> response.
> 
>> I'm starting to think that there is something blocking the returns of the
>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and then
>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do I
>> need to somehow mimic this to get my proxy to read the data?
> 
>> --Brian
> 
>> "David Erickson" <derickso@stanford.edu> wrote in message
>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>> Shashidhar Shashidhar wrote:
>>>> Hi,
>>>> 
>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>> what should we do here. When can this happen and how to come out of this
>>>> condition.
>>>> 
>>>> Thanks,
>>>> Shashidhar.
>>> 
>>> reading from the client or server?
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Updated Problem Set 1
Date: Thu, 18 Jan 2007 10:01:08 -0800
Lines: 5
Distribution: su
Message-ID: <eoocl4$50r$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169143268 5147 127.0.0.1 (18 Jan 2007 18:01:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11077

Please be aware I have posted an updated Problem Set 1, there was a typo 
in 1a which has been fixed.

Thanks,
David
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: Submission
Date: Thu, 18 Jan 2007 11:05:11 -0800
Lines: 4
Distribution: su
Message-ID: <eoogd8$8kk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169147112 8852 127.0.0.1 (18 Jan 2007 19:05:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11078

When I tried to submit the web proxy on the course website I get "You do not 
have permission to access the requested directory." Why is this happening? 


.

Path: shelby.stanford.edu!myth22.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Parsing request
Date: Thu, 18 Jan 2007 12:26:46 -0800
Lines: 10
Distribution: su
Message-ID: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU>
NNTP-Posting-Host: myth22.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1169152009 13143 171.64.15.36 (18 Jan 2007 20:26:49 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11079


Hi,

How exact do we need to parse the request/response? Do I need to make sure
that requests and responses are exactly as defined in RFC documents?


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission
Date: Thu, 18 Jan 2007 12:38:28 -0800
Lines: 10
Distribution: su
Message-ID: <eoolvc$dei$1@news.Stanford.EDU>
References: <eoogd8$8kk$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169152812 13778 171.64.74.54 (18 Jan 2007 20:40:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eoogd8$8kk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11080

Alex wrote:
> When I tried to submit the web proxy on the course website I get "You do not 
> have permission to access the requested directory." Why is this happening? 
> 
> 
Are you seeing this error as soon as you click on the 'Submit an 
Assignment' link from the front page, or only after you press the submit 
button on the submissions page?  Are you able to authenticate with WebAuth?

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Error code for unknown host
Date: Thu, 18 Jan 2007 13:09:32 -0800
Lines: 5
Distribution: su
Message-ID: <eoonmf$erk$1@news.Stanford.EDU>
NNTP-Posting-Host: hr-chyoon-1158559642.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169154575 15220 171.66.147.181 (18 Jan 2007 21:09:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11081

If the user sends a request from an unknown host, what error should we 
return? Is it 400 Bad Request or 404 Not Found?

Thanks,
Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: Re: Submission
Date: Thu, 18 Jan 2007 13:22:45 -0800
Lines: 16
Distribution: su
Message-ID: <eooof8$frb$1@news.Stanford.EDU>
References: <eoogd8$8kk$1@news.Stanford.EDU> <eoolvc$dei$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169155368 16235 127.0.0.1 (18 Jan 2007 21:22:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11082

After I authenticate I see this issue.

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eoolvc$dei$1@news.Stanford.EDU...
> Alex wrote:
>> When I tried to submit the web proxy on the course website I get "You do 
>> not have permission to access the requested directory." Why is this 
>> happening?
> Are you seeing this error as soon as you click on the 'Submit an 
> Assignment' link from the front page, or only after you press the submit 
> button on the submissions page?  Are you able to authenticate with 
> WebAuth?
>
> Clay 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Error code for unknown host
Date: Thu, 18 Jan 2007 13:34:31 -0800
Lines: 17
Distribution: su
Message-ID: <C1D527E7.76F4%jpettit@stanford.edu>
References: <eoonmf$erk$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169156077 16962 127.0.0.1 (18 Jan 2007 21:34:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Error code for unknown host
Thread-Index: Acc7SHA7rpdD1Kc7Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11083

Do you mean "to an unknown host"?  If so, then send back a 400.  You won't
need to generate a 404, since that has to do with missing pages.  However,
if the server generates a 404, you should pass that on.

--Justin


On 1/18/07 1:09 PM, in article eoonmf$erk$1@news.Stanford.EDU, "Chee-Hyung
Yoon" <chyoon@stanford.edu> wrote:

> If the user sends a request from an unknown host, what error should we
> return? Is it 400 Bad Request or 404 Not Found?
> 
> Thanks,
> Chee-Hyung


.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: GetHostByName error
Date: Thu, 18 Jan 2007 21:49:20 +0000 (UTC)
Lines: 10
Distribution: su
Message-ID: <eooq10$h40$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine6.stanford.edu
X-Trace: news.Stanford.EDU 1169156960 17536 171.64.15.71 (18 Jan 2007 21:49:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:11084


Hi,
  When I try to connect to the site HTTP://www.stanford.edu directly
it works fine. However when I run it through the grading script
I get an error for gethostbyname() which correcponds to TRY_AGAIN.
The function doesnt return successfully even with a number of tries. 
What could be wrong?

Thanks
Dina 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: GetHostByName error
Date: Thu, 18 Jan 2007 14:04:50 -0800
Lines: 21
Distribution: su
Message-ID: <C1D52F02.76FB%jpettit@stanford.edu>
References: <eooq10$h40$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169157894 18463 127.0.0.1 (18 Jan 2007 22:04:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: GetHostByName error
Thread-Index: Acc7TKxx6skMOac/Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11085

Are you trying to resolve "HTTP://www.stanford.edu"?  If so, then you need
to strip off the "HTTP://" before passing it to the resolver.

--Justin


On 1/18/07 1:49 PM, in article eooq10$h40$1@news.Stanford.EDU, "Dina Thomas"
<dinat@Stanford.EDU> wrote:

> 
> Hi,
>   When I try to connect to the site HTTP://www.stanford.edu directly
> it works fine. However when I run it through the grading script
> I get an error for gethostbyname() which correcponds to TRY_AGAIN.
> The function doesnt return successfully even with a number of tries.
> What could be wrong?
> 
> Thanks
> Dina 


.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: strdup
Date: Thu, 18 Jan 2007 14:45:27 -0800
Lines: 13
Distribution: su
Message-ID: <eoota9$j2m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1169160330 19542 127.0.0.1 (18 Jan 2007 22:45:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:11086

Hello. I used strdup() fairly liberally in my program, only to find out 
today when I tried to submit that they are technically (I belive) not 
supported by ANSI C. Is this a big enough problem that I should go 
through my code and change them, or can I just compile without the 
-ansi flag and go with it.

As a second unrelated question, if I run the tests over and over again, 
I occassionally encounter a failure. Sometimes it's a date string that 
changed on one of the sites, and sometimes it looks like the GET just 
choked for whatever reason. Is the testing script going to be run 
multiple times to isolate spot failures?


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission
Date: Thu, 18 Jan 2007 14:51:06 -0800
Lines: 23
Distribution: su
Message-ID: <eooto3$kb9$1@news.Stanford.EDU>
References: <eoogd8$8kk$1@news.Stanford.EDU> <eoolvc$dei$1@news.Stanford.EDU> <eooof8$frb$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169160771 20841 171.64.74.54 (18 Jan 2007 22:52:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eooof8$frb$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11087

Try clearing your browser cache and trying the link again.  Also, make 
sure that your browser is accepting cookies from both 
webauth.stanford.edu and www.stanford.edu.

Clay

Alex wrote:
> After I authenticate I see this issue.
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eoolvc$dei$1@news.Stanford.EDU...
>> Alex wrote:
>>> When I tried to submit the web proxy on the course website I get "You do 
>>> not have permission to access the requested directory." Why is this 
>>> happening?
>> Are you seeing this error as soon as you click on the 'Submit an 
>> Assignment' link from the front page, or only after you press the submit 
>> button on the submissions page?  Are you able to authenticate with 
>> WebAuth?
>>
>> Clay 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: elaine vs. myth
Date: Thu, 18 Jan 2007 22:54:20 +0000 (UTC)
Organization: Your Company
Lines: 1
Distribution: su
Message-ID: <Xns98BC97A2A5FE4chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169160860 20983 128.12.22.217 (18 Jan 2007 22:54:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11088

i can't seem to log-in properly on myth. can i use elaine?
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: elaine vs. myth
Date: Thu, 18 Jan 2007 15:06:39 -0800
Lines: 15
Distribution: su
Message-ID: <C1D53D7F.770B%jpettit@stanford.edu>
References: <Xns98BC97A2A5FE4chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169161602 21684 127.0.0.1 (18 Jan 2007 23:06:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: elaine vs. myth
Thread-Index: Acc7VU8tjaRo/qdIEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11089

You're welcome to use it.  Keep in mind that the Elaines are Solaris Sparc
machines.  We're going to be testing them on Linux x86 systems.  If you
write properly portable code, then you won't haven any issues, but that can
be tricky.

--Justin


On 1/18/07 2:54 PM, in article
Xns98BC97A2A5FE4chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> i can't seem to log-in properly on myth. can i use elaine?


.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Sending error code back
Date: Thu, 18 Jan 2007 15:08:14 -0800
Lines: 14
Distribution: su
Message-ID: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169161697 21789 171.64.66.201 (18 Jan 2007 23:08:17 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11090

For a bad request from the client, I am trying to send "HTTP/1.0 400 Bad 
Request\r\n\r\n" back to the client via the socket with the client, but 
once I close the socket, it gives me a socket error from the grader 
script:

IOError: [Errno socket error] (-2, 'Name or service not known')

Any clue why this is happening? If I send the message back to the client, 
but "don't" close the socket to the client, then this message won't 
appear, but the process just hangs, so it seems to me the client is still 
trying to read the socket somehow even though I sent a bad reqest response 
back......

Thanks for any answer.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: strdup
Date: Thu, 18 Jan 2007 15:14:54 -0800
Lines: 26
Distribution: su
Message-ID: <C1D53F6E.770E%jpettit@stanford.edu>
References: <eoota9$j2m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169162102 22154 127.0.0.1 (18 Jan 2007 23:15:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: strdup
Thread-Index: Acc7VnY4tIIKUqdJEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11091

On 1/18/07 2:45 PM, in article eoota9$j2m$1@news.Stanford.EDU, "Adam Cohen"
<adam.cohen@stanford.edu> wrote:

> Hello. I used strdup() fairly liberally in my program, only to find out
> today when I tried to submit that they are technically (I belive) not
> supported by ANSI C. Is this a big enough problem that I should go
> through my code and change them, or can I just compile without the
> -ansi flag and go with it.

Don't worry too much about that.  It's part of the standard C libraries on
the Myth systems, so as long as it compiles cleanly, we're happy.

> As a second unrelated question, if I run the tests over and over again,
> I occassionally encounter a failure. Sometimes it's a date string that
> changed on one of the sites, and sometimes it looks like the GET just
> choked for whatever reason. Is the testing script going to be run
> multiple times to isolate spot failures?

I imagine that if we see a problem we'll give it another shot.  If you are
finding particular problems in the grading script, please keep posting them
on the newsgroup.  Also, if you get dinged in your grade and you can
demonstrate it's a problem in the grading script, we'll gladly add the
points back. 

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: what's going on???? // = error?
Date: Thu, 18 Jan 2007 23:19:46 +0000 (UTC)
Organization: Your Company
Lines: 14
Distribution: su
Message-ID: <Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169162386 20983 128.12.22.217 (18 Jan 2007 23:19:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11092

i'm going crazy...

all i have is

void main()
{
    	int x;    	//x
}

and this doesn't compile.

but if i remove "//x" it compiles just fine...

i'm using myth
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing request
Date: Thu, 18 Jan 2007 15:21:43 -0800
Lines: 23
Distribution: su
Message-ID: <C1D54107.7715%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169162504 22449 127.0.0.1 (18 Jan 2007 23:21:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Parsing request
Thread-Index: Acc7V2oBqErqjKdKEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11093

Don't worry about parsing much of the request and response.  For the
request, make sure that it makes sense, but you don't have to verify all the
headers.  For the response, make sure that you get a proper response status
line and then just pass everything else through unmodified.

--Justin


On 1/18/07 12:26 PM, in article
Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU, "Seung Hoon
Choi" <shchoi@stanford.edu> wrote:

> 
> Hi,
> 
> How exact do we need to parse the request/response? Do I need to make sure
> that requests and responses are exactly as defined in RFC documents?
> 
> 
> Thanks,
> -Seung
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: what's going on???? // = error?
Date: Thu, 18 Jan 2007 15:22:22 -0800
Lines: 22
Distribution: su
Message-ID: <eoovfq$m14$1@news.Stanford.EDU>
References: <Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169162554 22564 128.12.81.44 (18 Jan 2007 23:22:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11094

// isn't valid commenting in ANSI C AFAIK. Use /* ... */

David Gobaud

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103...
> i'm going crazy...
>
> all i have is
>
> void main()
> {
>    int x;    //x
> }
>
> and this doesn't compile.
>
> but if i remove "//x" it compiles just fine...
>
> i'm using myth 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: what's going on???? // = error?
Date: Thu, 18 Jan 2007 15:23:09 -0800
Lines: 29
Distribution: su
Message-ID: <C1D5415D.7716%jpettit@stanford.edu>
References: <Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169162594 22580 127.0.0.1 (18 Jan 2007 23:23:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: what's going on???? // = error?
Thread-Index: Acc7V51D2+FoVadKEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11095

That's a C++ comment.  Try this:

    int x;  /* x */

Some compilers are sticklers about the C code using C++ comments.

--Justin


On 1/18/07 3:19 PM, in article
Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> i'm going crazy...
> 
> all i have is
> 
> void main()
> {
> int x;     //x
> }
> 
> and this doesn't compile.
> 
> but if i remove "//x" it compiles just fine...
> 
> i'm using myth


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Sending error code back
Date: Thu, 18 Jan 2007 15:30:59 -0800
Lines: 27
Distribution: su
Message-ID: <C1D54333.771C%jpettit@stanford.edu>
References: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169163065 22969 127.0.0.1 (18 Jan 2007 23:31:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Sending error code back
Thread-Index: Acc7WLVn87RmdadLEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11096

Are you sure the write completed?  It doesn't seem like you've written
enough data to require it, but you may need to call write() multiple times
to completely send your data.

--Justin


On 1/18/07 3:08 PM, in article
Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU, "Ryan Chen"
<ryanchen@xenon.Stanford.EDU> wrote:

> For a bad request from the client, I am trying to send "HTTP/1.0 400 Bad
> Request\r\n\r\n" back to the client via the socket with the client, but
> once I close the socket, it gives me a socket error from the grader
> script:
> 
> IOError: [Errno socket error] (-2, 'Name or service not known')
> 
> Any clue why this is happening? If I send the message back to the client,
> but "don't" close the socket to the client, then this message won't
> appear, but the process just hangs, so it seems to me the client is still
> trying to read the socket somehow even though I sent a bad reqest response
> back......
> 
> Thanks for any answer.


.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Sending error code back
Date: Thu, 18 Jan 2007 15:40:40 -0800
Lines: 39
Distribution: su
Message-ID: <Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU>
References: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU>
 <C1D54333.771C%jpettit@stanford.edu>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169163642 23424 171.64.66.201 (18 Jan 2007 23:40:42 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <C1D54333.771C%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11097

Yes, I am sure iis written through, I checked the number of bytes return 
by the write() call, and it equals the number of chars in my string.

Also, what do you mean by "it doens't seem like you've written enough data 
to require it"? What is this "required it"? Require what?

Thanks.


On Thu, 18 Jan 2007, Justin Pettit wrote:

> Are you sure the write completed?  It doesn't seem like you've written
> enough data to require it, but you may need to call write() multiple times
> to completely send your data.
>
> --Justin
>
>
> On 1/18/07 3:08 PM, in article
> Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU, "Ryan Chen"
> <ryanchen@xenon.Stanford.EDU> wrote:
>
>> For a bad request from the client, I am trying to send "HTTP/1.0 400 Bad
>> Request\r\n\r\n" back to the client via the socket with the client, but
>> once I close the socket, it gives me a socket error from the grader
>> script:
>>
>> IOError: [Errno socket error] (-2, 'Name or service not known')
>>
>> Any clue why this is happening? If I send the message back to the client,
>> but "don't" close the socket to the client, then this message won't
>> appear, but the process just hangs, so it seems to me the client is still
>> trying to read the socket somehow even though I sent a bad reqest response
>> back......
>>
>> Thanks for any answer.
>
>
>
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: elaine vs. myth
Date: Thu, 18 Jan 2007 15:39:11 -0800
Lines: 22
Distribution: su
Message-ID: <eop0i8$mm9$1@news.Stanford.EDU>
References: <Xns98BC97A2A5FE4chunkaiwstanfordedu@171.64.14.103> <C1D53D7F.770B%jpettit@stanford.edu>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169163656 23241 171.64.74.54 (18 Jan 2007 23:40:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <C1D53D7F.770B%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11098

It's also worth mentioning that the myth machines sometimes hang on 
login for no apparent reason- trying back in a few minutes may net a 
different result.  The bramble and hedge machines are also running x86 
Linux, if you want to try those instead.

Clay
Justin Pettit wrote:
> You're welcome to use it.  Keep in mind that the Elaines are Solaris Sparc
> machines.  We're going to be testing them on Linux x86 systems.  If you
> write properly portable code, then you won't haven any issues, but that can
> be tricky.
> 
> --Justin
> 
> 
> On 1/18/07 2:54 PM, in article
> Xns98BC97A2A5FE4chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
> <chunkaiw@stanford.edu> wrote:
> 
>> i can't seem to log-in properly on myth. can i use elaine?
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Submission Tarballs
Date: Thu, 18 Jan 2007 15:45:37 -0800
Lines: 7
Distribution: su
Message-ID: <eop0ua$n6m$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169164042 23766 171.64.74.54 (18 Jan 2007 23:47:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11099

Please make sure that you are gzipping the tar archives that you submit 
(use 'tar zcf' to create the file)- it will save you time performing the 
upload, and makes it easier for us to process the submissions in a 
batch.  Check out the sample Makefile on the assignment page if you're 
not sure how to tar up your working files.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Thu, 18 Jan 2007 15:50:59 -0800
Lines: 25
Distribution: su
Message-ID: <eop15e$nek$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU> <eohufb$k3i$1@news.Stanford.EDU> <eomqct$c0v$1@news.Stanford.EDU> <eoms00$dcg$4@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169164270 24020 128.12.81.44 (18 Jan 2007 23:51:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11100

So we shouldn't allocate a buffer of size SSIZE_MAX as it seems to be 
defined as something big (LONG_MAX) correct? Shouldn't we allocate a 
temporary read buffer in the range of something like [1024, 10240], pass 
that buffer to recv, and copy from it to the real data buffer which is 
grown/realloced as needed?

David Gobaud

"David Erickson" <derickso@stanford.edu> wrote in message 
news:eoms00$dcg$4@news.Stanford.EDU...
> Alicia Chen wrote:
>> Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" compile 
>> error, which doesn't go away even when I include <limits.h> or 
>> <sys/limits.h>
>>
>> Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or 
>> something exceedingly large, and I don't really want to allocate a buffer 
>> that big.  Am I wrong on any of these points?  We can't exactly allocate 
>> a buffer that big...
>
> Check out the function realloc.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 15:52:47 -0800
Lines: 61
Distribution: su
Message-ID: <eop18i$nic$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <C1D4ED4D.76BE%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169164371 24140 127.0.0.1 (18 Jan 2007 23:52:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11101

Yeah, I use PUTTY to get into myth.stanford.edu and run Exceed for an X 
windows.  Should I be on something else?

--Brian

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D4ED4D.76BE%jpettit@stanford.edu...
> You definitely should not send three "\r\n" to indicate the end of a
> request--that's contrary to the RFC.  I just connected to www.yahoo.com 
> over
> a dozen times, and never had to hit enter more than twice.  Are you 
> running
> your tests on one of the Myths?
>
> --Justin
>
>
> On 1/18/07 1:19 AM, in article eone2e$42e$1@news.Stanford.EDU, "Brian
> Thompson" <Brian.C.Thompson@Boeing.com> wrote:
>
>> I am runninng into the same problem with my proxy, I don't get a response
>> from the server.  I show that I connect just fine using serive name of 
>> www
>> on port 80.
>>
>> As a check I have run the server.c and setup a server with a port of 
>> 8001.
>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a 
>> message
>> to localhost on port 8001, saw my message reach the server and then get a
>> response.
>>
>> I'm starting to think that there is something blocking the returns of the
>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and 
>> then
>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do 
>> I
>> need to somehow mimic this to get my proxy to read the data?
>>
>> --Brian
>>
>> "David Erickson" <derickso@stanford.edu> wrote in message
>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>> Shashidhar Shashidhar wrote:
>>>> Hi,
>>>>
>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>> what should we do here. When can this happen and how to come out of 
>>>> this
>>>> condition.
>>>>
>>>> Thanks,
>>>> Shashidhar.
>>>
>>> reading from the client or server?
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: valgrind errors
Date: Thu, 18 Jan 2007 16:08:15 -0800
Lines: 87
Distribution: su
Message-ID: <eop22e$oeo$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169165198 25048 127.0.0.1 (19 Jan 2007 00:06:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11102

When I run my proxy with valgrind I get the following errors. Can I ignore 
these? From what I can tell, this has nothing to do with my code

==7650== Conditional jump or move depends on uninitialised value(s)
==7650==    at 0x40104FE: (within /lib/ld-2.3.6.so)
==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
==7650==
==7650== Conditional jump or move depends on uninitialised value(s)
==7650==    at 0x4010509: (within /lib/ld-2.3.6.so)
==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
==7650==
==7650== Conditional jump or move depends on uninitialised value(s)
==7650==    at 0x4010514: (within /lib/ld-2.3.6.so)
==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
==7650==
==7650== Conditional jump or move depends on uninitialised value(s)
==7650==    at 0x4010671: (within /lib/ld-2.3.6.so)
==7650==    by 0x4006718: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
==7650==
==7650== Invalid read of size 8
==7650==    at 0x4010664: (within /lib/ld-2.3.6.so)
==7650==    by 0x40089BC: (within /lib/ld-2.3.6.so)
==7650==    by 0x4004DF3: (within /lib/ld-2.3.6.so)
==7650==    by 0x4006612: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==  Address 0x4D586D8 is 16 bytes inside a block of size 23 alloc'd
==7650==    at 0x4A19A16: malloc (vg_replace_malloc.c:149)
==7650==    by 0x4006A00: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Store-and-forward delay
Date: Thu, 18 Jan 2007 16:21:27 -0800
Lines: 7
Distribution: su
Message-ID: <eop2vq$pan$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169166138 25943 171.64.74.36 (19 Jan 2007 00:22:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11103

Prof. McKeown said in class that the store-and-forward delay is
negligible. But isn't that delay equal to the transmission delay? And if
we are considering the transmission delay, shouldn't we then consider
the store-and-forward delay?

Thanks,
Jad.
.

Path: shelby.stanford.edu!xenon.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@xenon.Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Sending error code back
Date: Thu, 18 Jan 2007 16:30:07 -0800
Lines: 52
Distribution: su
Message-ID: <Pine.LNX.4.62.0701181627500.2601@xenon.Stanford.EDU>
References: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU>
 <C1D54333.771C%jpettit@stanford.edu> <Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU>
NNTP-Posting-Host: xenon.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Trace: news.Stanford.EDU 1169166608 26669 171.64.66.201 (19 Jan 2007 00:30:08 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11104

After reading the error output, I found the error line is caused by line 
54 in the proxy_grader.py, which is the

direct_file = urllib.urlopen(pub_urls[n])

that is failing which is telling me that it's the grader itself couldn't 
open a socket connection to a bad address that I passed in. Can someone 
tell me whether the grader script can handle a url like "http://error/", 
because it seems to me the grader script can't handle it.

On Thu, 18 Jan 2007, Ryan Chen wrote:

> Yes, I am sure iis written through, I checked the number of bytes return by 
> the write() call, and it equals the number of chars in my string.
>
> Also, what do you mean by "it doens't seem like you've written enough data to 
> require it"? What is this "required it"? Require what?
>
> Thanks.
>
>
> On Thu, 18 Jan 2007, Justin Pettit wrote:
>
>> Are you sure the write completed?  It doesn't seem like you've written
>> enough data to require it, but you may need to call write() multiple times
>> to completely send your data.
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 3:08 PM, in article
>> Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU, "Ryan Chen"
>> <ryanchen@xenon.Stanford.EDU> wrote:
>> 
>>> For a bad request from the client, I am trying to send "HTTP/1.0 400 Bad
>>> Request\r\n\r\n" back to the client via the socket with the client, but
>>> once I close the socket, it gives me a socket error from the grader
>>> script:
>>> 
>>> IOError: [Errno socket error] (-2, 'Name or service not known')
>>> 
>>> Any clue why this is happening? If I send the message back to the client,
>>> but "don't" close the socket to the client, then this message won't
>>> appear, but the process just hangs, so it seems to me the client is still
>>> trying to read the socket somehow even though I sent a bad reqest response
>>> back......
>>> 
>>> Thanks for any answer.
>> 
>> 
>> 
>
.

Path: shelby.stanford.edu!not-for-mail
From: "Derek Schumacher" <dschumac@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 16:41:26 -0800
Lines: 85
Distribution: su
Message-ID: <eop44m$qno$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169167318 27384 127.0.0.1 (19 Jan 2007 00:41:58 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11105

For some reason I'm never seeing read() return a zero value when the number 
of bytes sent by the client and read in by read() is less than the size of 
the buffer I've supplied in the read() call.  Should I expect a single 
additional call to read() to return zero after the initial one returns a 
positive value?

Thanks,
Derek


"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D4EE4D.76C2%jpettit@stanford.edu...
> The best way to prevent blocking is to use the system call "select" or
> "poll" to determine whether there is data to be read.  You can also mark 
> the
> socket as non-blocking.  However, you shouldn't need to do either of these
> for this assignment.
>
> As David mentioned earlier, make sure that you don't immediately try to
> read() again after getting a zero return value, otherwise you'll block.
>
> --Justin
>
>
> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
> Gupta" <dineshg@Stanford.EDU> wrote:
>
>> Hi,
>>
>> I'm also seeing this problem when I configured firefox to use my proxy.
>> It's stuck in read while reading from the remote server(yahoo). It
>> worked fine with cnn though. So it doesn't happen always but very
>> annoying when it happens. Please let me know how to come out of this read
>> call.
>>
>> Thanks,
>> Dinesh
>>
>>
>>
>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>> I am runninng into the same problem with my proxy, I don't get a 
>>> response
>>> from the server.  I show that I connect just fine using serive name of 
>>> www
>>> on port 80.
>>
>>> As a check I have run the server.c and setup a server with a port of 
>>> 8001.
>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a 
>>> message
>>> to localhost on port 8001, saw my message reach the server and then get 
>>> a
>>> response.
>>
>>> I'm starting to think that there is something blocking the returns of 
>>> the
>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and 
>>> then
>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show. 
>>> Do I
>>> need to somehow mimic this to get my proxy to read the data?
>>
>>> --Brian
>>
>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>> Shashidhar Shashidhar wrote:
>>>>> Hi,
>>>>>
>>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>>> what should we do here. When can this happen and how to come out of 
>>>>> this
>>>>> condition.
>>>>>
>>>>> Thanks,
>>>>> Shashidhar.
>>>>
>>>> reading from the client or server?
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Sending error code back
Date: Thu, 18 Jan 2007 16:46:28 -0800
Lines: 65
Distribution: su
Message-ID: <eop4gd$qo0$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU> <C1D54333.771C%jpettit@stanford.edu> <Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU> <Pine.LNX.4.62.0701181627500.2601@xenon.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169167693 27392 171.64.74.54 (19 Jan 2007 00:48:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.62.0701181627500.2601@xenon.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11106

No- the script is expecting that the URLs in the URL array will be valid 
hosts.  The script that was posted will likely do something odd or break 
if a non-existant host is added to the URL list.

Clay

Ryan Chen wrote:
> After reading the error output, I found the error line is caused by line 
> 54 in the proxy_grader.py, which is the
> 
> direct_file = urllib.urlopen(pub_urls[n])
> 
> that is failing which is telling me that it's the grader itself couldn't 
> open a socket connection to a bad address that I passed in. Can someone 
> tell me whether the grader script can handle a url like "http://error/", 
> because it seems to me the grader script can't handle it.
> 
> On Thu, 18 Jan 2007, Ryan Chen wrote:
> 
>> Yes, I am sure iis written through, I checked the number of bytes 
>> return by the write() call, and it equals the number of chars in my 
>> string.
>>
>> Also, what do you mean by "it doens't seem like you've written enough 
>> data to require it"? What is this "required it"? Require what?
>>
>> Thanks.
>>
>>
>> On Thu, 18 Jan 2007, Justin Pettit wrote:
>>
>>> Are you sure the write completed?  It doesn't seem like you've written
>>> enough data to require it, but you may need to call write() multiple 
>>> times
>>> to completely send your data.
>>>
>>> --Justin
>>>
>>>
>>> On 1/18/07 3:08 PM, in article
>>> Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU, "Ryan Chen"
>>> <ryanchen@xenon.Stanford.EDU> wrote:
>>>
>>>> For a bad request from the client, I am trying to send "HTTP/1.0 400 
>>>> Bad
>>>> Request\r\n\r\n" back to the client via the socket with the client, but
>>>> once I close the socket, it gives me a socket error from the grader
>>>> script:
>>>>
>>>> IOError: [Errno socket error] (-2, 'Name or service not known')
>>>>
>>>> Any clue why this is happening? If I send the message back to the 
>>>> client,
>>>> but "don't" close the socket to the client, then this message won't
>>>> appear, but the process just hangs, so it seems to me the client is 
>>>> still
>>>> trying to read the socket somehow even though I sent a bad reqest 
>>>> response
>>>> back......
>>>>
>>>> Thanks for any answer.
>>>
>>>
>>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: "Jin Wang" <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Parsing response
Date: Fri, 19 Jan 2007 01:02:17 -0500
Lines: 13
Distribution: su
Message-ID: <eop5cs$s09$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169168604 28681 127.0.0.1 (19 Jan 2007 01:03:24 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Xref: shelby.stanford.edu su.class.cs244a:11107

How much parsing/validation of the response from a web server is necessary?

1) Do we need to check syntax of the status line and headers?
2) To whom (client or server or both) do we issue the error messages?
3) What should the error codes be?

Also, what phone number can remote SCPD students use to reach TA's during
office hours?

Thanks,
Jin


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Sending error code back
Date: Thu, 18 Jan 2007 17:09:30 -0800
Lines: 51
Distribution: su
Message-ID: <C1D55A4A.7736%jpettit@stanford.edu>
References: <Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU> <C1D54333.771C%jpettit@stanford.edu> <Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169168971 28855 127.0.0.1 (19 Jan 2007 01:09:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Sending error code back
Thread-Index: Acc7ZnijtynjCKdZEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11108

I meant that you hadn't written very much data, so it's unlikely you
wouldn't be able to send it in one call to write().

--Justin


On 1/18/07 3:40 PM, in article
Pine.LNX.4.62.0701181538530.24805@xenon.Stanford.EDU, "Ryan Chen"
<ryanchen@xenon.Stanford.EDU> wrote:

> Yes, I am sure iis written through, I checked the number of bytes return
> by the write() call, and it equals the number of chars in my string.
> 
> Also, what do you mean by "it doens't seem like you've written enough data
> to require it"? What is this "required it"? Require what?
> 
> Thanks.
> 
> 
> On Thu, 18 Jan 2007, Justin Pettit wrote:
> 
>> Are you sure the write completed?  It doesn't seem like you've written
>> enough data to require it, but you may need to call write() multiple times
>> to completely send your data.
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 3:08 PM, in article
>> Pine.LNX.4.62.0701181504050.29823@xenon.Stanford.EDU, "Ryan Chen"
>> <ryanchen@xenon.Stanford.EDU> wrote:
>> 
>>> For a bad request from the client, I am trying to send "HTTP/1.0 400 Bad
>>> Request\r\n\r\n" back to the client via the socket with the client, but
>>> once I close the socket, it gives me a socket error from the grader
>>> script:
>>> 
>>> IOError: [Errno socket error] (-2, 'Name or service not known')
>>> 
>>> Any clue why this is happening? If I send the message back to the client,
>>> but "don't" close the socket to the client, then this message won't
>>> appear, but the process just hangs, so it seems to me the client is still
>>> trying to read the socket somehow even though I sent a bad reqest response
>>> back......
>>> 
>>> Thanks for any answer.
>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Thu, 18 Jan 2007 17:11:45 -0800
Lines: 36
Distribution: su
Message-ID: <C1D55AD1.7737%jpettit@stanford.edu>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU> <eohufb$k3i$1@news.Stanford.EDU> <eomqct$c0v$1@news.Stanford.EDU> <eoms00$dcg$4@news.Stanford.EDU> <eop15e$nek$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169169108 29225 127.0.0.1 (19 Jan 2007 01:11:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: How much to read()
Thread-Index: Acc7ZskaB4FgYadaEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11109

Yes, growing a buffer is a good strategy.  Definitely don't just allocate an
SSIZE_MAX buffer right off the bat.

--Justin


On 1/18/07 3:50 PM, in article eop15e$nek$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> So we shouldn't allocate a buffer of size SSIZE_MAX as it seems to be
> defined as something big (LONG_MAX) correct? Shouldn't we allocate a
> temporary read buffer in the range of something like [1024, 10240], pass
> that buffer to recv, and copy from it to the real data buffer which is
> grown/realloced as needed?
> 
> David Gobaud
> 
> "David Erickson" <derickso@stanford.edu> wrote in message
> news:eoms00$dcg$4@news.Stanford.EDU...
>> Alicia Chen wrote:
>>> Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" compile
>>> error, which doesn't go away even when I include <limits.h> or
>>> <sys/limits.h>
>>> 
>>> Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or
>>> something exceedingly large, and I don't really want to allocate a buffer
>>> that big.  Am I wrong on any of these points?  We can't exactly allocate
>>> a buffer that big...
>> 
>> Check out the function realloc.
>> 
>> -David 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 17:36:27 -0800
Lines: 72
Distribution: su
Message-ID: <C1D5609B.773D%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <C1D4ED4D.76BE%jpettit@stanford.edu> <eop18i$nic$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169170592 423 127.0.0.1 (19 Jan 2007 01:36:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7ajxxeyVlK6ddEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11110

The Myths are the best systems to do your work on, since I think that's
where we're going to do the grading.

--Justin


On 1/18/07 3:52 PM, in article eop18i$nic$1@news.Stanford.EDU, "Brian
Thompson" <Brian.C.Thompson@Boeing.com> wrote:

> Yeah, I use PUTTY to get into myth.stanford.edu and run Exceed for an X
> windows.  Should I be on something else?
> 
> --Brian
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D4ED4D.76BE%jpettit@stanford.edu...
>> You definitely should not send three "\r\n" to indicate the end of a
>> request--that's contrary to the RFC.  I just connected to www.yahoo.com
>> over
>> a dozen times, and never had to hit enter more than twice.  Are you
>> running
>> your tests on one of the Myths?
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 1:19 AM, in article eone2e$42e$1@news.Stanford.EDU, "Brian
>> Thompson" <Brian.C.Thompson@Boeing.com> wrote:
>> 
>>> I am runninng into the same problem with my proxy, I don't get a response
>>> from the server.  I show that I connect just fine using serive name of
>>> www
>>> on port 80.
>>> 
>>> As a check I have run the server.c and setup a server with a port of
>>> 8001.
>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>> message
>>> to localhost on port 8001, saw my message reach the server and then get a
>>> response.
>>> 
>>> I'm starting to think that there is something blocking the returns of the
>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and
>>> then
>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.  Do
>>> I
>>> need to somehow mimic this to get my proxy to read the data?
>>> 
>>> --Brian
>>> 
>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>> Shashidhar Shashidhar wrote:
>>>>> Hi,
>>>>> 
>>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>>> what should we do here. When can this happen and how to come out of
>>>>> this
>>>>> condition.
>>>>> 
>>>>> Thanks,
>>>>> Shashidhar.
>>>> 
>>>> reading from the client or server?
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 17:39:28 -0800
Lines: 96
Distribution: su
Message-ID: <C1D56150.773F%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169170771 563 127.0.0.1 (19 Jan 2007 01:39:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7aqhU5vqNLKddEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11111

Yes, you should keep calling read() until you receive a 0 (no more data) or
a -1 (there was an error).

--Justin


On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
Schumacher" <dschumac@stanford.edu> wrote:

> For some reason I'm never seeing read() return a zero value when the number
> of bytes sent by the client and read in by read() is less than the size of
> the buffer I've supplied in the read() call.  Should I expect a single
> additional call to read() to return zero after the initial one returns a
> positive value?
> 
> Thanks,
> Derek
> 
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>> The best way to prevent blocking is to use the system call "select" or
>> "poll" to determine whether there is data to be read.  You can also mark
>> the
>> socket as non-blocking.  However, you shouldn't need to do either of these
>> for this assignment.
>> 
>> As David mentioned earlier, make sure that you don't immediately try to
>> read() again after getting a zero return value, otherwise you'll block.
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
>> Gupta" <dineshg@Stanford.EDU> wrote:
>> 
>>> Hi,
>>> 
>>> I'm also seeing this problem when I configured firefox to use my proxy.
>>> It's stuck in read while reading from the remote server(yahoo). It
>>> worked fine with cnn though. So it doesn't happen always but very
>>> annoying when it happens. Please let me know how to come out of this read
>>> call.
>>> 
>>> Thanks,
>>> Dinesh
>>> 
>>> 
>>> 
>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>> I am runninng into the same problem with my proxy, I don't get a
>>>> response
>>>> from the server.  I show that I connect just fine using serive name of
>>>> www
>>>> on port 80.
>>> 
>>>> As a check I have run the server.c and setup a server with a port of
>>>> 8001.
>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>> message
>>>> to localhost on port 8001, saw my message reach the server and then get
>>>> a
>>>> response.
>>> 
>>>> I'm starting to think that there is something blocking the returns of
>>>> the
>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 and
>>>> then
>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.
>>>> Do I
>>>> need to somehow mimic this to get my proxy to read the data?
>>> 
>>>> --Brian
>>> 
>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>> Shashidhar Shashidhar wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>>>> what should we do here. When can this happen and how to come out of
>>>>>> this
>>>>>> condition.
>>>>>> 
>>>>>> Thanks,
>>>>>> Shashidhar.
>>>>> 
>>>>> reading from the client or server?
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: valgrind errors
Date: Thu, 18 Jan 2007 17:58:18 -0800
Lines: 98
Distribution: su
Message-ID: <C1D565BA.7740%jpettit@stanford.edu>
References: <eop22e$oeo$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169171902 1586 127.0.0.1 (19 Jan 2007 01:58:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: valgrind errors
Thread-Index: Acc7bUnciG3jvadgEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11112

Those are fine.  You can probably switch to gethotbyname_r to make them go
away, but we won't ding you for them.

--Justin


On 1/18/07 4:08 PM, in article eop22e$oeo$1@news.Stanford.EDU, "Riju
Kallivalappil" <riju@stanford.edu> wrote:

> When I run my proxy with valgrind I get the following errors. Can I ignore
> these? From what I can tell, this has nothing to do with my code
> 
> ==7650== Conditional jump or move depends on uninitialised value(s)
> ==7650==    at 0x40104FE: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
> ==7650==
> ==7650== Conditional jump or move depends on uninitialised value(s)
> ==7650==    at 0x4010509: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
> ==7650==
> ==7650== Conditional jump or move depends on uninitialised value(s)
> ==7650==    at 0x4010514: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4006581: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
> ==7650==
> ==7650== Conditional jump or move depends on uninitialised value(s)
> ==7650==    at 0x4010671: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4006718: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
> ==7650==
> ==7650== Invalid read of size 8
> ==7650==    at 0x4010664: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x40089BC: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4004DF3: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4006612: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==  Address 0x4D586D8 is 16 bytes inside a block of size 23 alloc'd
> ==7650==    at 0x4A19A16: malloc (vg_replace_malloc.c:149)
> ==7650==    by 0x4006A00: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C1751B: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C180C9: _dl_open (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4C19627: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x400B13F: (within /lib/ld-2.3.6.so)
> ==7650==    by 0x4C196D2: __libc_dlopen_mode (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF50F1: __nss_lookup_function (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF5253: (within /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF9E70: gethostbyname_r (in /lib/libc-2.3.6.so)
> ==7650==    by 0x4BF96BE: gethostbyname (in /lib/libc-2.3.6.so)
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing response
Date: Thu, 18 Jan 2007 18:04:36 -0800
Lines: 24
Distribution: su
Message-ID: <C1D56734.7745%jpettit@stanford.edu>
References: <eop5cs$s09$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169172284 2026 127.0.0.1 (19 Jan 2007 02:04:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Parsing response
Thread-Index: Acc7bisqaZjEMqdhEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11113

> 1) Do we need to check syntax of the status line and headers?

See my post from earlier today titled "Re: Parsing request".

> 2) To whom (client or server or both) do we issue the error messages?

You only need to return error messages to the client.  There isn't really a
way to send error messages to the server.

> 3) What should the error codes be?

Look through the RFC.  Focus on 400 and 500.
 
> Also, what phone number can remote SCPD students use to reach TA's during
> office hours?

We're trying to figure that out, since we don't have phone service in the
labs.  If you're in the area, I tried to position my office hours so that
they'd be usable by SCPD students.

--Justin
 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission
Date: Thu, 18 Jan 2007 18:22:17 -0800
Lines: 28
Distribution: su
Message-ID: <eop9u2$2q3$1@news.Stanford.EDU>
References: <eoogd8$8kk$1@news.Stanford.EDU> <eoolvc$dei$1@news.Stanford.EDU> <eooof8$frb$1@news.Stanford.EDU> <eooto3$kb9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169173250 2883 127.0.0.1 (19 Jan 2007 02:20:50 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11114

I too am getting the same error. Is there any other way to submit the 
tarball?

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eooto3$kb9$1@news.Stanford.EDU...
> Try clearing your browser cache and trying the link again.  Also, make 
> sure that your browser is accepting cookies from both webauth.stanford.edu 
> and www.stanford.edu.
>
> Clay
>
> Alex wrote:
>> After I authenticate I see this issue.
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:eoolvc$dei$1@news.Stanford.EDU...
>>> Alex wrote:
>>>> When I tried to submit the web proxy on the course website I get "You 
>>>> do not have permission to access the requested directory." Why is this 
>>>> happening?
>>> Are you seeing this error as soon as you click on the 'Submit an 
>>> Assignment' link from the front page, or only after you press the submit 
>>> button on the submissions page?  Are you able to authenticate with 
>>> WebAuth?
>>>
>>> Clay
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Do we need to handle simple request/response?
Date: Thu, 18 Jan 2007 18:31:52 -0800
Lines: 1
Distribution: su
Message-ID: <eopaiu$33r$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169173918 3195 127.0.0.1 (19 Jan 2007 02:31:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11115

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Do we need to handle simple request/response?
Date: Thu, 18 Jan 2007 18:39:09 -0800
Lines: 11
Distribution: su
Message-ID: <C1D56F4D.7750%jpettit@stanford.edu>
References: <eopaiu$33r$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169174353 3846 127.0.0.1 (19 Jan 2007 02:39:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Do we need to handle simple request/response?
Thread-Index: Acc7cv7FPVWkVadmEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11116

Yes, you need to support HTTP/1.0 as defined in the RFC.

--Justin


On 1/18/07 6:31 PM, in article eopaiu$33r$2@news.Stanford.EDU, "Yuliya
Sarkisyan" <yuliya@stanford.edu> wrote:

> Thanks.


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ANSI C struct?
Date: Fri, 19 Jan 2007 03:29:42 +0000 (UTC)
Organization: Your Company
Lines: 11
Distribution: su
Message-ID: <Xns98BCC651F8D7chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169177382 6494 128.12.22.217 (19 Jan 2007 03:29:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11117

is there struct in ANSI C???

i have 


proxy.c:12: error: 'proxyServerSide_t' undeclared (first use in this 
function)

even though i did declare it right before main.


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: what's going on???? // = error?
Date: Thu, 18 Jan 2007 19:51:55 -0800
Lines: 42
Distribution: su
Message-ID: <eopf7i$7ra$1@news.Stanford.EDU>
References: <Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103> <C1D5415D.7716%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169178674 8042 127.0.0.1 (19 Jan 2007 03:51:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11118

It is because of the -ansi (which is a requirement of the project).  I have 
heard that // comments were a part of C99 (and, also exciting, that scoped 
variables might join C sometime in the 21st century); however, gcc acts like 
it does not.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D5415D.7716%jpettit@stanford.edu...
> That's a C++ comment.  Try this:
>
>    int x;  /* x */
>
> Some compilers are sticklers about the C code using C++ comments.
>
> --Justin
>
>
> On 1/18/07 3:19 PM, in article
> Xns98BC9BF29A199chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
> <chunkaiw@stanford.edu> wrote:
>
>> i'm going crazy...
>>
>> all i have is
>>
>> void main()
>> {
>> int x;     //x
>> }
>>
>> and this doesn't compile.
>>
>> but if i remove "//x" it compiles just fine...
>>
>> i'm using myth
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ANSI C struct?
Date: Thu, 18 Jan 2007 19:59:21 -0800
Lines: 43
Distribution: su
Message-ID: <eopflh$86g$1@news.Stanford.EDU>
References: <Xns98BCC651F8D7chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1169179121 8400 127.0.0.1 (19 Jan 2007 03:58:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11119

Both enums and structs have to be preceded with their type qualifiers (they 
are like namespace identifiers).
IOW, with
struct Fred_ {
    int toes;
    int fingers;
};

You have to declare an instance of Fred_ like so:
struct Fred_ dishwasher;

If you do a typedef (typedef Fred_ Fred) you do not need 'struct' preceding 
the instance declaration.

That is why you commonly see:
typedef struct Fred_ {
    int toes;
    int fingers;
} Fred;
in C code.

It is so common, C++ removed the requirement.

Sincerely,
Randy Jennings

The squirrels are your friends!

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98BCC651F8D7chunkaiwstanfordedu@171.64.14.103...
> is there struct in ANSI C???
>
> i have
>
>
> proxy.c:12: error: 'proxyServerSide_t' undeclared (first use in this
> function)
>
> even though i did declare it right before main.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How much to read()
Date: Thu, 18 Jan 2007 20:04:27 -0800
Lines: 55
Distribution: su
Message-ID: <eopfv3$8hl$1@news.Stanford.EDU>
References: <Pine.LNX.4.62.0701152056360.8222@xenon.Stanford.EDU> <eohufb$k3i$1@news.Stanford.EDU> <eomqct$c0v$1@news.Stanford.EDU> <eoms00$dcg$4@news.Stanford.EDU> <eop15e$nek$1@news.Stanford.EDU> <C1D55AD1.7737%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169179427 8757 127.0.0.1 (19 Jan 2007 04:03:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11120

Actually, growing the buffer is not a good strategy, but it is probably 
acceptable within the constraints of the problem.  It can lead to horrible 
fragmentation of memory, and is a performance penalty.  Picking a fixed size 
and relaying chunks (cut-through proxying :-) ) is a much better approach 
(not required by the assignment)!

Sincerely,
Randy Jennings

The squirrels are your friends!

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D55AD1.7737%jpettit@stanford.edu...
> Yes, growing a buffer is a good strategy.  Definitely don't just allocate 
> an
> SSIZE_MAX buffer right off the bat.
>
> --Justin
>
>
> On 1/18/07 3:50 PM, in article eop15e$nek$1@news.Stanford.EDU, "David
> Gobaud" <gobaudd@stanford.edu> wrote:
>
>> So we shouldn't allocate a buffer of size SSIZE_MAX as it seems to be
>> defined as something big (LONG_MAX) correct? Shouldn't we allocate a
>> temporary read buffer in the range of something like [1024, 10240], pass
>> that buffer to recv, and copy from it to the real data buffer which is
>> grown/realloced as needed?
>>
>> David Gobaud
>>
>> "David Erickson" <derickso@stanford.edu> wrote in message
>> news:eoms00$dcg$4@news.Stanford.EDU...
>>> Alicia Chen wrote:
>>>> Firstly, when I use SSIZE_MAX, it gives an "SSIZE_MAX undefined" 
>>>> compile
>>>> error, which doesn't go away even when I include <limits.h> or
>>>> <sys/limits.h>
>>>>
>>>> Also, from what I can glean, SSIZE_MAX is equivalent to INT_MAX, or
>>>> something exceedingly large, and I don't really want to allocate a 
>>>> buffer
>>>> that big.  Am I wrong on any of these points?  We can't exactly 
>>>> allocate
>>>> a buffer that big...
>>>
>>> Check out the function realloc.
>>>
>>> -David
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ANSI C struct?
Date: Fri, 19 Jan 2007 04:15:48 +0000 (UTC)
Organization: Your Company
Lines: 1
Distribution: su
Message-ID: <Xns98BCCE22EE318chunkaiwstanfordedu@171.64.14.103>
References: <Xns98BCC651F8D7chunkaiwstanfordedu@171.64.14.103> <eopflh$86g$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169180148 9259 128.12.22.217 (19 Jan 2007 04:15:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11121

perfect. thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: "Derek Schumacher" <dschumac@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 20:20:15 -0800
Lines: 115
Distribution: su
Message-ID: <eopgut$9hf$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU> <C1D56150.773F%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169180445 9775 127.0.0.1 (19 Jan 2007 04:20:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11122

Any reason why I may not be seeing this happen?  I'm reasonably sure I'm 
only doing two calls to read, one that returns the number of bytes read 
initially (a non-zero positive number) and the second one which appears to 
block.

Thanks,
Derek

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D56150.773F%jpettit@stanford.edu...
> Yes, you should keep calling read() until you receive a 0 (no more data) 
> or
> a -1 (there was an error).
>
> --Justin
>
>
> On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
> Schumacher" <dschumac@stanford.edu> wrote:
>
>> For some reason I'm never seeing read() return a zero value when the 
>> number
>> of bytes sent by the client and read in by read() is less than the size 
>> of
>> the buffer I've supplied in the read() call.  Should I expect a single
>> additional call to read() to return zero after the initial one returns a
>> positive value?
>>
>> Thanks,
>> Derek
>>
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>>> The best way to prevent blocking is to use the system call "select" or
>>> "poll" to determine whether there is data to be read.  You can also mark
>>> the
>>> socket as non-blocking.  However, you shouldn't need to do either of 
>>> these
>>> for this assignment.
>>>
>>> As David mentioned earlier, make sure that you don't immediately try to
>>> read() again after getting a zero return value, otherwise you'll block.
>>>
>>> --Justin
>>>
>>>
>>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
>>> Gupta" <dineshg@Stanford.EDU> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm also seeing this problem when I configured firefox to use my proxy.
>>>> It's stuck in read while reading from the remote server(yahoo). It
>>>> worked fine with cnn though. So it doesn't happen always but very
>>>> annoying when it happens. Please let me know how to come out of this 
>>>> read
>>>> call.
>>>>
>>>> Thanks,
>>>> Dinesh
>>>>
>>>>
>>>>
>>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>>> I am runninng into the same problem with my proxy, I don't get a
>>>>> response
>>>>> from the server.  I show that I connect just fine using serive name of
>>>>> www
>>>>> on port 80.
>>>>
>>>>> As a check I have run the server.c and setup a server with a port of
>>>>> 8001.
>>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>>> message
>>>>> to localhost on port 8001, saw my message reach the server and then 
>>>>> get
>>>>> a
>>>>> response.
>>>>
>>>>> I'm starting to think that there is something blocking the returns of
>>>>> the
>>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80 
>>>>> and
>>>>> then
>>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.
>>>>> Do I
>>>>> need to somehow mimic this to get my proxy to read the data?
>>>>
>>>>> --Brian
>>>>
>>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>>> Shashidhar Shashidhar wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>>>>> what should we do here. When can this happen and how to come out of
>>>>>>> this
>>>>>>> condition.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Shashidhar.
>>>>>>
>>>>>> reading from the client or server?
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: inet_aton
Date: Fri, 19 Jan 2007 05:57:41 +0000 (UTC)
Organization: Your Company
Lines: 12
Distribution: su
Message-ID: <Xns98BCDF68FC373chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169186261 13898 128.12.22.217 (19 Jan 2007 05:57:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11123

i have:

inet_aton("209.131.36.158", &(proxyClient.serverAddr.sin_addr) );

printf(inet_ntoa(proxyClient.serverAddr.sin_addr)); 



but it prints 209.131.36.1580


why? where did the extra 0 come from?
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxy.c:40: warning: implicit declaration of function
Date: Fri, 19 Jan 2007 06:45:09 +0000 (UTC)
Organization: Your Company
Lines: 10
Distribution: su
Message-ID: <Xns98BCE7752A0A2chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169189109 16173 128.12.22.217 (19 Jan 2007 06:45:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11124

anyone know how to solve: 


proxy.c:40: warning: implicit declaration of function 'read'
proxy.c:47: warning: implicit declaration of function 'bzero'
proxy.c:50: warning: implicit declaration of function 'inet_aton'
proxy.c:51: warning: implicit declaration of function 'memset'


? thanks : )
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on Referencing
Date: Thu, 18 Jan 2007 23:11:32 -0800
Lines: 7
Distribution: su
Message-ID: <paun-071956.23113218012007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1169190693 17510 128.12.135.184 (19 Jan 2007 07:11:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11125

 I have code that looks very similar to the code presented in one of the 
books as well as the referenced website, and i would like to acknowledge 
this code 'inspiration'.  On top of this, i have talked about the high 
level project issues with other classmates.  

 Just to make sure, the specifics of the above need to go in our README, 
correct?
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: inet_aton
Date: Thu, 18 Jan 2007 23:15:40 -0800
Lines: 23
Distribution: su
Message-ID: <C1D5B01C.7784%jpettit@stanford.edu>
References: <Xns98BCDF68FC373chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169190942 18012 127.0.0.1 (19 Jan 2007 07:15:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: inet_aton
Thread-Index: Acc7mZ/G3hmqnqeMEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11126

I don't know.  I couldn't reproduce on the Myths.

--Justin


On 1/18/07 9:57 PM, in article
Xns98BCDF68FC373chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> i have:
> 
> inet_aton("209.131.36.158", &(proxyClient.serverAddr.sin_addr) );
> 
> printf(inet_ntoa(proxyClient.serverAddr.sin_addr));
> 
> 
> 
> but it prints 209.131.36.1580
> 
> 
> why? where did the extra 0 come from?


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on Referencing
Date: Thu, 18 Jan 2007 23:20:54 -0800
Lines: 20
Distribution: su
Message-ID: <C1D5B156.778A%jpettit@stanford.edu>
References: <paun-071956.23113218012007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169191257 18245 127.0.0.1 (19 Jan 2007 07:20:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Question on Referencing
Thread-Index: Acc7mlrvmW7W+qeNEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11127

Yes, that's exactly where it should go.  I would recommend mentioning your
"inspiration" in a comment above the code, too.  That way, no one reading
the code without immediate access to the README will get concerned.

--Justin


On 1/18/07 11:11 PM, in article
paun-071956.23113218012007@nntp.stanford.edu, "Filip Paun"
<paun@stanford.edu> wrote:

>  I have code that looks very similar to the code presented in one of the
> books as well as the referenced website, and i would like to acknowledge
> this code 'inspiration'.  On top of this, i have talked about the high
> level project issues with other classmates.
> 
>  Just to make sure, the specifics of the above need to go in our README,
> correct?


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 23:27:10 -0800
Lines: 128
Distribution: su
Message-ID: <C1D5B2CE.778C%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU> <C1D56150.773F%jpettit@stanford.edu> <eopgut$9hf$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169191633 18491 127.0.0.1 (19 Jan 2007 07:27:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7mzsMeZAjOKeOEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11128

Are you seeing this problem from the web server?  Make sure that you're
sending it HTTP/1.0 and not using keep-alive extension.  If so, it seems
like it's not closing its connection.  Are you seeing this when you type in
a request manually, using the grading script, or Firefox?

--Justin
 

On 1/18/07 8:20 PM, in article eopgut$9hf$1@news.Stanford.EDU, "Derek
Schumacher" <dschumac@stanford.edu> wrote:

> Any reason why I may not be seeing this happen?  I'm reasonably sure I'm
> only doing two calls to read, one that returns the number of bytes read
> initially (a non-zero positive number) and the second one which appears to
> block.
> 
> Thanks,
> Derek
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D56150.773F%jpettit@stanford.edu...
>> Yes, you should keep calling read() until you receive a 0 (no more data)
>> or
>> a -1 (there was an error).
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
>> Schumacher" <dschumac@stanford.edu> wrote:
>> 
>>> For some reason I'm never seeing read() return a zero value when the
>>> number
>>> of bytes sent by the client and read in by read() is less than the size
>>> of
>>> the buffer I've supplied in the read() call.  Should I expect a single
>>> additional call to read() to return zero after the initial one returns a
>>> positive value?
>>> 
>>> Thanks,
>>> Derek
>>> 
>>> 
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>>>> The best way to prevent blocking is to use the system call "select" or
>>>> "poll" to determine whether there is data to be read.  You can also mark
>>>> the
>>>> socket as non-blocking.  However, you shouldn't need to do either of
>>>> these
>>>> for this assignment.
>>>> 
>>>> As David mentioned earlier, make sure that you don't immediately try to
>>>> read() again after getting a zero return value, otherwise you'll block.
>>>> 
>>>> --Justin
>>>> 
>>>> 
>>>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
>>>> Gupta" <dineshg@Stanford.EDU> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm also seeing this problem when I configured firefox to use my proxy.
>>>>> It's stuck in read while reading from the remote server(yahoo). It
>>>>> worked fine with cnn though. So it doesn't happen always but very
>>>>> annoying when it happens. Please let me know how to come out of this
>>>>> read
>>>>> call.
>>>>> 
>>>>> Thanks,
>>>>> Dinesh
>>>>> 
>>>>> 
>>>>> 
>>>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>>>> I am runninng into the same problem with my proxy, I don't get a
>>>>>> response
>>>>>> from the server.  I show that I connect just fine using serive name of
>>>>>> www
>>>>>> on port 80.
>>>>> 
>>>>>> As a check I have run the server.c and setup a server with a port of
>>>>>> 8001.
>>>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>>>> message
>>>>>> to localhost on port 8001, saw my message reach the server and then
>>>>>> get
>>>>>> a
>>>>>> response.
>>>>> 
>>>>>> I'm starting to think that there is something blocking the returns of
>>>>>> the
>>>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80
>>>>>> and
>>>>>> then
>>>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to show.
>>>>>> Do I
>>>>>> need to somehow mimic this to get my proxy to read the data?
>>>>> 
>>>>>> --Brian
>>>>> 
>>>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>>>> Shashidhar Shashidhar wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call and
>>>>>>>> what should we do here. When can this happen and how to come out of
>>>>>>>> this
>>>>>>>> condition.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Shashidhar.
>>>>>>> 
>>>>>>> reading from the client or server?
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Derek Schumacher" <dschumac@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 23:29:57 -0800
Lines: 150
Distribution: su
Message-ID: <eops2j$i9c$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU> <C1D56150.773F%jpettit@stanford.edu> <eopgut$9hf$1@news.Stanford.EDU> <C1D5B2CE.778C%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169191827 18732 127.0.0.1 (19 Jan 2007 07:30:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11129

I see this when simply taking the request in from the client when using the 
grading script.  I haven't tried any other methods as of yet.

Derek


"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D5B2CE.778C%jpettit@stanford.edu...
> Are you seeing this problem from the web server?  Make sure that you're
> sending it HTTP/1.0 and not using keep-alive extension.  If so, it seems
> like it's not closing its connection.  Are you seeing this when you type 
> in
> a request manually, using the grading script, or Firefox?
>
> --Justin
>
>
> On 1/18/07 8:20 PM, in article eopgut$9hf$1@news.Stanford.EDU, "Derek
> Schumacher" <dschumac@stanford.edu> wrote:
>
>> Any reason why I may not be seeing this happen?  I'm reasonably sure I'm
>> only doing two calls to read, one that returns the number of bytes read
>> initially (a non-zero positive number) and the second one which appears 
>> to
>> block.
>>
>> Thanks,
>> Derek
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1D56150.773F%jpettit@stanford.edu...
>>> Yes, you should keep calling read() until you receive a 0 (no more data)
>>> or
>>> a -1 (there was an error).
>>>
>>> --Justin
>>>
>>>
>>> On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
>>> Schumacher" <dschumac@stanford.edu> wrote:
>>>
>>>> For some reason I'm never seeing read() return a zero value when the
>>>> number
>>>> of bytes sent by the client and read in by read() is less than the size
>>>> of
>>>> the buffer I've supplied in the read() call.  Should I expect a single
>>>> additional call to read() to return zero after the initial one returns 
>>>> a
>>>> positive value?
>>>>
>>>> Thanks,
>>>> Derek
>>>>
>>>>
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>>>>> The best way to prevent blocking is to use the system call "select" or
>>>>> "poll" to determine whether there is data to be read.  You can also 
>>>>> mark
>>>>> the
>>>>> socket as non-blocking.  However, you shouldn't need to do either of
>>>>> these
>>>>> for this assignment.
>>>>>
>>>>> As David mentioned earlier, make sure that you don't immediately try 
>>>>> to
>>>>> read() again after getting a zero return value, otherwise you'll 
>>>>> block.
>>>>>
>>>>> --Justin
>>>>>
>>>>>
>>>>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
>>>>> Gupta" <dineshg@Stanford.EDU> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm also seeing this problem when I configured firefox to use my 
>>>>>> proxy.
>>>>>> It's stuck in read while reading from the remote server(yahoo). It
>>>>>> worked fine with cnn though. So it doesn't happen always but very
>>>>>> annoying when it happens. Please let me know how to come out of this
>>>>>> read
>>>>>> call.
>>>>>>
>>>>>> Thanks,
>>>>>> Dinesh
>>>>>>
>>>>>>
>>>>>>
>>>>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>>>>> I am runninng into the same problem with my proxy, I don't get a
>>>>>>> response
>>>>>>> from the server.  I show that I connect just fine using serive name 
>>>>>>> of
>>>>>>> www
>>>>>>> on port 80.
>>>>>>
>>>>>>> As a check I have run the server.c and setup a server with a port of
>>>>>>> 8001.
>>>>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>>>>> message
>>>>>>> to localhost on port 8001, saw my message reach the server and then
>>>>>>> get
>>>>>>> a
>>>>>>> response.
>>>>>>
>>>>>>> I'm starting to think that there is something blocking the returns 
>>>>>>> of
>>>>>>> the
>>>>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80
>>>>>>> and
>>>>>>> then
>>>>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to 
>>>>>>> show.
>>>>>>> Do I
>>>>>>> need to somehow mimic this to get my proxy to read the data?
>>>>>>
>>>>>>> --Brian
>>>>>>
>>>>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>>>>> Shashidhar Shashidhar wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call 
>>>>>>>>> and
>>>>>>>>> what should we do here. When can this happen and how to come out 
>>>>>>>>> of
>>>>>>>>> this
>>>>>>>>> condition.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Shashidhar.
>>>>>>>>
>>>>>>>> reading from the client or server?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing request
Date: Thu, 18 Jan 2007 23:33:29 -0800
Lines: 28
Distribution: su
Message-ID: <eops83$idj$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU> <C1D54107.7715%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169192004 18867 127.0.0.1 (19 Jan 2007 07:33:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1D54107.7715%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11130

If the response status line is not proper, then what should be done?

Thanks
Neelima

Justin Pettit wrote:
> Don't worry about parsing much of the request and response.  For the
> request, make sure that it makes sense, but you don't have to verify all the
> headers.  For the response, make sure that you get a proper response status
> line and then just pass everything else through unmodified.
> 
> --Justin
> 
> 
> On 1/18/07 12:26 PM, in article
> Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU, "Seung Hoon
> Choi" <shchoi@stanford.edu> wrote:
> 
>> Hi,
>>
>> How exact do we need to parse the request/response? Do I need to make sure
>> that requests and responses are exactly as defined in RFC documents?
>>
>>
>> Thanks,
>> -Seung
>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 23:39:06 -0800
Lines: 170
Distribution: su
Message-ID: <C1D5B59A.7793%jpettit@stanford.edu>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU> <C1D56150.773F%jpettit@stanford.edu> <eopgut$9hf$1@news.Stanford.EDU> <C1D5B2CE.778C%jpettit@stanford.edu> <eops2j$i9c$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169192348 19100 127.0.0.1 (19 Jan 2007 07:39:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Proxy process getting stuck in read() system call
Thread-Index: Acc7nOXRJCzeNqeQEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11131

Ahh.  I think this discussion started with a question about reading data
from the server, which is different, since it sends data and then closes the
connection.  When the connection is closed, the read() call return 0, when
there is no more data.

However, the client doesn't close the connection, since it still wants to
get a response back.  For this, you should read data in and look for
"\r\n\r\n"--the indicator that the request is completed.  At this point, you
will only ever write to the client's socket.

Does that make sense?

--Justin


On 1/18/07 11:29 PM, in article eops2j$i9c$1@news.Stanford.EDU, "Derek
Schumacher" <dschumac@stanford.edu> wrote:

> I see this when simply taking the request in from the client when using the
> grading script.  I haven't tried any other methods as of yet.
> 
> Derek
> 
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D5B2CE.778C%jpettit@stanford.edu...
>> Are you seeing this problem from the web server?  Make sure that you're
>> sending it HTTP/1.0 and not using keep-alive extension.  If so, it seems
>> like it's not closing its connection.  Are you seeing this when you type
>> in
>> a request manually, using the grading script, or Firefox?
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 8:20 PM, in article eopgut$9hf$1@news.Stanford.EDU, "Derek
>> Schumacher" <dschumac@stanford.edu> wrote:
>> 
>>> Any reason why I may not be seeing this happen?  I'm reasonably sure I'm
>>> only doing two calls to read, one that returns the number of bytes read
>>> initially (a non-zero positive number) and the second one which appears
>>> to
>>> block.
>>> 
>>> Thanks,
>>> Derek
>>> 
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1D56150.773F%jpettit@stanford.edu...
>>>> Yes, you should keep calling read() until you receive a 0 (no more data)
>>>> or
>>>> a -1 (there was an error).
>>>> 
>>>> --Justin
>>>> 
>>>> 
>>>> On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
>>>> Schumacher" <dschumac@stanford.edu> wrote:
>>>> 
>>>>> For some reason I'm never seeing read() return a zero value when the
>>>>> number
>>>>> of bytes sent by the client and read in by read() is less than the size
>>>>> of
>>>>> the buffer I've supplied in the read() call.  Should I expect a single
>>>>> additional call to read() to return zero after the initial one returns
>>>>> a
>>>>> positive value?
>>>>> 
>>>>> Thanks,
>>>>> Derek
>>>>> 
>>>>> 
>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>>>>>> The best way to prevent blocking is to use the system call "select" or
>>>>>> "poll" to determine whether there is data to be read.  You can also
>>>>>> mark
>>>>>> the
>>>>>> socket as non-blocking.  However, you shouldn't need to do either of
>>>>>> these
>>>>>> for this assignment.
>>>>>> 
>>>>>> As David mentioned earlier, make sure that you don't immediately try
>>>>>> to
>>>>>> read() again after getting a zero return value, otherwise you'll
>>>>>> block.
>>>>>> 
>>>>>> --Justin
>>>>>> 
>>>>>> 
>>>>>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, "Dinesh
>>>>>> Gupta" <dineshg@Stanford.EDU> wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I'm also seeing this problem when I configured firefox to use my
>>>>>>> proxy.
>>>>>>> It's stuck in read while reading from the remote server(yahoo). It
>>>>>>> worked fine with cnn though. So it doesn't happen always but very
>>>>>>> annoying when it happens. Please let me know how to come out of this
>>>>>>> read
>>>>>>> call.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Dinesh
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>>>>>> I am runninng into the same problem with my proxy, I don't get a
>>>>>>>> response
>>>>>>>> from the server.  I show that I connect just fine using serive name
>>>>>>>> of
>>>>>>>> www
>>>>>>>> on port 80.
>>>>>>> 
>>>>>>>> As a check I have run the server.c and setup a server with a port of
>>>>>>>> 8001.
>>>>>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>>>>>> message
>>>>>>>> to localhost on port 8001, saw my message reach the server and then
>>>>>>>> get
>>>>>>>> a
>>>>>>>> response.
>>>>>>> 
>>>>>>>> I'm starting to think that there is something blocking the returns
>>>>>>>> of
>>>>>>>> the
>>>>>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 80
>>>>>>>> and
>>>>>>>> then
>>>>>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to
>>>>>>>> show.
>>>>>>>> Do I
>>>>>>>> need to somehow mimic this to get my proxy to read the data?
>>>>>>> 
>>>>>>>> --Brian
>>>>>>> 
>>>>>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>>>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>>>>>> Shashidhar Shashidhar wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call
>>>>>>>>>> and
>>>>>>>>>> what should we do here. When can this happen and how to come out
>>>>>>>>>> of
>>>>>>>>>> this
>>>>>>>>>> condition.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Shashidhar.
>>>>>>>>> 
>>>>>>>>> reading from the client or server?
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing request
Date: Thu, 18 Jan 2007 23:44:34 -0800
Lines: 41
Distribution: su
Message-ID: <C1D5B6E2.7797%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU> <C1D54107.7715%jpettit@stanford.edu> <eops83$idj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169192677 19400 127.0.0.1 (19 Jan 2007 07:44:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Parsing request
Thread-Index: Acc7nalS6AGJt6eQEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11132

If by not proper, you mean doesn't conform to the RFC spec, then I'd return
a 400.  There's not a great mapping in the spec, but that seems to be the
best fit.  This could happen if the proxy connects to a service that's not
HTTP.  

--Justin


On 1/18/07 11:33 PM, in article eops83$idj$1@news.Stanford.EDU, "Neelima
Balakrishnan" <bneelima@stanford.edu> wrote:

> If the response status line is not proper, then what should be done?
> 
> Thanks
> Neelima
> 
> Justin Pettit wrote:
>> Don't worry about parsing much of the request and response.  For the
>> request, make sure that it makes sense, but you don't have to verify all the
>> headers.  For the response, make sure that you get a proper response status
>> line and then just pass everything else through unmodified.
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 12:26 PM, in article
>> Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU, "Seung Hoon
>> Choi" <shchoi@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> How exact do we need to parse the request/response? Do I need to make sure
>>> that requests and responses are exactly as defined in RFC documents?
>>> 
>>> 
>>> Thanks,
>>> -Seung
>>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Derek Schumacher" <dschumac@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Proxy process getting stuck in read() system call
Date: Thu, 18 Jan 2007 23:54:52 -0800
Lines: 194
Distribution: su
Message-ID: <eopthb$luc$1@news.Stanford.EDU>
References: <eon2fc$j07$1@news.Stanford.EDU> <eon3ts$k8s$1@news.Stanford.EDU> <eone2e$42e$1@news.Stanford.EDU> <eoo56v$qrp$1@news.Stanford.EDU> <C1D4EE4D.76C2%jpettit@stanford.edu> <eop44m$qno$1@news.Stanford.EDU> <C1D56150.773F%jpettit@stanford.edu> <eopgut$9hf$1@news.Stanford.EDU> <C1D5B2CE.778C%jpettit@stanford.edu> <eops2j$i9c$1@news.Stanford.EDU> <C1D5B59A.7793%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169193323 22476 127.0.0.1 (19 Jan 2007 07:55:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11133

Yep, thanks; although it complicates what I had been trying to do in reusing 
code that reads from a stream, but I should be able to get around that.

Derek

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D5B59A.7793%jpettit@stanford.edu...
> Ahh.  I think this discussion started with a question about reading data
> from the server, which is different, since it sends data and then closes 
> the
> connection.  When the connection is closed, the read() call return 0, when
> there is no more data.
>
> However, the client doesn't close the connection, since it still wants to
> get a response back.  For this, you should read data in and look for
> "\r\n\r\n"--the indicator that the request is completed.  At this point, 
> you
> will only ever write to the client's socket.
>
> Does that make sense?
>
> --Justin
>
>
> On 1/18/07 11:29 PM, in article eops2j$i9c$1@news.Stanford.EDU, "Derek
> Schumacher" <dschumac@stanford.edu> wrote:
>
>> I see this when simply taking the request in from the client when using 
>> the
>> grading script.  I haven't tried any other methods as of yet.
>>
>> Derek
>>
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1D5B2CE.778C%jpettit@stanford.edu...
>>> Are you seeing this problem from the web server?  Make sure that you're
>>> sending it HTTP/1.0 and not using keep-alive extension.  If so, it seems
>>> like it's not closing its connection.  Are you seeing this when you type
>>> in
>>> a request manually, using the grading script, or Firefox?
>>>
>>> --Justin
>>>
>>>
>>> On 1/18/07 8:20 PM, in article eopgut$9hf$1@news.Stanford.EDU, "Derek
>>> Schumacher" <dschumac@stanford.edu> wrote:
>>>
>>>> Any reason why I may not be seeing this happen?  I'm reasonably sure 
>>>> I'm
>>>> only doing two calls to read, one that returns the number of bytes read
>>>> initially (a non-zero positive number) and the second one which appears
>>>> to
>>>> block.
>>>>
>>>> Thanks,
>>>> Derek
>>>>
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>> news:C1D56150.773F%jpettit@stanford.edu...
>>>>> Yes, you should keep calling read() until you receive a 0 (no more 
>>>>> data)
>>>>> or
>>>>> a -1 (there was an error).
>>>>>
>>>>> --Justin
>>>>>
>>>>>
>>>>> On 1/18/07 4:41 PM, in article eop44m$qno$1@news.Stanford.EDU, "Derek
>>>>> Schumacher" <dschumac@stanford.edu> wrote:
>>>>>
>>>>>> For some reason I'm never seeing read() return a zero value when the
>>>>>> number
>>>>>> of bytes sent by the client and read in by read() is less than the 
>>>>>> size
>>>>>> of
>>>>>> the buffer I've supplied in the read() call.  Should I expect a 
>>>>>> single
>>>>>> additional call to read() to return zero after the initial one 
>>>>>> returns
>>>>>> a
>>>>>> positive value?
>>>>>>
>>>>>> Thanks,
>>>>>> Derek
>>>>>>
>>>>>>
>>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>>> news:C1D4EE4D.76C2%jpettit@stanford.edu...
>>>>>>> The best way to prevent blocking is to use the system call "select" 
>>>>>>> or
>>>>>>> "poll" to determine whether there is data to be read.  You can also
>>>>>>> mark
>>>>>>> the
>>>>>>> socket as non-blocking.  However, you shouldn't need to do either of
>>>>>>> these
>>>>>>> for this assignment.
>>>>>>>
>>>>>>> As David mentioned earlier, make sure that you don't immediately try
>>>>>>> to
>>>>>>> read() again after getting a zero return value, otherwise you'll
>>>>>>> block.
>>>>>>>
>>>>>>> --Justin
>>>>>>>
>>>>>>>
>>>>>>> On 1/18/07 7:54 AM, in article eoo56v$qrp$1@news.Stanford.EDU, 
>>>>>>> "Dinesh
>>>>>>> Gupta" <dineshg@Stanford.EDU> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm also seeing this problem when I configured firefox to use my
>>>>>>>> proxy.
>>>>>>>> It's stuck in read while reading from the remote server(yahoo). It
>>>>>>>> worked fine with cnn though. So it doesn't happen always but very
>>>>>>>> annoying when it happens. Please let me know how to come out of 
>>>>>>>> this
>>>>>>>> read
>>>>>>>> call.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dinesh
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Brian Thompson <Brian.C.Thompson@boeing.com> wrote:
>>>>>>>>> I am runninng into the same problem with my proxy, I don't get a
>>>>>>>>> response
>>>>>>>>> from the server.  I show that I connect just fine using serive 
>>>>>>>>> name
>>>>>>>>> of
>>>>>>>>> www
>>>>>>>>> on port 80.
>>>>>>>>
>>>>>>>>> As a check I have run the server.c and setup a server with a port 
>>>>>>>>> of
>>>>>>>>> 8001.
>>>>>>>>> Then I ran my proxy on 8000 and telneted to localhost 8000, sent a
>>>>>>>>> message
>>>>>>>>> to localhost on port 8001, saw my message reach the server and 
>>>>>>>>> then
>>>>>>>>> get
>>>>>>>>> a
>>>>>>>>> response.
>>>>>>>>
>>>>>>>>> I'm starting to think that there is something blocking the returns
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> reads.  I notice that when I do a normal telnet to www.yahoo.com 
>>>>>>>>> 80
>>>>>>>>> and
>>>>>>>>> then
>>>>>>>>> GET / HTTP/1.0 I have to press enter 3 times to get the data to
>>>>>>>>> show.
>>>>>>>>> Do I
>>>>>>>>> need to somehow mimic this to get my proxy to read the data?
>>>>>>>>
>>>>>>>>> --Brian
>>>>>>>>
>>>>>>>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>>>>>>>> news:eon3ts$k8s$1@news.Stanford.EDU...
>>>>>>>>>> Shashidhar Shashidhar wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Sometimes I see that the proxy gets stuck in read( ) system call
>>>>>>>>>>> and
>>>>>>>>>>> what should we do here. When can this happen and how to come out
>>>>>>>>>>> of
>>>>>>>>>>> this
>>>>>>>>>>> condition.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Shashidhar.
>>>>>>>>>>
>>>>>>>>>> reading from the client or server?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission Tarballs
Date: Fri, 19 Jan 2007 00:15:18 -0800
Lines: 14
Distribution: su
Message-ID: <eopumc$ole$1@news.Stanford.EDU>
References: <eop0ua$n6m$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169194509 25262 128.12.194.72 (19 Jan 2007 08:15:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eop0ua$n6m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11134

Clay Collier wrote:
> Please make sure that you are gzipping the tar archives that you submit 
> (use 'tar zcf' to create the file)- it will save you time performing the 
> upload, and makes it easier for us to process the submissions in a 
> batch.  Check out the sample Makefile on the assignment page if you're 
> not sure how to tar up your working files.
> 
> Clay

Clay,

should we re-submit if we've already submitted the tar file?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on Referencing
Date: Fri, 19 Jan 2007 00:27:21 -0800
Lines: 45
Distribution: su
Message-ID: <eopvcv$pcb$1@news.Stanford.EDU>
References: <paun-071956.23113218012007@nntp.stanford.edu> <C1D5B156.778A%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169195231 25995 128.12.194.72 (19 Jan 2007 08:27:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1D5B156.778A%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11135

Um, what?

I only mentioned my code inspirations in the source code itself, since 
the specs for the README made no mention of repeating this information.

 From the website:

The second deliverable is a project writeup. This file should be a file 
called README (all caps) and should be a text file. This file should 
contain the following:

     * An overview of the structure of your code.
     * Any design decisions you made and a short justification for them. 
If you found ambiguities in the assignment itself, also list here how 
they were resolved in your implementation.
     * Answers to any questions the assignment asks.

But that's just the website. I'm not sure whether the TAs override the 
website or it's the other way around. :p

-Yangfan

Justin Pettit wrote:
> Yes, that's exactly where it should go.  I would recommend mentioning your
> "inspiration" in a comment above the code, too.  That way, no one reading
> the code without immediate access to the README will get concerned.
> 
> --Justin
> 
> 
> On 1/18/07 11:11 PM, in article
> paun-071956.23113218012007@nntp.stanford.edu, "Filip Paun"
> <paun@stanford.edu> wrote:
> 
> 
>> I have code that looks very similar to the code presented in one of the
>>books as well as the referenced website, and i would like to acknowledge
>>this code 'inspiration'.  On top of this, i have talked about the high
>>level project issues with other classmates.
>>
>> Just to make sure, the specifics of the above need to go in our README,
>>correct?
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on Referencing
Date: Fri, 19 Jan 2007 00:40:16 -0800
Lines: 59
Distribution: su
Message-ID: <C1D5C3F0.77AC%jpettit@stanford.edu>
References: <paun-071956.23113218012007@nntp.stanford.edu> <C1D5B156.778A%jpettit@stanford.edu> <eopvcv$pcb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169196019 26695 127.0.0.1 (19 Jan 2007 08:40:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Question on Referencing
Thread-Index: Acc7pXFPr6KwqKeYEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11136

I think documenting the source code itself is safest, so that you don't
accidentally reuse the code later and miss a proper attribution.  However,
we'll look in both places before we drag you in front of the Judicial
Affairs Counsel.  ;)  Hopefully, you didn't need very much "inspiration",
either.

--Justin


On 1/19/07 12:27 AM, in article eopvcv$pcb$1@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> Um, what?
> 
> I only mentioned my code inspirations in the source code itself, since
> the specs for the README made no mention of repeating this information.
> 
>  From the website:
> 
> The second deliverable is a project writeup. This file should be a file
> called README (all caps) and should be a text file. This file should
> contain the following:
> 
>      * An overview of the structure of your code.
>      * Any design decisions you made and a short justification for them.
> If you found ambiguities in the assignment itself, also list here how
> they were resolved in your implementation.
>      * Answers to any questions the assignment asks.
> 
> But that's just the website. I'm not sure whether the TAs override the
> website or it's the other way around. :p
> 
> -Yangfan
> 
> Justin Pettit wrote:
>> Yes, that's exactly where it should go.  I would recommend mentioning your
>> "inspiration" in a comment above the code, too.  That way, no one reading
>> the code without immediate access to the README will get concerned.
>> 
>> --Justin
>> 
>> 
>> On 1/18/07 11:11 PM, in article
>> paun-071956.23113218012007@nntp.stanford.edu, "Filip Paun"
>> <paun@stanford.edu> wrote:
>> 
>> 
>>> I have code that looks very similar to the code presented in one of the
>>> books as well as the referenced website, and i would like to acknowledge
>>> this code 'inspiration'.  On top of this, i have talked about the high
>>> level project issues with other classmates.
>>> 
>>> Just to make sure, the specifics of the above need to go in our README,
>>> correct?
>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Potential Submission Problems
Date: Fri, 19 Jan 2007 00:42:03 -0800
Lines: 14
Distribution: su
Message-ID: <C1D5C45B.77B1%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169196123 26746 127.0.0.1 (19 Jan 2007 08:42:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Potential Submission Problems
Thread-Index: Acc7pbEV72yxR6eYEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11137

We've gotten a few reports from students getting "Access Forbidden" pages
after authenticating via WebAuth.  We think the problem is limited to SCPD
students and that we've fixed the problem.  However, if you receive that
error when submitting Friday, just email the tarball directly to your TA.
Please put "CS244A" in the subject line, so that we can easily spot your
submission. 

Hopefully that won't be necessary.  Keep in mind that the 5PM deadline is
still in effect, so don't wait until the last minute to try submitting.

Good luck!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Potential Submission Problems
Date: Fri, 19 Jan 2007 01:16:51 -0800
Lines: 26
Distribution: su
Message-ID: <eoq2ai$t1r$1@news.Stanford.EDU>
References: <C1D5C45B.77B1%jpettit@stanford.edu>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1169198226 29755 171.64.75.59 (19 Jan 2007 09:17:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11138


This is off-topic, but is there a way to check and confirm that we 
successfully submitted our work?
The one-time "Your submission is complete!" message itself is not quite 
assuring enough for me :-)

-Steven

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D5C45B.77B1%jpettit@stanford.edu...
> We've gotten a few reports from students getting "Access Forbidden" pages
> after authenticating via WebAuth.  We think the problem is limited to SCPD
> students and that we've fixed the problem.  However, if you receive that
> error when submitting Friday, just email the tarball directly to your TA.
> Please put "CS244A" in the subject line, so that we can easily spot your
> submission.
>
> Hopefully that won't be necessary.  Keep in mind that the 5PM deadline is
> still in effect, so don't wait until the last minute to try submitting.
>
> Good luck!
>
> --Justin
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing request
Date: Fri, 19 Jan 2007 01:28:27 -0800
Lines: 17
Distribution: su
Message-ID: <eoq301$jn$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU> <C1D54107.7715%jpettit@stanford.edu> <eops83$idj$1@news.Stanford.EDU> <C1D5B6E2.7797%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169198913 631 127.0.0.1 (19 Jan 2007 09:28:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1D5B6E2.7797%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11139

Justin Pettit wrote:
> If by not proper, you mean doesn't conform to the RFC spec, then I'd return
> a 400.  There's not a great mapping in the spec, but that seems to be the
> best fit.  This could happen if the proxy connects to a service that's not
> HTTP.  
> 
> --Justin
> 

Isn't the response code
	
	502 Bad Gateway
	The server, while acting as a gateway or proxy, received an
	invalid response from the upstream server it accessed in
	attempting to fulfill the request.

more appropriate?
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission Tarballs
Date: Fri, 19 Jan 2007 01:26:44 -0800
Lines: 18
Distribution: su
Message-ID: <eoq301$ku$1@news.Stanford.EDU>
References: <eop0ua$n6m$1@news.Stanford.EDU> <eopumc$ole$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169198914 670 171.64.74.54 (19 Jan 2007 09:28:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eopumc$ole$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11140

If you have a chance to do so, it would be helpful.

Clay
Yangfan Wang wrote:
> Clay Collier wrote:
>> Please make sure that you are gzipping the tar archives that you 
>> submit (use 'tar zcf' to create the file)- it will save you time 
>> performing the upload, and makes it easier for us to process the 
>> submissions in a batch.  Check out the sample Makefile on the 
>> assignment page if you're not sure how to tar up your working files.
>>
>> Clay
> 
> Clay,
> 
> should we re-submit if we've already submitted the tar file?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Potential Submission Problems
Date: Fri, 19 Jan 2007 01:36:17 -0800
Lines: 38
Distribution: su
Message-ID: <eoq3hv$13h$1@news.Stanford.EDU>
References: <C1D5C45B.77B1%jpettit@stanford.edu> <eoq2ai$t1r$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169199488 1137 171.64.74.54 (19 Jan 2007 09:38:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eoq2ai$t1r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11141

At the moment, you'll have to put your faith in the confidence-inspiring 
'submission accepted' message.  I think it shouldn't be too difficult to 
set something up to allow you to check the status of your submission and 
ensure that things have gone through- I'll try to get that set up early 
tomorrow.

Clay





Euijong Whang wrote:
> This is off-topic, but is there a way to check and confirm that we 
> successfully submitted our work?
> The one-time "Your submission is complete!" message itself is not quite 
> assuring enough for me :-)
> 
> -Steven
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1D5C45B.77B1%jpettit@stanford.edu...
>> We've gotten a few reports from students getting "Access Forbidden" pages
>> after authenticating via WebAuth.  We think the problem is limited to SCPD
>> students and that we've fixed the problem.  However, if you receive that
>> error when submitting Friday, just email the tarball directly to your TA.
>> Please put "CS244A" in the subject line, so that we can easily spot your
>> submission.
>>
>> Hopefully that won't be necessary.  Keep in mind that the 5PM deadline is
>> still in effect, so don't wait until the last minute to try submitting.
>>
>> Good luck!
>>
>> --Justin
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parsing request
Date: Fri, 19 Jan 2007 01:38:33 -0800
Lines: 33
Distribution: su
Message-ID: <C1D5D199.77BA%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0701181225270.12959-100000@myth22.Stanford.EDU> <C1D54107.7715%jpettit@stanford.edu> <eops83$idj$1@news.Stanford.EDU> <C1D5B6E2.7797%jpettit@stanford.edu> <eoq301$jn$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169199516 1240 127.0.0.1 (19 Jan 2007 09:38:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Parsing request
Thread-Index: Acc7rZWu1D/BeKegEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11142

You're right.  I think that's a better choice.  I was thinking that if the
client specifies port 443, for example, and the server is expecting SSL,
then it would be a bad request.  However, 502 makes more sense.  Regardless,
it is fine to return either either 502 or 400 for the purposes of the
assignment.

Thanks for pointing that out!

--Justin  


On 1/19/07 1:28 AM, in article eoq301$jn$1@news.Stanford.EDU, "Yuliya
Sarkisyan" <yuliya@stanford.edu> wrote:

> Justin Pettit wrote:
>> If by not proper, you mean doesn't conform to the RFC spec, then I'd return
>> a 400.  There's not a great mapping in the spec, but that seems to be the
>> best fit.  This could happen if the proxy connects to a service that's not
>> HTTP.  
>> 
>> --Justin
>> 
> 
> Isn't the response code
> 
> 502 Bad Gateway
> The server, while acting as a gateway or proxy, received an
> invalid response from the upstream server it accessed in
> attempting to fulfill the request.
> 
> more appropriate?


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: multithreading
Date: Fri, 19 Jan 2007 03:25:52 -0800
Lines: 12
Distribution: su
Message-ID: <eoq9s1$6b9$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169205953 6505 128.12.81.44 (19 Jan 2007 11:25:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11143

Hi,

What is the gcc compiler option to link to multithreaded c and c++ standard 
libraries? Also, is the socket library thread-safe by default or must one 
synchronize socket calls? If only a single thread deals with each socket is 
it thread-safe?

Thank you,
David Gobaud



.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Do we need to handle simple request/response?
Date: Fri, 19 Jan 2007 03:41:32 -0800
Lines: 33
Distribution: su
Message-ID: <eoqao5$6v0$1@news.Stanford.EDU>
References: <eopaiu$33r$2@news.Stanford.EDU> <C1D56F4D.7750%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1169206853 7136 127.0.0.1 (19 Jan 2007 11:40:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11144

Then talking about validating anything (including the status line) from the 
server is a farce.

My document could just happen to read:
HTTP/bunnyrabit.litter 747 Go HOME

I can imagine fun things to do with a 1.1 looking status line followed by a 
(perfectly legitimate) ContentLength of 1 gazillion.

What a spec!

I guess that makes my life easier...

Sincerely,
Randy Jennings

The squirrels are your friends!

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D56F4D.7750%jpettit@stanford.edu...
> Yes, you need to support HTTP/1.0 as defined in the RFC.
>
> --Justin
>
>
> On 1/18/07 6:31 PM, in article eopaiu$33r$2@news.Stanford.EDU, "Yuliya
> Sarkisyan" <yuliya@stanford.edu> wrote:
>
>> Thanks.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: broken pipe?
Date: Fri, 19 Jan 2007 05:16:16 -0800
Lines: 9
Distribution: su
Message-ID: <eoqgb1$dk0$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169212577 13952 128.12.81.44 (19 Jan 2007 13:16:17 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11145

Hi,

Sometimes when my proxy is processing requests it exits and says "Broken 
pipe". Ideas... ? I can't reproduce it reliably.

Thank you,
David Gobaud 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: broken pipe?
Date: Fri, 19 Jan 2007 08:14:19 -0800
Lines: 22
Distribution: su
Message-ID: <C1D62E5B.77CA%jpettit@stanford.edu>
References: <eoqgb1$dk0$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169223262 22793 127.0.0.1 (19 Jan 2007 16:14:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: broken pipe?
Thread-Index: Acc75N9mHeZsrKfYEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11146

I actual spoke with another student who had a similar problem.  It has to do
with trying to write to a socket that was closed by the other end.  Look
into handling the SIGPIPE signal.  If you don't have a handler, the system
kills your process.

--Justin


On 1/19/07 5:16 AM, in article eoqgb1$dk0$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> Hi,
> 
> Sometimes when my proxy is processing requests it exits and says "Broken
> pipe". Ideas... ? I can't reproduce it reliably.
> 
> Thank you,
> David Gobaud 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: multithreading
Date: Fri, 19 Jan 2007 08:25:49 -0800
Lines: 29
Distribution: su
Message-ID: <C1D6310D.77CE%jpettit@stanford.edu>
References: <eoq9s1$6b9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169223952 23321 127.0.0.1 (19 Jan 2007 16:25:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: multithreading
Thread-Index: Acc75nqsuV65hKfZEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11147

I'm not quite sure what you are asking in your first question, but I assume
you figured it out, since a later post seems to have working code.

Most of the socket calls are thread-safe.  There are a few, such as
gethostent, which are not thread-safe, but they have sister functions with
an "_r", such as gethostent_r.  They are listed on the same man page as the
normal call, so keep your eyes open for them.  However, you should look at
Chapter 26 of Stevens for a full discussion.

--Justin


On 1/19/07 3:25 AM, in article eoq9s1$6b9$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> Hi,
> 
> What is the gcc compiler option to link to multithreaded c and c++ standard
> libraries? Also, is the socket library thread-safe by default or must one
> synchronize socket calls? If only a single thread deals with each socket is
> it thread-safe?
> 
> Thank you,
> David Gobaud
> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: grading script vs. telnet
Date: Fri, 19 Jan 2007 16:27:24 +0000 (UTC)
Organization: Your Company
Lines: 21
Distribution: su
Message-ID: <Xns98BD5608CADEFchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169224044 23349 128.12.22.217 (19 Jan 2007 16:27:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11148

my grading script says:

>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
Entertainment & Video News</title>     <meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1">


but when i telnet and do GET http://www.cnn.com/

it works just fine and i get 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
Entertainment & Video News</title>     <meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1">


help...
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: www.cnn.com
Date: Fri, 19 Jan 2007 16:31:28 +0000 (UTC)
Organization: Your Company
Lines: 49
Distribution: su
Message-ID: <Xns98BD56B9B74EDchunkaiwstanfordedu@171.64.14.103>
References: <eol05i$g9o$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169224288 23349 128.12.22.217 (19 Jan 2007 16:31:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11149

i have a similar problem except mine is: 

>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
Entertainment & Video News</title>     <meta http-equiv="content-
type" content="text/html; charset=iso-8859-1">


but when i telnet, i get what is expected in the <<<

help...



"Madeleine Lam" <mlamone@cisco.com> wrote in
news:eol05i$g9o$1@news.Stanford.EDU: 

> Hi,
> 
> What is the tricky reason of using www.cnn.com?
> 
> I am getting:
> 
> proxy: >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> 
> <<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
> Transitional//EN"><html lang="en"><head><title>CNN.com - Breaking
> News, U.S., World, Weather, Entertainment & Video News</title>    
> <meta http-equiv="content-type" content="text/html;
> charset=iso-8859-1"> 
> 
> 
> I tried manually
> telnet www.cnn.com 80
> GET / HTTP/1.0
> and still got "-//W3C//DTD HTML 4.01 Transitional//EN"
> 
> Also tried manually run my code using "GET http://www.cnn.com
> HTTP/1.0" and still got the same W3C output
> 
> Does the grading script expect "-//IETF//DTD HTML 2.0//EN" ?
> 
> 
> Thanks.
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Raymond Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script vs. telnet
Date: Fri, 19 Jan 2007 08:45:22 -0800
Lines: 28
Distribution: su
Message-ID: <eoqsj5$npg$1@news.Stanford.EDU>
References: <Xns98BD5608CADEFchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169225125 24368 127.0.0.1 (19 Jan 2007 16:45:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98BD5608CADEFchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11150

Someone noted (in the newsgroup) that cnn.com can sometimes serves up 
different responses.  I have also found that to be the case; but I find 
that for the majority of times, cnn.com passes the grading script runs.

- Raymond

Chun Kai Wang wrote:
> my grading script says:
> 
>>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> 
> <<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
> lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
> Entertainment & Video News</title>     <meta http-equiv="content-type" 
> content="text/html; charset=iso-8859-1">
> 
> 
> but when i telnet and do GET http://www.cnn.com/
> 
> it works just fine and i get 
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
> lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
> Entertainment & Video News</title>     <meta http-equiv="content-type" 
> content="text/html; charset=iso-8859-1">
> 
> 
> help...
.

Path: shelby.stanford.edu!not-for-mail
From: Raymond Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: broken pipe?
Date: Fri, 19 Jan 2007 08:46:01 -0800
Lines: 26
Distribution: su
Message-ID: <eoqskc$npg$2@news.Stanford.EDU>
References: <eoqgb1$dk0$1@news.Stanford.EDU> <C1D62E5B.77CA%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169225164 24368 127.0.0.1 (19 Jan 2007 16:46:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1D62E5B.77CA%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11151

Will we be marked off if we don't have signal handlers?
- Raymond

Justin Pettit wrote:
> I actual spoke with another student who had a similar problem.  It has to do
> with trying to write to a socket that was closed by the other end.  Look
> into handling the SIGPIPE signal.  If you don't have a handler, the system
> kills your process.
> 
> --Justin
> 
> 
> On 1/19/07 5:16 AM, in article eoqgb1$dk0$1@news.Stanford.EDU, "David
> Gobaud" <gobaudd@stanford.edu> wrote:
> 
>> Hi,
>>
>> Sometimes when my proxy is processing requests it exits and says "Broken
>> pipe". Ideas... ? I can't reproduce it reliably.
>>
>> Thank you,
>> David Gobaud 
>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: broken pipe?
Date: Fri, 19 Jan 2007 08:57:33 -0800
Lines: 39
Distribution: su
Message-ID: <C1D6387D.77DD%jpettit@stanford.edu>
References: <eoqgb1$dk0$1@news.Stanford.EDU> <C1D62E5B.77CA%jpettit@stanford.edu> <eoqskc$npg$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169225855 25000 127.0.0.1 (19 Jan 2007 16:57:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: broken pipe?
Thread-Index: Acc76umLJ/3ZSKfeEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11152

No, but if your program dies during execution, then you'll definitely lose
points.  I've only heard about SIGPIPE problems related to multithreaded
implementations of the assignment.  My version of the assignment didn't have
any signal handlers (I did a forking version).

--Justin
 

On 1/19/07 8:46 AM, in article eoqskc$npg$2@news.Stanford.EDU, "Raymond
Thang" <rlt5654@stanford.edu> wrote:

> Will we be marked off if we don't have signal handlers?
> - Raymond
> 
> Justin Pettit wrote:
>> I actual spoke with another student who had a similar problem.  It has to do
>> with trying to write to a socket that was closed by the other end.  Look
>> into handling the SIGPIPE signal.  If you don't have a handler, the system
>> kills your process.
>> 
>> --Justin
>> 
>> 
>> On 1/19/07 5:16 AM, in article eoqgb1$dk0$1@news.Stanford.EDU, "David
>> Gobaud" <gobaudd@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> Sometimes when my proxy is processing requests it exits and says "Broken
>>> pipe". Ideas... ? I can't reproduce it reliably.
>>> 
>>> Thank you,
>>> David Gobaud 
>>> 
>>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxy.c:40: warning: implicit declaration of function
Date: Fri, 19 Jan 2007 09:16:40 -0800
Lines: 17
Distribution: su
Message-ID: <eoqub0$pbe$1@news.Stanford.EDU>
References: <Xns98BCE7752A0A2chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169226912 25966 128.12.134.140 (19 Jan 2007 17:15:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <Xns98BCE7752A0A2chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11153

You need to include headers for these functions. Do a man for each of
them and you can find what header they are declared in for example.
memset is in string.h. So you need to add #include <string.h> to your code.

Jad.

Chun Kai Wang wrote:
> anyone know how to solve: 
> 
> 
> proxy.c:40: warning: implicit declaration of function 'read'
> proxy.c:47: warning: implicit declaration of function 'bzero'
> proxy.c:50: warning: implicit declaration of function 'inet_aton'
> proxy.c:51: warning: implicit declaration of function 'memset'
> 
> 
> ? thanks : )
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: how do we know that submissions have gone through?
Date: Fri, 19 Jan 2007 09:32:14 -0800
Lines: 6
Distribution: su
Message-ID: <eoqvam$q5u$1@news.Stanford.EDU>
NNTP-Posting-Host: zeus2.stanford.edu
X-Trace: news.Stanford.EDU 1169227926 26814 128.12.137.163 (19 Jan 2007 17:32:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11154

How do we know that that submissions have gone through?

Is there any way to log into the myth machines and check a directory to make 
sure that there exists a submission with my "suid-name"


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: how do we know that submissions have gone through?
Date: Fri, 19 Jan 2007 10:01:51 -0800
Lines: 16
Distribution: su
Message-ID: <C1D6478F.77E8%jpettit@stanford.edu>
References: <eoqvam$q5u$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169229712 28757 127.0.0.1 (19 Jan 2007 18:01:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: how do we know that submissions have gone through?
Thread-Index: Acc78+UYI4ov/KfnEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11155

Look for the thread titled "Re: Potential Submission Problems".

--Justin


On 1/19/07 9:32 AM, in article eoqvam$q5u$1@news.Stanford.EDU, "manj"
<manj@stanford.edu> wrote:

> How do we know that that submissions have gone through?
> 
> Is there any way to log into the myth machines and check a directory to make
> sure that there exists a submission with my "suid-name"
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Raymond Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission Tarballs
Date: Fri, 19 Jan 2007 10:30:43 -0800
Lines: 15
Distribution: su
Message-ID: <eor2on$11a$1@news.Stanford.EDU>
References: <eop0ua$n6m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169231447 1066 127.0.0.1 (19 Jan 2007 18:30:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eop0ua$n6m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11156

Clay Collier wrote:
> Please make sure that you are gzipping the tar archives that you submit 
> (use 'tar zcf' to create the file)- it will save you time performing the 
> upload, and makes it easier for us to process the submissions in a 
> batch.  Check out the sample Makefile on the assignment page if you're 
> not sure how to tar up your working files.
> 
> Clay

(This may sound a little silly)

If we've updated the makefile sources and headers correctly, shouldn't 
we just be able to 'make submit' and submit the pa1.tar.gz file it produces?

- Raymond
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: error handling
Date: Fri, 19 Jan 2007 19:44:36 +0000 (UTC)
Organization: Your Company
Lines: 12
Distribution: su
Message-ID: <Xns98BD7777D7820chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169235876 6067 128.12.22.217 (19 Jan 2007 19:44:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11157

what should the error handling be?

right now, when i change the grading script such that there is an invalid 
url, say "ht://www.c.com" then a valid one after that "http://www.cnn.com/"

the grading script will exit and print the error message for the invalid 
URL


is this correct? or is it suppose to continue?


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: unable to open socket
Date: Fri, 19 Jan 2007 20:00:55 +0000 (UTC)
Organization: Your Company
Lines: 10
Distribution: su
Message-ID: <Xns98BD7A3BF1A55chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169236855 6067 128.12.22.217 (19 Jan 2007 20:00:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11158

i passed the grading script but when i use IE to access the proxy, 

it works at first, but once i press "F5, or refresh", 


then the proxy shuts down and returns cannot open socket for all 
websites...


is this normal?
.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Segmentation Fault
Date: Fri, 19 Jan 2007 12:04:33 -0800
Lines: 48
Distribution: su
Message-ID: <eor88o$6va$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169237080 7146 127.0.0.1 (19 Jan 2007 20:04:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11159

I am consistently getting a segmentation fault on ports 1300, 1304 and 
1307, but on no others in the 1300-1325 range.

The following are my first lines in main():

   if ( (listenfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
     error("ERROR opening socket");

   if (argc < 2)
     error("ERROR, no port provided\n");

   portno = atoi(argv[1]);

   printf("port: %d\n", portno);

   bzero((char *) &servaddr, sizeof(servaddr));
   servaddr.sin_family = AF_INET;
   servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
   servaddr.sin_port = htons(portno);

   printf("created socket struct\n");

   /* BIND SOCKET */

   if (bind(listenfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
     error("ERROR on binding");

   printf("bound to socket\n");


The port is printed correctly and so is "created socket struct\n", but 
the segmentation fault occurs before "bound to socket\n" is printed.

Why would the program crash on some ports and work on others?

Thanks for the help,
Yuliya

P.S.

I am having trouble running valgrind and am getting the following error 
message:

vine7:~/cs244a> valgrind proxy 1301
Executable range 0xb0000000-0xb0819730 is outside the
acceptable range 0x80d7000-0x7fa11000
valgrind: failed to load /usr/lib/valgrind/stage2: Cannot allocate memory

.

Path: shelby.stanford.edu!not-for-mail
From: Douglas Wightman <wightman@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Basing code upon other code
Date: Fri, 19 Jan 2007 12:23:55 -0800
Lines: 10
Distribution: su
Message-ID: <eor9cr$7ps$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169238235 7996 127.0.0.1 (19 Jan 2007 20:23:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11160

This is my first programming assignment at Stanford. Please confirm 
whether or not it is alright to cut & paste code snippets from other 
sources (so long as they are cited). For example:
http://www.cs.rpi.edu/courses/sysprog/sockets/sock.html

Would this be considered plagiarism? Clearly, the functioning of these 
examples significantly differs from our assignment. Would it decrease my 
mark on the assignment?

Thanks
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: error handling
Date: Fri, 19 Jan 2007 12:40:07 -0800
Lines: 25
Distribution: su
Message-ID: <C1D66CA7.780C%jpettit@stanford.edu>
References: <Xns98BD7777D7820chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169239212 8884 127.0.0.1 (19 Jan 2007 20:40:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: error handling
Thread-Index: Acc8CgEmP7e9lqf9Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11161

If you receive a request like that, then send back an error to the client
and be in a state that you can handle a new connection.  The grading script
is fairly fragile, so do that sort of testing manually.

--Justin


On 1/19/07 11:44 AM, in article
Xns98BD7777D7820chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> what should the error handling be?
> 
> right now, when i change the grading script such that there is an invalid
> url, say "ht://www.c.com" then a valid one after that "http://www.cnn.com/"
> 
> the grading script will exit and print the error message for the invalid
> URL
> 
> 
> is this correct? or is it suppose to continue?
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: unable to open socket
Date: Fri, 19 Jan 2007 12:48:51 -0800
Lines: 25
Distribution: su
Message-ID: <C1D66EB3.7813%jpettit@stanford.edu>
References: <Xns98BD7A3BF1A55chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169239735 9313 127.0.0.1 (19 Jan 2007 20:48:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: unable to open socket
Thread-Index: Acc8Czl6eAgcMKf+Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11162

If you didn't write a select-based, thread-based, or fork-based proxy, then
your browser is probably going to have really bad performance and seem to
hang, since it issues many simultaneous requests.  That's why the grading
script does one request at a time.  Regardless, though, if your proxy "shuts
down", that doesn't sound good.

--Justin


On 1/19/07 12:00 PM, in article
Xns98BD7A3BF1A55chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> i passed the grading script but when i use IE to access the proxy,
> 
> it works at first, but once i press "F5, or refresh",
> 
> 
> then the proxy shuts down and returns cannot open socket for all
> websites...
> 
> 
> is this normal?


.

Path: shelby.stanford.edu!myth15.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: HTTP/0.9 Compatibility
Date: Fri, 19 Jan 2007 12:54:12 -0800
Lines: 9
Distribution: su
Message-ID: <Pine.LNX.4.44.0701191253430.8861-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1169240054 9683 171.64.15.56 (19 Jan 2007 20:54:14 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11163


Hi,

Do we need to make the proxy backward compatible to HTTP/0.9?


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Checking Assignment Submissions
Date: Fri, 19 Jan 2007 12:55:02 -0800
Lines: 10
Distribution: su
Message-ID: <eorbas$9ia$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169240221 9802 171.64.74.54 (19 Jan 2007 20:57:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11164

If you would like to check that your assignment was submitted 
successfully, take a look at

http://www.stanford.edu/class/cs244a/cgi-bin/submit/status.php

You should see a listing of the assignments that you have submitted 
(including resubmissions) and the dates that we have recorded for those 
submissions.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: grading script vs. telnet
Date: Fri, 19 Jan 2007 13:01:41 -0800
Lines: 38
Distribution: su
Message-ID: <eorbn8$9ia$2@news.Stanford.EDU>
References: <Xns98BD5608CADEFchunkaiwstanfordedu@171.64.14.103> <eoqsj5$npg$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169240618 9802 171.64.74.54 (19 Jan 2007 21:03:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eoqsj5$npg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11165

Yes- CNN does vary once in a while, and we will be using a static 
version of the page when we do the actual grading, to make sure that we 
don't get spurious errors when we test your proxy.

If the script is failing occasionally with slight variations, it is 
likely just CNN's server changing things around; if you are failing 
consistently, and seeing the same error every time, it's likely that 
your proxy is altering the data returned from the server in some way.

Clay
Raymond Thang wrote:
> Someone noted (in the newsgroup) that cnn.com can sometimes serves up 
> different responses.  I have also found that to be the case; but I find 
> that for the majority of times, cnn.com passes the grading script runs.
> 
> - Raymond
> 
> Chun Kai Wang wrote:
>> my grading script says:
>>
>>>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>>
>> <<< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 
>> Transitional//EN"><html lang="en"><head><title>CNN.com - Breaking 
>> News, U.S., World, Weather, Entertainment & Video News</title>     
>> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
>>
>>
>> but when i telnet and do GET http://www.cnn.com/
>>
>> it works just fine and i get
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html 
>> lang="en"><head><title>CNN.com - Breaking News, U.S., World, Weather, 
>> Entertainment & Video News</title>     <meta 
>> http-equiv="content-type" content="text/html; charset=iso-8859-1">
>>
>>
>> help...
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Submission Tarballs
Date: Fri, 19 Jan 2007 13:23:47 -0800
Lines: 22
Distribution: su
Message-ID: <eord0m$b5r$1@news.Stanford.EDU>
References: <eop0ua$n6m$1@news.Stanford.EDU> <eor2on$11a$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169241944 11451 171.64.74.54 (19 Jan 2007 21:25:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eor2on$11a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11166

Yes- as long as you've added any additional source files that you 
created to the source list, the 'make submit' from the Makefile should 
produce a perfectly acceptable file.

Clay
Raymond Thang wrote:
> Clay Collier wrote:
>> Please make sure that you are gzipping the tar archives that you 
>> submit (use 'tar zcf' to create the file)- it will save you time 
>> performing the upload, and makes it easier for us to process the 
>> submissions in a batch.  Check out the sample Makefile on the 
>> assignment page if you're not sure how to tar up your working files.
>>
>> Clay
> 
> (This may sound a little silly)
> 
> If we've updated the makefile sources and headers correctly, shouldn't 
> we just be able to 'make submit' and submit the pa1.tar.gz file it 
> produces?
> 
> - Raymond
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Connection close by foreign host
Date: Fri, 19 Jan 2007 13:31:18 -0800
Lines: 7
Distribution: su
Message-ID: <eordba$ble$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1169242282 11950 128.12.83.54 (19 Jan 2007 21:31:22 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11167

When I try to connect to the Stanford website, it gets alll-most all the way 
to the end before getting shut down by the other side.  This happens both 
with IE and telnet.  Any ideas?

--Alicia 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: multithreading
Date: Fri, 19 Jan 2007 13:45:11 -0800
Lines: 46
Distribution: su
Message-ID: <eore59$cav$1@news.Stanford.EDU>
References: <eoq9s1$6b9$1@news.Stanford.EDU> <C1D6310D.77CE%jpettit@stanford.edu>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169243113 12639 128.12.81.44 (19 Jan 2007 21:45:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11168

I'm used to programming for Windows and think in Visual Studio one can 
select either a single threaded or multithreaded CRT library to link to and 
if one uses the single threaded one with a multithreaded program I believe 
there are problems.

Is it the same in Unix?

David Gobaud

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D6310D.77CE%jpettit@stanford.edu...
> I'm not quite sure what you are asking in your first question, but I 
> assume
> you figured it out, since a later post seems to have working code.
>
> Most of the socket calls are thread-safe.  There are a few, such as
> gethostent, which are not thread-safe, but they have sister functions with
> an "_r", such as gethostent_r.  They are listed on the same man page as 
> the
> normal call, so keep your eyes open for them.  However, you should look at
> Chapter 26 of Stevens for a full discussion.
>
> --Justin
>
>
> On 1/19/07 3:25 AM, in article eoq9s1$6b9$1@news.Stanford.EDU, "David
> Gobaud" <gobaudd@stanford.edu> wrote:
>
>> Hi,
>>
>> What is the gcc compiler option to link to multithreaded c and c++ 
>> standard
>> libraries? Also, is the socket library thread-safe by default or must one
>> synchronize socket calls? If only a single thread deals with each socket 
>> is
>> it thread-safe?
>>
>> Thank you,
>> David Gobaud
>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: broken pipe?
Date: Fri, 19 Jan 2007 13:47:00 -0800
Lines: 53
Distribution: su
Message-ID: <eore8l$ce6$1@news.Stanford.EDU>
References: <eoqgb1$dk0$1@news.Stanford.EDU> <C1D62E5B.77CA%jpettit@stanford.edu> <eoqskc$npg$2@news.Stanford.EDU> <C1D6387D.77DD%jpettit@stanford.edu>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169243221 12742 128.12.81.44 (19 Jan 2007 21:47:01 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11169

My implementation is single threaded. I think I fixed the problem by being 
more careful and not writing to sockets on which a recv or send has already 
failed.

David Gobaud

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D6387D.77DD%jpettit@stanford.edu...
> No, but if your program dies during execution, then you'll definitely lose
> points.  I've only heard about SIGPIPE problems related to multithreaded
> implementations of the assignment.  My version of the assignment didn't 
> have
> any signal handlers (I did a forking version).
>
> --Justin
>
>
> On 1/19/07 8:46 AM, in article eoqskc$npg$2@news.Stanford.EDU, "Raymond
> Thang" <rlt5654@stanford.edu> wrote:
>
>> Will we be marked off if we don't have signal handlers?
>> - Raymond
>>
>> Justin Pettit wrote:
>>> I actual spoke with another student who had a similar problem.  It has 
>>> to do
>>> with trying to write to a socket that was closed by the other end.  Look
>>> into handling the SIGPIPE signal.  If you don't have a handler, the 
>>> system
>>> kills your process.
>>>
>>> --Justin
>>>
>>>
>>> On 1/19/07 5:16 AM, in article eoqgb1$dk0$1@news.Stanford.EDU, "David
>>> Gobaud" <gobaudd@stanford.edu> wrote:
>>>
>>>> Hi,
>>>>
>>>> Sometimes when my proxy is processing requests it exits and says 
>>>> "Broken
>>>> pipe". Ideas... ? I can't reproduce it reliably.
>>>>
>>>> Thank you,
>>>> David Gobaud
>>>>
>>>>
>>>
>>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Connection close by foreign host
Date: Fri, 19 Jan 2007 13:47:48 -0800
Lines: 14
Distribution: su
Message-ID: <eorea5$cf0$1@news.Stanford.EDU>
References: <eordba$ble$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169243269 12768 128.12.81.44 (19 Jan 2007 21:47:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11170

I'm having the same problem with an HTTP .9 session to www.yahoo.com

David Gobaud

"Alicia Chen" <achen530@stanford.edu> wrote in message 
news:eordba$ble$1@news.Stanford.EDU...
> When I try to connect to the Stanford website, it gets alll-most all the 
> way to the end before getting shut down by the other side.  This happens 
> both with IE and telnet.  Any ideas?
>
> --Alicia
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: multithreading
Date: Fri, 19 Jan 2007 13:50:13 -0800
Lines: 56
Distribution: su
Message-ID: <C1D67D15.7825%jpettit@stanford.edu>
References: <eoq9s1$6b9$1@news.Stanford.EDU> <C1D6310D.77CE%jpettit@stanford.edu> <eore59$cav$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169243420 13031 127.0.0.1 (19 Jan 2007 21:50:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: multithreading
Thread-Index: Acc8E8wfCo0jJKgHEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11171

Just stick to the thread-safe version of calls, and you should be fine.

--Justin


On 1/19/07 1:45 PM, in article eore59$cav$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> I'm used to programming for Windows and think in Visual Studio one can
> select either a single threaded or multithreaded CRT library to link to and
> if one uses the single threaded one with a multithreaded program I believe
> there are problems.
> 
> Is it the same in Unix?
> 
> David Gobaud
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D6310D.77CE%jpettit@stanford.edu...
>> I'm not quite sure what you are asking in your first question, but I
>> assume
>> you figured it out, since a later post seems to have working code.
>> 
>> Most of the socket calls are thread-safe.  There are a few, such as
>> gethostent, which are not thread-safe, but they have sister functions with
>> an "_r", such as gethostent_r.  They are listed on the same man page as
>> the
>> normal call, so keep your eyes open for them.  However, you should look at
>> Chapter 26 of Stevens for a full discussion.
>> 
>> --Justin
>> 
>> 
>> On 1/19/07 3:25 AM, in article eoq9s1$6b9$1@news.Stanford.EDU, "David
>> Gobaud" <gobaudd@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> What is the gcc compiler option to link to multithreaded c and c++
>>> standard
>>> libraries? Also, is the socket library thread-safe by default or must one
>>> synchronize socket calls? If only a single thread deals with each socket
>>> is
>>> it thread-safe?
>>> 
>>> Thank you,
>>> David Gobaud
>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HTTP/0.9 Compatibility
Date: Fri, 19 Jan 2007 13:51:16 -0800
Lines: 20
Distribution: su
Message-ID: <C1D67D54.7826%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0701191253430.8861-100000@myth15.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169243478 13031 127.0.0.1 (19 Jan 2007 21:51:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: HTTP/0.9 Compatibility
Thread-Index: Acc8E/GsMDwVxKgHEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11172

We'll only send HTTP/1.0 requests.

--Justin


On 1/19/07 12:54 PM, in article
Pine.LNX.4.44.0701191253430.8861-100000@myth15.Stanford.EDU, "Seung Hoon
Choi" <shchoi@stanford.edu> wrote:

> 
> Hi,
> 
> Do we need to make the proxy backward compatible to HTTP/0.9?
> 
> 
> Thanks,
> -Seung
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Char to String
Date: Fri, 19 Jan 2007 14:07:02 -0800
Lines: 3
Distribution: su
Message-ID: <eorfea$dib$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169244426 13899 127.0.0.1 (19 Jan 2007 22:07:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:11173

What is the best method for changing a char to a string in C? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Fri, 19 Jan 2007 15:16:03 -0800
Lines: 125
Distribution: su
Message-ID: <eorjfo$h9a$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169248568 17706 127.0.0.1 (19 Jan 2007 23:16:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11174

I've been testing my proxy through telnet and my browsers mostly, so I just 
started using the grading script and I've got this error too. I don't have 
any trouble making connections through the browsers though. Anyone know some 
reasons why this would occur only with the script or if there's a way to 
debug my program while the script is executing?

Thanks,
Darius


"Alex" <axle@sonic.net> wrote in message 
news:eoel8m$ob8$1@news.Stanford.EDU...
>I gave a port in the valid range and I still see this issue. I was able to 
>run my proxy on that port and use telnet and do GET correctly but I'm still 
>having problems with the grading script.
>
> vine7:~/proj1> ./grade proxy.c 32454
> Binary: proxy.c
> Running on port 32454
> Traceback (most recent call last):
>  File "./grade", line 97, in ?
>    main()
>  File "./grade", line 42, in main
>    foblist.append(urllib.urlopen(url, None, proxy_map))
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line 
> 82, in urlopen
>    return opener.open(url)
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line 
> 190, in open
>    return getattr(self, name)(url)
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line 
> 313, in open_http
>    h.endheaders()
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
> line 798, in endheaders
>    self._send_output()
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
> line 679, in _send_output
>    self.send(msg)
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
> line 646, in send
>    self.connect()
>  File 
> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
> line 630, in connect
>    raise socket.error, msg
> IOError: [Errno socket error] (111, 'Connection refused')
>
> Alex
>
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1D00C6D.7506%jpettit@stanford.edu...
>> TCP and UDP port numbers are 16-bit values, which means the maximum value 
>> is
>> 65535.  Try something between 1024 and 65535.  You also might want to 
>> check
>> to make sure that you're checking all your socket return values and 
>> compiler
>> warnings.
>>
>> --Justin
>>
>>
>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>> <axle@sonic.net> wrote:
>>
>>> I was trying to run the grading script on my proxy and I get the 
>>> messages
>>> below. Why is this happening?
>>>
>>> vine7:~/proj1> ./grade proxy.c 98235
>>> Binary: proxy.c
>>> Running on port 98235
>>> Traceback (most recent call last):
>>>   File "./grade", line 100, in ?
>>>     main()
>>>   File "./grade", line 45, in main
>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 82, in urlopen
>>>     return opener.open(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 190, in open
>>>     return getattr(self, name)(url)
>>>   File 
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>> line 313, in open_http
>>>     h.endheaders()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 798, in endheaders
>>>     self._send_output()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 679, in _send_output
>>>     self.send(msg)
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 646, in send
>>>     self.connect()
>>>   File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py", 
>>> line
>>> 630, in connect
>>>     raise socket.error, msg
>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Re: Char to String
Date: Fri, 19 Jan 2007 15:52:21 -0800
Lines: 9
Distribution: su
Message-ID: <eorljq$j0h$1@news.Stanford.EDU>
References: <eorfea$dib$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169250746 19473 127.0.0.1 (19 Jan 2007 23:52:26 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:11175

Nevermind.   I found a way to do this by creating a 2 char array and then 
assigning [0] the char and [1] the '\0'.

"Brian Thompson" <Brian.C.Thompson@Boeing.com> wrote in message 
news:eorfea$dib$1@news.Stanford.EDU...
> What is the best method for changing a char to a string in C?
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Basing code upon other code
Date: Fri, 19 Jan 2007 16:21:20 -0800
Lines: 24
Distribution: su
Message-ID: <C1D6A080.783C%jpettit@stanford.edu>
References: <eor9cr$7ps$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169252489 21165 127.0.0.1 (20 Jan 2007 00:21:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Basing code upon other code
Thread-Index: Acc8KOh5JzQBt6gcEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11176

As I've stated before, there's only so many ways to do relatively simple
things.  If you are just doing basic things like creating sockets, binding
to interfaces, etc. then don't worry too much about citing your sources.  If
you are using bigger things (e.g. a modified version of Stevens's readline
function), then you should provide attribution.

--Justin


On 1/19/07 12:23 PM, in article eor9cr$7ps$1@news.Stanford.EDU, "Douglas
Wightman" <wightman@stanford.edu> wrote:

> This is my first programming assignment at Stanford. Please confirm
> whether or not it is alright to cut & paste code snippets from other
> sources (so long as they are cited). For example:
> http://www.cs.rpi.edu/courses/sysprog/sockets/sock.html
> 
> Would this be considered plagiarism? Clearly, the functioning of these
> examples significantly differs from our assignment. Would it decrease my
> mark on the assignment?
> 
> Thanks


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Segmentation Fault
Date: Fri, 19 Jan 2007 16:57:47 -0800
Lines: 61
Distribution: su
Message-ID: <C1D6A90B.7858%jpettit@stanford.edu>
References: <eor88o$6va$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169254671 22954 127.0.0.1 (20 Jan 2007 00:57:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Segmentation Fault
Thread-Index: Acc8LgAHPqFClqghEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11177

I don't see anything from my quick look at the code.  I'd recommend running
it through gdb.  I haven't seen your valgrind error before.  If you have
some memory problem that's causing a segmentation fault, it may be causing
valgrind problems.  Hopefully, it would warn you first, though.

--Justin


On 1/19/07 12:04 PM, in article eor88o$6va$1@news.Stanford.EDU, "Yuliya
Sarkisyan" <yuliya@stanford.edu> wrote:

> I am consistently getting a segmentation fault on ports 1300, 1304 and
> 1307, but on no others in the 1300-1325 range.
> 
> The following are my first lines in main():
> 
>    if ( (listenfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
>      error("ERROR opening socket");
> 
>    if (argc < 2)
>      error("ERROR, no port provided\n");
> 
>    portno = atoi(argv[1]);
> 
>    printf("port: %d\n", portno);
> 
>    bzero((char *) &servaddr, sizeof(servaddr));
>    servaddr.sin_family = AF_INET;
>    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
>    servaddr.sin_port = htons(portno);
> 
>    printf("created socket struct\n");
> 
>    /* BIND SOCKET */
> 
>    if (bind(listenfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
>      error("ERROR on binding");
> 
>    printf("bound to socket\n");
> 
> 
> The port is printed correctly and so is "created socket struct\n", but
> the segmentation fault occurs before "bound to socket\n" is printed.
> 
> Why would the program crash on some ports and work on others?
> 
> Thanks for the help,
> Yuliya
> 
> P.S.
> 
> I am having trouble running valgrind and am getting the following error
> message:
> 
> vine7:~/cs244a> valgrind proxy 1301
> Executable range 0xb0000000-0xb0819730 is outside the
> acceptable range 0x80d7000-0x7fa11000
> valgrind: failed to load /usr/lib/valgrind/stage2: Cannot allocate memory
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Fri, 19 Jan 2007 17:01:56 -0800
Lines: 138
Distribution: su
Message-ID: <C1D6AA04.785A%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169254919 23286 127.0.0.1 (20 Jan 2007 01:01:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: Acc8LpRx0zaVeKghEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11178

It looks like you may be closing the socket you have listening on 32454,
since the script is complaining that it can't connect to your proxy.  You
may want to telnet to your proxy and manually type in the requests from the
grading script.  Is your proxy crashing on one of the queries?

--Justin


On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
Henderson" <darius.henderson@stanford.edu> wrote:

> I've been testing my proxy through telnet and my browsers mostly, so I just
> started using the grading script and I've got this error too. I don't have
> any trouble making connections through the browsers though. Anyone know some
> reasons why this would occur only with the script or if there's a way to
> debug my program while the script is executing?
> 
> Thanks,
> Darius
> 
> 
> "Alex" <axle@sonic.net> wrote in message
> news:eoel8m$ob8$1@news.Stanford.EDU...
>> I gave a port in the valid range and I still see this issue. I was able to
>> run my proxy on that port and use telnet and do GET correctly but I'm still
>> having problems with the grading script.
>> 
>> vine7:~/proj1> ./grade proxy.c 32454
>> Binary: proxy.c
>> Running on port 32454
>> Traceback (most recent call last):
>>  File "./grade", line 97, in ?
>>    main()
>>  File "./grade", line 42, in main
>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line
>> 82, in urlopen
>>    return opener.open(url)
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line
>> 190, in open
>>    return getattr(self, name)(url)
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", line
>> 313, in open_http
>>    h.endheaders()
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>> line 798, in endheaders
>>    self._send_output()
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>> line 679, in _send_output
>>    self.send(msg)
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>> line 646, in send
>>    self.connect()
>>  File 
>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>> line 630, in connect
>>    raise socket.error, msg
>> IOError: [Errno socket error] (111, 'Connection refused')
>> 
>> Alex
>> 
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>> TCP and UDP port numbers are 16-bit values, which means the maximum value
>>> is
>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>> check
>>> to make sure that you're checking all your socket return values and
>>> compiler
>>> warnings.
>>> 
>>> --Justin
>>> 
>>> 
>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>> <axle@sonic.net> wrote:
>>> 
>>>> I was trying to run the grading script on my proxy and I get the
>>>> messages
>>>> below. Why is this happening?
>>>> 
>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>> Binary: proxy.c
>>>> Running on port 98235
>>>> Traceback (most recent call last):
>>>>   File "./grade", line 100, in ?
>>>>     main()
>>>>   File "./grade", line 45, in main
>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 82, in urlopen
>>>>     return opener.open(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 190, in open
>>>>     return getattr(self, name)(url)
>>>>   File 
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line 313, in open_http
>>>>     h.endheaders()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line
>>>> 798, in endheaders
>>>>     self._send_output()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line
>>>> 679, in _send_output
>>>>     self.send(msg)
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line
>>>> 646, in send
>>>>     self.connect()
>>>>   File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line
>>>> 630, in connect
>>>>     raise socket.error, msg
>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem Set Submission
Date: Fri, 19 Jan 2007 18:46:22 -0800
Lines: 19
Distribution: su
Message-ID: <C1D6C27E.786E%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169261183 28105 127.0.0.1 (20 Jan 2007 02:46:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Problem Set Submission
Thread-Index: Acc8PStFahSl0agwEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11179

As you should all be aware, the first problem set is due Tuesday at noon.
If you are on-campus, please drop off your assignment at Judy Polenta's
office.  If she is not there, please slip the assignment under her door.
Her office is Gates 351.

If you are an SCPD student, you are more than welcome to drop off your
homework.  However, this is probably not convenient, so feel free to fax it
directly to SCPD.  They'll take care of delivering it to us.  Here's the
routing form that you'll need:

    http://scpd.stanford.edu/scpd/downloads/remoteRouteForm.pdf

Assignments that are handed in will be returned in class.  Faxed assignments
will be sent back to you through SCPD.

If you have any questions, please let me know.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: broken pipe?
Date: Fri, 19 Jan 2007 19:41:19 -0800
Lines: 85
Distribution: su
Message-ID: <eos2vo$cp$1@news.Stanford.EDU>
References: <eoqgb1$dk0$1@news.Stanford.EDU> <C1D62E5B.77CA%jpettit@stanford.edu> <eoqskc$npg$2@news.Stanford.EDU> <C1D6387D.77DD%jpettit@stanford.edu> <eore8l$ce6$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169264440 409 127.0.0.1 (20 Jan 2007 03:40:40 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11180

> My implementation is single threaded. I think I fixed the problem by being 
> more careful and not writing to sockets on which a recv or send has 
> already failed.

That actually will not save you.  There is a good discussion of it in UNP. 
The high and low of it is that the first time you read a socket that was 
closed, you get a SIGPIPE.  After, it returns an error value.  So, it is 
very easy to blow up code that does not have a signal handler; just send a 
content length that is plausible, but longer than the data you will really 
send.

However, when I compile with -ansi, the preprocessor fails to find the 
functions.  This is in spite of the top of the file saying they are in C99 
(actually, POSIX is the standard).

-ansi gives:
proxy.c: In function 'unp_signal':
proxy.c:283: error: storage size of 'act' isn't known
proxy.c:283: error: storage size of 'oact' isn't known
proxy.c:285: warning: implicit declaration of function 'sigemptyset'
proxy.c:298: warning: implicit declaration of function 'sigaction'
proxy.c:283: warning: unused variable 'oact'
proxy.c:283: warning: unused variable 'act'
proxy.c:300: warning: control reaches end of non-void function

Sincerely,
Randy Jennings

The squirrels are your friends!
"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:eore8l$ce6$1@news.Stanford.EDU...
>
> David Gobaud
>
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1D6387D.77DD%jpettit@stanford.edu...
>> No, but if your program dies during execution, then you'll definitely 
>> lose
>> points.  I've only heard about SIGPIPE problems related to multithreaded
>> implementations of the assignment.  My version of the assignment didn't 
>> have
>> any signal handlers (I did a forking version).
>>
>> --Justin
>>
>>
>> On 1/19/07 8:46 AM, in article eoqskc$npg$2@news.Stanford.EDU, "Raymond
>> Thang" <rlt5654@stanford.edu> wrote:
>>
>>> Will we be marked off if we don't have signal handlers?
>>> - Raymond
>>>
>>> Justin Pettit wrote:
>>>> I actual spoke with another student who had a similar problem.  It has 
>>>> to do
>>>> with trying to write to a socket that was closed by the other end. 
>>>> Look
>>>> into handling the SIGPIPE signal.  If you don't have a handler, the 
>>>> system
>>>> kills your process.
>>>>
>>>> --Justin
>>>>
>>>>
>>>> On 1/19/07 5:16 AM, in article eoqgb1$dk0$1@news.Stanford.EDU, "David
>>>> Gobaud" <gobaudd@stanford.edu> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Sometimes when my proxy is processing requests it exits and says 
>>>>> "Broken
>>>>> pipe". Ideas... ? I can't reproduce it reliably.
>>>>>
>>>>> Thank you,
>>>>> David Gobaud
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Reposted: Store-and-forward delay
Date: Sat, 20 Jan 2007 00:29:41 -0800
Lines: 7
Distribution: su
Message-ID: <eosjqt$fo0$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169281693 16128 128.12.134.140 (20 Jan 2007 08:28:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11181

Prof. McKeown said in class that the store-and-forward delay is
negligible. But isn't that delay equal to the transmission delay? And if
we are considering the transmission delay, shouldn't we then consider
the store-and-forward delay?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Sat, 20 Jan 2007 11:29:46 -0800
Lines: 18
Distribution: su
Message-ID: <eotqj6$j01$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169321382 19457 127.0.0.1 (20 Jan 2007 19:29:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eosjqt$fo0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11182

Jad Naous wrote:
> Prof. McKeown said in class that the store-and-forward delay is
> negligible. But isn't that delay equal to the transmission delay? And if
> we are considering the transmission delay, shouldn't we then consider
> the store-and-forward delay?
> 
> Thanks,
> Jad.

The transmission delay IS the store and forward delay.  IE if you were 
traversing from host A to B over n links, and all the links had the same 
bandwidth, then you would have to consider n transmission delays 
(because the packet must be accumulated at each router then sent on to 
the next).  However if you were not accumulating the packet at each 
router before sending it on, IE doing a cut-through router style, then 
you would only consider a single transmission delay over the full route.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Sat, 20 Jan 2007 13:25:37 -0800
Lines: 32
Distribution: su
Message-ID: <eou19n$ohv$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169328247 25151 128.12.134.140 (20 Jan 2007 21:24:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <eotqj6$j01$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11183

If the packet length is L and the link rate is R, when the first bit of
a packet reaches the router, it takes R/L to get the full packet into
the router before we do anything with it. That's the store-and-forward
delay, right?

And then after processing and queuing, when the first bit is ready to go
out on the link, it takes another R/L to put the packet back on the
wire, isn't that the transmission delay? So doesn't a packet experience
2*R/L delays going through a router?

Thanks,
Jad.

David Erickson wrote:
> Jad Naous wrote:
>> Prof. McKeown said in class that the store-and-forward delay is
>> negligible. But isn't that delay equal to the transmission delay? And if
>> we are considering the transmission delay, shouldn't we then consider
>> the store-and-forward delay?
>>
>> Thanks,
>> Jad.
> 
> The transmission delay IS the store and forward delay.  IE if you were
> traversing from host A to B over n links, and all the links had the same
> bandwidth, then you would have to consider n transmission delays
> (because the packet must be accumulated at each router then sent on to
> the next).  However if you were not accumulating the packet at each
> router before sending it on, IE doing a cut-through router style, then
> you would only consider a single transmission delay over the full route.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: collaboration on the problem set
Date: Sat, 20 Jan 2007 14:53:28 -0800
Lines: 3
Distribution: su
Message-ID: <eou6h1$sd8$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df3.stanford.edu
X-Trace: news.Stanford.EDU 1169333601 29096 171.67.77.243 (20 Jan 2007 22:53:21 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11184

Are we allowed to collaborate/discuss on the problem set?


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Sat, 20 Jan 2007 15:12:57 -0800
Lines: 47
Distribution: su
Message-ID: <eou7ll$2m$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU> <eou19n$ohv$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169334774 86 127.0.0.1 (20 Jan 2007 23:12:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eou19n$ohv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11185

 > David Erickson wrote:
 >> Jad Naous wrote:
 >>> Prof. McKeown said in class that the store-and-forward delay is
 >>> negligible. But isn't that delay equal to the transmission delay? 
And if
 >>> we are considering the transmission delay, shouldn't we then consider
 >>> the store-and-forward delay?
 >>>
 >>> Thanks,
 >>> Jad.
 >> The transmission delay IS the store and forward delay.  IE if you were
 >> traversing from host A to B over n links, and all the links had the same
 >> bandwidth, then you would have to consider n transmission delays
 >> (because the packet must be accumulated at each router then sent on to
 >> the next).  However if you were not accumulating the packet at each
 >> router before sending it on, IE doing a cut-through router style, then
 >> you would only consider a single transmission delay over the full route.
 >>
 >> -David

Jad Naous wrote:
> If the packet length is L and the link rate is R, when the first bit of
> a packet reaches the router, it takes R/L to get the full packet into
> the router before we do anything with it. That's the store-and-forward
> delay, right?
> 
> And then after processing and queuing, when the first bit is ready to go
> out on the link, it takes another R/L to put the packet back on the
> wire, isn't that the transmission delay? So doesn't a packet experience
> 2*R/L delays going through a router?
> 
> Thanks,
> Jad.
> 

Its better to think about it from the packets point of view.  Lets 
assume L is the packet size, R is the rate of all of the links in b/s. 
Then the time for the entire packet to make it from origin router to 
router 2 is the transmission delay: L/R + some Propogation delay (Prop). 
  Once at the second router I may experience some processing and 
queueing delay.  Then from router 2 to router 3 the delay is similar as 
from origin to 2, Transmission delay of L/R + Prop, and so it goes 
through each router in series until the end.

Does that make more sense?

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Office Hours
Date: Sat, 20 Jan 2007 15:30:08 -0800
Lines: 6
Distribution: su
Message-ID: <eou8m5$pv$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169335813 831 128.12.133.106 (20 Jan 2007 23:30:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11186

My Office hours have changed to Monday from 12:45 - 2:45. The Wednesday 
hours conflicted with another class I must take.

Sorry for any inconvenience this might have caused.

Paul
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: collaboration on the problem set
Date: Sat, 20 Jan 2007 15:32:29 -0800
Lines: 6
Distribution: su
Message-ID: <eou8qi$pv$2@news.Stanford.EDU>
References: <eou6h1$sd8$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169335954 831 128.12.133.106 (20 Jan 2007 23:32:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eou6h1$sd8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11187

Manj, please read the Logistics handout on the website. It is the first 
one. I won't paste it all here, but the full answer to your question is 
there.

In short, you can generally collaborate but not specifically. For more 
detail see the handout.
.

Path: shelby.stanford.edu!not-for-mail
From: Benjamin Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: watching lectures
Date: Sat, 20 Jan 2007 20:44:13 -0800
Lines: 5
Distribution: su
Message-ID: <eour2u$e8d$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169354654 14605 128.12.94.22 (21 Jan 2007 04:44:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11188

I can't seem to watch lectures online. Anyone else having this problem? 
I can't exactly watch it in person, since I'm also in CS161, which isn't 
offered online...

Ben
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 #6
Date: Sat, 20 Jan 2007 23:19:31 -0800
Lines: 15
Distribution: su
Message-ID: <eov466$k43$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1169363974 20611 128.12.81.44 (21 Jan 2007 07:19:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11189

Hi,

I'm finding #6 on PS1 confusing.

It states that a packet is buffered on average every 10ms by the router. 
Does this mean a packet arrives on average every 10ms? If not, I'm having 
trouble seeing how to approach part a since we are not told the bandwidth of 
the router. Also, for b, I don't see how to calculate the average delay of a 
packet in the router. Is this the same as the queuing delay and if so, don't 
we need to know the bandwidth to calculate it?

Thank you,
David Gobaud 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: watching lectures
Date: Sun, 21 Jan 2007 00:03:33 -0800
Lines: 20
Distribution: su
Message-ID: <C1D85E55.78B7%jpettit@stanford.edu>
References: <eour2u$e8d$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169366615 25342 127.0.0.1 (21 Jan 2007 08:03:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: watching lectures
Thread-Index: Acc9MqUL44O0iqklEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11190

I just tried for one of my other classes, and it's not working either.  My
guess is that SCPD is having a temporary problem.

By the way, since Professor McKeown doesn't allow students to take alternate
midterms or final exams, you should make sure you won't have a conflict with
CS161.

--Justin


On 1/20/07 8:44 PM, in article eour2u$e8d$1@news.Stanford.EDU, "Benjamin
Nham" <nham@stanford.edu> wrote:

> I can't seem to watch lectures online. Anyone else having this problem?
> I can't exactly watch it in person, since I'm also in CS161, which isn't
> offered online...
> 
> Ben


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: problem 9
Date: Sun, 21 Jan 2007 17:36:09 -0800
Lines: 18
Distribution: su
Message-ID: <ep14ee$fhn$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1169429774 15927 128.12.197.229 (22 Jan 2007 01:36:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11191

Part a) iii)
    A(t) = 200 + 2t.  At t=0, we have 200 bits in the queue.  Each of those 
bits has a different queue delay: bit 0 goes out right way, whereas bit 199 
has to wait a while.  So, d(t) at t = 0 is different depending on which of 
the 200 bits you are referring to.  How do you want us to express this? 
Alternatively, we can ignore the first 199 bits and just take the worst 
delay at t = 0.

Part b)
    Is it ok to express the answer in terms of some variable (say "p") that 
represents the packet number, where "p" is an integer ranging from 0 to 
infinity?

Thanks,
Tom



.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 #9
Date: Sun, 21 Jan 2007 17:48:42 -0800
Lines: 19
Distribution: su
Message-ID: <ep155u$g41$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1169430526 16513 128.12.104.53 (22 Jan 2007 01:48:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11192

Hello--

Two questions on question 9 on PS1:

(1) Why is the time-average queue occupancy not a function of t? Isn't 
the point of this function to tell you the average queue occupancy from 
t = 0 until some later time t?

(2) In the discrete arrival case, does a packet enter the queue as soon 
as the first bit of the packet is recieved or when the entire packet is 
recieved? Likewise, does the packet leave the queue when the first bit 
is transmitted or when the last bit is? The basic question is: when 
working with these simplified router models, does each link have a 
local buffer of the current packet it's dealing with or are all 
operations done directly on the queue?

Thanks,
Peter

.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 #7
Date: Sun, 21 Jan 2007 21:27:58 -0800
Lines: 8
Distribution: su
Message-ID: <ep1i0n$pmm$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab4082f9.stanford.edu
X-Trace: news.Stanford.EDU 1169443671 26326 171.64.130.249 (22 Jan 2007 05:27:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11193

In #7, no information has been provided for calculating the propogation 
delay.

Should we ignore propogation delay, assuming that it is negligible compared 
to the transmission time, when calculating the total time required to 
transmit the file? 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 #6
Date: Sun, 21 Jan 2007 22:13:18 -0800
Lines: 4
Distribution: su
Message-ID: <ep1kln$rkf$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab4082f9.stanford.edu
X-Trace: news.Stanford.EDU 1169446391 28303 171.64.130.249 (22 Jan 2007 06:13:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11194

In #6, part b), should we assume the same average queue occupancy of 
128kbytes, even when the router drops 15% of the incoming packets? 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Mon, 22 Jan 2007 07:59:52 -0800
Lines: 55
Distribution: su
Message-ID: <ep2muv$3ov$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU> <eou19n$ohv$1@news.Stanford.EDU> <eou7ll$2m$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169481504 3871 128.12.134.140 (22 Jan 2007 15:58:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <eou7ll$2m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11195

David Erickson wrote:
>> David Erickson wrote:
>>> Jad Naous wrote:
>>>> Prof. McKeown said in class that the store-and-forward delay is
>>>> negligible. But isn't that delay equal to the transmission delay?
> And if
>>>> we are considering the transmission delay, shouldn't we then consider
>>>> the store-and-forward delay?
>>>>
>>>> Thanks,
>>>> Jad.
>>> The transmission delay IS the store and forward delay.  IE if you were
>>> traversing from host A to B over n links, and all the links had the same
>>> bandwidth, then you would have to consider n transmission delays
>>> (because the packet must be accumulated at each router then sent on to
>>> the next).  However if you were not accumulating the packet at each
>>> router before sending it on, IE doing a cut-through router style, then
>>> you would only consider a single transmission delay over the full route.
>>>
>>> -David
> 
> Jad Naous wrote:
>> If the packet length is L and the link rate is R, when the first bit of
>> a packet reaches the router, it takes R/L to get the full packet into
>> the router before we do anything with it. That's the store-and-forward
>> delay, right?
>>
>> And then after processing and queuing, when the first bit is ready to go
>> out on the link, it takes another R/L to put the packet back on the
>> wire, isn't that the transmission delay? So doesn't a packet experience
>> 2*R/L delays going through a router?
>>
>> Thanks,
>> Jad.
>>
> 
> Its better to think about it from the packets point of view.  Lets
> assume L is the packet size, R is the rate of all of the links in b/s.
> Then the time for the entire packet to make it from origin router to
> router 2 is the transmission delay: L/R + some Propogation delay (Prop).
>  Once at the second router I may experience some processing and queueing
> delay.  Then from router 2 to router 3 the delay is similar as from
> origin to 2, Transmission delay of L/R + Prop, and so it goes through
> each router in series until the end.
> 
> Does that make more sense?
> 
> -David

So the packet doesn't experience any delay while being read off the
wire? I thought it would since it has to be read completely before being
processed.

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Lin Kuang" <lkuang@cisco.com>
Newsgroups: su.class.cs244a
Subject: PS problem 1d
Date: Mon, 22 Jan 2007 11:42:49 -0800
Lines: 12
Distribution: su
Message-ID: <ep343p$f6o$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169494969 15576 127.0.0.1 (22 Jan 2007 19:42:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Xref: shelby.stanford.edu su.class.cs244a:11196

Hi TAs,

for HW problem 1d, something is not very clear to me:

do we assume the first date of class during those five years are always the
same, or they can be different day in each year?

Thank you for your input.

Lin


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Mon, 22 Jan 2007 13:35:56 -0800
Lines: 62
Distribution: su
Message-ID: <ep3ao1$kos$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU> <eou19n$ohv$1@news.Stanford.EDU> <eou7ll$2m$1@news.Stanford.EDU> <ep2muv$3ov$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169501761 21276 171.64.74.36 (22 Jan 2007 21:36:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
In-Reply-To: <ep2muv$3ov$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11197

Jad Naous wrote:
> David Erickson wrote:
>>> David Erickson wrote:
>>>> Jad Naous wrote:
>>>>> Prof. McKeown said in class that the store-and-forward delay is
>>>>> negligible. But isn't that delay equal to the transmission delay?
>> And if
>>>>> we are considering the transmission delay, shouldn't we then consider
>>>>> the store-and-forward delay?
>>>>>
>>>>> Thanks,
>>>>> Jad.
>>>> The transmission delay IS the store and forward delay.  IE if you were
>>>> traversing from host A to B over n links, and all the links had the same
>>>> bandwidth, then you would have to consider n transmission delays
>>>> (because the packet must be accumulated at each router then sent on to
>>>> the next).  However if you were not accumulating the packet at each
>>>> router before sending it on, IE doing a cut-through router style, then
>>>> you would only consider a single transmission delay over the full route.
>>>>
>>>> -David
>> Jad Naous wrote:
>>> If the packet length is L and the link rate is R, when the first bit of
>>> a packet reaches the router, it takes R/L to get the full packet into
>>> the router before we do anything with it. That's the store-and-forward
>>> delay, right?
>>>
>>> And then after processing and queuing, when the first bit is ready to go
>>> out on the link, it takes another R/L to put the packet back on the
>>> wire, isn't that the transmission delay? So doesn't a packet experience
>>> 2*R/L delays going through a router?
>>>
>>> Thanks,
>>> Jad.
>>>
>> Its better to think about it from the packets point of view.  Lets
>> assume L is the packet size, R is the rate of all of the links in b/s.
>> Then the time for the entire packet to make it from origin router to
>> router 2 is the transmission delay: L/R + some Propogation delay (Prop).
>>  Once at the second router I may experience some processing and queueing
>> delay.  Then from router 2 to router 3 the delay is similar as from
>> origin to 2, Transmission delay of L/R + Prop, and so it goes through
>> each router in series until the end.
>>
>> Does that make more sense?
>>
>> -David
> 
> So the packet doesn't experience any delay while being read off the
> wire? I thought it would since it has to be read completely before being
> processed.
> 
> Thanks,
> Jad.

I got it, Paul explained it. My wrong assumption was that the packet has
to be dumped on the wire before it started moving. When looking at it in
terms of bits, it makes more sense.

Thanks, David.

Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #6
Date: Mon, 22 Jan 2007 13:46:55 -0800
Lines: 9
Distribution: su
Message-ID: <ep3bcf$lbp$1@news.Stanford.EDU>
References: <eov466$k43$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169502415 21881 171.64.15.50 (22 Jan 2007 21:46:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <eov466$k43$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11198

> It states that a packet is buffered on average every 10ms by the router. 
> Does this mean a packet arrives on average every 10ms? 
It isn't buffered EVERY 10ms, it is buffered FOR 10ms.

> Also, for b, I don't see how to calculate the average delay of a 
> packet in the router. Is this the same as the queuing delay and if so, don't 
> we need to know the bandwidth to calculate it?
Well, it isn't the same since we have a 15% drop rate. Is it higher or 
lower and if we didn't have the drops? :)
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #6
Date: Mon, 22 Jan 2007 13:47:38 -0800
Lines: 4
Distribution: su
Message-ID: <ep3bdq$lbp$2@news.Stanford.EDU>
References: <ep1kln$rkf$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169502458 21881 171.64.15.50 (22 Jan 2007 21:47:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <ep1kln$rkf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11199

manj wrote:
> In #6, part b), should we assume the same average queue occupancy of 
> 128kbytes, even when the router drops 15% of the incoming packets? 
Assume that the amount of incoming data is still the same as in part a).
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: problem 9
Date: Mon, 22 Jan 2007 13:51:17 -0800
Lines: 18
Distribution: su
Message-ID: <ep3bkm$lkp$1@news.Stanford.EDU>
References: <ep14ee$fhn$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169502678 22169 171.64.15.50 (22 Jan 2007 21:51:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <ep14ee$fhn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11200

Tom Deane wrote:
> Part a) iii)
>     A(t) = 200 + 2t.  At t=0, we have 200 bits in the queue.  Each of those 
> bits has a different queue delay: bit 0 goes out right way, whereas bit 199 
> has to wait a while.  So, d(t) at t = 0 is different depending on which of 
> the 200 bits you are referring to.  How do you want us to express this? 
> Alternatively, we can ignore the first 199 bits and just take the worst 
> delay at t = 0.
Making a function that does that isn't too hard is it? Please write the 
function based on time, not ignoring parts of the packets.

> 
> Part b)
>     Is it ok to express the answer in terms of some variable (say "p") that 
> represents the packet number, where "p" is an integer ranging from 0 to 
> infinity?

Big hint: I don't see why you would need p :)
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #9
Date: Mon, 22 Jan 2007 13:55:31 -0800
Lines: 25
Distribution: su
Message-ID: <ep3bsj$lq1$1@news.Stanford.EDU>
References: <ep155u$g41$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169502931 22337 171.64.15.50 (22 Jan 2007 21:55:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <ep155u$g41$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11201

Peter Pawlowski wrote:
> Hello--
> 
> Two questions on question 9 on PS1:
> 
> (1) Why is the time-average queue occupancy not a function of t? Isn't 
> the point of this function to tell you the average queue occupancy from 
> t = 0 until some later time t?
Well, X(t) is a function of t. If you are talking about X bar, then just 
take the average from time t=0 to time t=infinity.

> 
> (2) In the discrete arrival case, does a packet enter the queue as soon 
> as the first bit of the packet is recieved or when the entire packet is 
> recieved? Likewise, does the packet leave the queue when the first bit 
> is transmitted or when the last bit is? The basic question is: when 
> working with these simplified router models, does each link have a local 
> buffer of the current packet it's dealing with or are all operations 
> done directly on the queue?
Don't think too much about multiple queues, local buffers, etc.. Just 
read the preamble of the question:

"The router is a store-and-forward device, which means that arriving 
packets are completely stored before starting transmission on the 
outgoing link."
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #7
Date: Mon, 22 Jan 2007 13:57:56 -0800
Lines: 11
Distribution: su
Message-ID: <ep3c14$lq1$2@news.Stanford.EDU>
References: <ep1i0n$pmm$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169503076 22337 171.64.15.50 (22 Jan 2007 21:57:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <ep1i0n$pmm$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11202

manj wrote:
> In #7, no information has been provided for calculating the propogation 
> delay.
> 
> Should we ignore propogation delay, assuming that it is negligible compared 
> to the transmission time, when calculating the total time required to 
> transmit the file? 
> 
All you need is that:

"You are given a communication link that transmits R bits per second."
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA1 Grading
Date: Mon, 22 Jan 2007 14:05:57 -0800
Lines: 25
Distribution: su
Message-ID: <C1DA7545.7931%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169503559 22844 127.0.0.1 (22 Jan 2007 22:05:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA1 Grading
Thread-Index: Acc+cX4HvMee5qpkEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11203

As was pointed out by some of you, there was differing information about how
PA1 was going to be graded.  Here's the official word:

    - The public grading script is worth eight points, as the grading script
and assignment indicated.  We know that some of the pages with dynamic
content were returning different results.  If the script indicates that you
failed a site, we will look at the diff and determine where the fault lies.
This should prevent problems due to spurious errors.

    - The private grading script is worth one point.  There are four tests.
If you pass all four, you will get the point.  If you pass two or three, you
will get a half point.  If you pass none or one, you will not get a point.
None of these tests use dynamic content.

    - The style portion is worth one point.  It is possible to get the full
point, a half, or zero.  We're just checking that you're following good
style.  If you don't get the full point, then all three of us will need to
sign off on it.  This should significantly reduce the variance among TAs.  A
different TA will grade your next assignment, which should help more.

Hopefully that clears things up.  Let me know if you have any more
questions.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS problem 1d
Date: Mon, 22 Jan 2007 14:58:34 -0800
Lines: 9
Distribution: su
Message-ID: <ep3fiq$oti$1@news.Stanford.EDU>
References: <ep343p$f6o$1@news.Stanford.EDU>
NNTP-Posting-Host: raptor10.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169506714 25522 171.64.15.50 (22 Jan 2007 22:58:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060427 Debian/1.7.13-0ubuntu5.10
X-Accept-Language: en
In-Reply-To: <ep343p$f6o$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11204

> do we assume the first date of class during those five years are always the
> same, or they can be different day in each year?

Well, think about the two cases. What if the first day of class changed 
all the time? Would things change if the same student repeated? What 
about if the first day of class was on the same date each year. Would 
things change if the same student repeated?

Think about which way makes more sense.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Class Registration
Date: Mon, 22 Jan 2007 15:20:56 -0800
Lines: 10
Distribution: su
Message-ID: <C1DA86D8.794B%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169508056 26795 127.0.0.1 (22 Jan 2007 23:20:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Class Registration
Thread-Index: Acc+e/ekNjvtIqpvEdui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11205

We are going to keep track of your grades with the eeclass system.  Only a
small number of students have registered with the system.  If you have not
done so yet, please do it by tomorrow.  You can register by following the
link titled "Grades & Solutions" on the front page and then clicking
"Students".

Thanks!

--Justin

.

Path: shelby.stanford.edu!myth10.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS#1 problem 9
Date: Mon, 22 Jan 2007 15:42:15 -0800
Lines: 11
Distribution: su
Message-ID: <Pine.LNX.4.44.0701221539350.16959-100000@myth10.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1169509336 27865 171.64.15.6 (22 Jan 2007 23:42:16 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11206

Hi,

1. What's the unit of the function A(t)? I thought it was the number of
packets, but I don't see the size of packet in the writeup.

2. Could you define what time-average queue occupancy is?


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS#1 problem 9
Date: Mon, 22 Jan 2007 16:48:49 -0800
Lines: 14
Distribution: su
Message-ID: <ep3m1b$uv$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701221539350.16959-100000@myth10.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169513323 991 127.0.0.1 (23 Jan 2007 00:48:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0701221539350.16959-100000@myth10.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11207

Seung Hoon Choi wrote:
> Hi,
> 
> 1. What's the unit of the function A(t)? I thought it was the number of
> packets, but I don't see the size of packet in the writeup.

A(t) is the number of bits arriving at time t.

> 2. Could you define what time-average queue occupancy is?

The average queue occupancy over some time period.  In this case 0 to 
infinity.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Mon, 22 Jan 2007 17:24:02 -0800
Lines: 77
Distribution: su
Message-ID: <ep3o3j$2kd$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU> <eou19n$ohv$1@news.Stanford.EDU> <eou7ll$2m$1@news.Stanford.EDU> <ep2muv$3ov$1@news.Stanford.EDU> <ep3ao1$kos$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169515443 2701 127.0.0.1 (23 Jan 2007 01:24:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11208

Jad could you explain to us what Paul said to you about transmission delay? 
Is the transmission delay referring to the time you wait for receiving the 
whole packet before putting it on the wire, or does it refer to given the 
whole packet is already at the sender side and at the sender how long does 
it take to put it on the wire?

Alex

"Jad Naous" <jnaous@stanford.edu> wrote in message 
news:ep3ao1$kos$1@news.Stanford.EDU...
> Jad Naous wrote:
>> David Erickson wrote:
>>>> David Erickson wrote:
>>>>> Jad Naous wrote:
>>>>>> Prof. McKeown said in class that the store-and-forward delay is
>>>>>> negligible. But isn't that delay equal to the transmission delay?
>>> And if
>>>>>> we are considering the transmission delay, shouldn't we then consider
>>>>>> the store-and-forward delay?
>>>>>>
>>>>>> Thanks,
>>>>>> Jad.
>>>>> The transmission delay IS the store and forward delay.  IE if you were
>>>>> traversing from host A to B over n links, and all the links had the 
>>>>> same
>>>>> bandwidth, then you would have to consider n transmission delays
>>>>> (because the packet must be accumulated at each router then sent on to
>>>>> the next).  However if you were not accumulating the packet at each
>>>>> router before sending it on, IE doing a cut-through router style, then
>>>>> you would only consider a single transmission delay over the full 
>>>>> route.
>>>>>
>>>>> -David
>>> Jad Naous wrote:
>>>> If the packet length is L and the link rate is R, when the first bit of
>>>> a packet reaches the router, it takes R/L to get the full packet into
>>>> the router before we do anything with it. That's the store-and-forward
>>>> delay, right?
>>>>
>>>> And then after processing and queuing, when the first bit is ready to 
>>>> go
>>>> out on the link, it takes another R/L to put the packet back on the
>>>> wire, isn't that the transmission delay? So doesn't a packet experience
>>>> 2*R/L delays going through a router?
>>>>
>>>> Thanks,
>>>> Jad.
>>>>
>>> Its better to think about it from the packets point of view.  Lets
>>> assume L is the packet size, R is the rate of all of the links in b/s.
>>> Then the time for the entire packet to make it from origin router to
>>> router 2 is the transmission delay: L/R + some Propogation delay (Prop).
>>>  Once at the second router I may experience some processing and queueing
>>> delay.  Then from router 2 to router 3 the delay is similar as from
>>> origin to 2, Transmission delay of L/R + Prop, and so it goes through
>>> each router in series until the end.
>>>
>>> Does that make more sense?
>>>
>>> -David
>>
>> So the packet doesn't experience any delay while being read off the
>> wire? I thought it would since it has to be read completely before being
>> processed.
>>
>> Thanks,
>> Jad.
>
> I got it, Paul explained it. My wrong assumption was that the packet has
> to be dumped on the wire before it started moving. When looking at it in
> terms of bits, it makes more sense.
>
> Thanks, David.
>
> Jad. 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: PS#1 problem 9
Date: Tue, 23 Jan 2007 01:35:46 +0000 (UTC)
Lines: 19
Distribution: su
Message-ID: <ep3opi$2t6$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701221539350.16959-100000@myth10.Stanford.EDU> <ep3m1b$uv$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine40.stanford.edu
X-Trace: news.Stanford.EDU 1169516146 2982 171.64.15.115 (23 Jan 2007 01:35:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:11209

David Erickson <derickso@stanford.edu> wrote:
> Seung Hoon Choi wrote:
> > Hi,
> > 
> > 1. What's the unit of the function A(t)? I thought it was the number of
> > packets, but I don't see the size of packet in the writeup.

> A(t) is the number of bits arriving at time t.

On slide 33, it's mentioned A(t) is number of arrivals in interval [0,t] not at time t.
Please clarify.
Dinesh

> > 2. Could you define what time-average queue occupancy is?

> The average queue occupancy over some time period.  In this case 0 to 
> infinity.

> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Reposted: Store-and-forward delay
Date: Mon, 22 Jan 2007 17:41:40 -0800
Lines: 96
Distribution: su
Message-ID: <ep3p4p$3c4$1@news.Stanford.EDU>
References: <eosjqt$fo0$1@news.Stanford.EDU> <eotqj6$j01$1@news.Stanford.EDU> <eou19n$ohv$1@news.Stanford.EDU> <eou7ll$2m$1@news.Stanford.EDU> <ep2muv$3ov$1@news.Stanford.EDU> <ep3ao1$kos$1@news.Stanford.EDU> <ep3o3j$2kd$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169516505 3460 171.64.74.36 (23 Jan 2007 01:41:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
In-Reply-To: <ep3o3j$2kd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11210

That's what confused me. Here's what Prof. McKeown had to say about this:

-----------------------
The first bit arrives [To the next hop] after PROP, the last bit arrives
TRANSP later. At this point, the whole packet is in the router and it
can process the packet. If the processing time is zero, it can start
putting the first bit on the outgoing link.

So.... TRANSP is paid for just once.

If the packet is stored-and-forwarded several times internally in the
switch/router, then it could be that we need several TRANSPs (but all
based on the internal rate of the router, which we don't know).
---------------------

I don't want to say much more because I might explain it incorrectly and
confuse you more. If you are confused about it, I would ask Paul.

Jad.

Alex wrote:
> Jad could you explain to us what Paul said to you about transmission delay? 
> Is the transmission delay referring to the time you wait for receiving the 
> whole packet before putting it on the wire, or does it refer to given the 
> whole packet is already at the sender side and at the sender how long does 
> it take to put it on the wire?
> 
> Alex
> 
> "Jad Naous" <jnaous@stanford.edu> wrote in message 
> news:ep3ao1$kos$1@news.Stanford.EDU...
>> Jad Naous wrote:
>>> David Erickson wrote:
>>>>> David Erickson wrote:
>>>>>> Jad Naous wrote:
>>>>>>> Prof. McKeown said in class that the store-and-forward delay is
>>>>>>> negligible. But isn't that delay equal to the transmission delay?
>>>> And if
>>>>>>> we are considering the transmission delay, shouldn't we then consider
>>>>>>> the store-and-forward delay?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jad.
>>>>>> The transmission delay IS the store and forward delay.  IE if you were
>>>>>> traversing from host A to B over n links, and all the links had the 
>>>>>> same
>>>>>> bandwidth, then you would have to consider n transmission delays
>>>>>> (because the packet must be accumulated at each router then sent on to
>>>>>> the next).  However if you were not accumulating the packet at each
>>>>>> router before sending it on, IE doing a cut-through router style, then
>>>>>> you would only consider a single transmission delay over the full 
>>>>>> route.
>>>>>>
>>>>>> -David
>>>> Jad Naous wrote:
>>>>> If the packet length is L and the link rate is R, when the first bit of
>>>>> a packet reaches the router, it takes R/L to get the full packet into
>>>>> the router before we do anything with it. That's the store-and-forward
>>>>> delay, right?
>>>>>
>>>>> And then after processing and queuing, when the first bit is ready to 
>>>>> go
>>>>> out on the link, it takes another R/L to put the packet back on the
>>>>> wire, isn't that the transmission delay? So doesn't a packet experience
>>>>> 2*R/L delays going through a router?
>>>>>
>>>>> Thanks,
>>>>> Jad.
>>>>>
>>>> Its better to think about it from the packets point of view.  Lets
>>>> assume L is the packet size, R is the rate of all of the links in b/s.
>>>> Then the time for the entire packet to make it from origin router to
>>>> router 2 is the transmission delay: L/R + some Propogation delay (Prop).
>>>>  Once at the second router I may experience some processing and queueing
>>>> delay.  Then from router 2 to router 3 the delay is similar as from
>>>> origin to 2, Transmission delay of L/R + Prop, and so it goes through
>>>> each router in series until the end.
>>>>
>>>> Does that make more sense?
>>>>
>>>> -David
>>> So the packet doesn't experience any delay while being read off the
>>> wire? I thought it would since it has to be read completely before being
>>> processed.
>>>
>>> Thanks,
>>> Jad.
>> I got it, Paul explained it. My wrong assumption was that the packet has
>> to be dumped on the wire before it started moving. When looking at it in
>> terms of bits, it makes more sense.
>>
>> Thanks, David.
>>
>> Jad. 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS#1 problem 9
Date: Mon, 22 Jan 2007 17:48:30 -0800
Lines: 18
Distribution: su
Message-ID: <ep3ph8$3h3$3@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701221539350.16959-100000@myth10.Stanford.EDU> <ep3m1b$uv$1@news.Stanford.EDU> <ep3opi$2t6$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169516904 3619 127.0.0.1 (23 Jan 2007 01:48:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep3opi$2t6$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11212

Dinesh Gupta wrote:
> David Erickson <derickso@stanford.edu> wrote:
>> Seung Hoon Choi wrote:
>>> Hi,
>>>
>>> 1. What's the unit of the function A(t)? I thought it was the number of
>>> packets, but I don't see the size of packet in the writeup.
> 
>> A(t) is the number of bits arriving at time t.
> 
> On slide 33, it's mentioned A(t) is number of arrivals in interval [0,t] not at time t.
> Please clarify.
> Dinesh

It is cumulative per what the assignment states, "cumulative arrival 
processes, A(t)".

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Alex" <axle@sonic.net>
Newsgroups: su.class.cs244a
Subject: Transmission Delay Interpretation
Date: Mon, 22 Jan 2007 18:27:45 -0800
Lines: 8
Distribution: su
Message-ID: <ep3rr2$5h0$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169519266 5664 127.0.0.1 (23 Jan 2007 02:27:46 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11213

Is the transmission delay referring to the time you wait for receiving the
whole packet before putting it on the wire, or does it refer to given the
whole packet is already at the sender side and at the sender how long does
it take to put it on the wire?

Alex


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Transmission Delay Interpretation
Date: Mon, 22 Jan 2007 18:42:04 -0800
Lines: 14
Distribution: su
Message-ID: <ep3sll$69a$1@news.Stanford.EDU>
References: <ep3rr2$5h0$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169520117 6442 127.0.0.1 (23 Jan 2007 02:41:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep3rr2$5h0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11214

Alex wrote:
> Is the transmission delay referring to the time you wait for receiving the
> whole packet before putting it on the wire, or does it refer to given the
> whole packet is already at the sender side and at the sender how long does
> it take to put it on the wire?
> 
> Alex
> 
> 

The transmission delay is the time it takes to put the full packet onto 
the wire.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #6
Date: Mon, 22 Jan 2007 18:46:35 -0800
Lines: 25
Distribution: su
Message-ID: <ep3st2$6ji$1@news.Stanford.EDU>
References: <ep1kln$rkf$1@news.Stanford.EDU> <ep3bdq$lbp$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169520354 6770 127.0.0.1 (23 Jan 2007 02:45:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11215

That does not answer the question.

The effect of changing the arrival rate on average queue length depends on 
the incoming (and outgoing) process.  For instance, changing the arrival 
rate on a constant bit rate pattern modifies the length of the queue in a 
certain manner (yes, I know the manner), but lowering the bit rate on a 
Poisson process would lessen the queue length more than the constant bit 
rate process (I'd have to work that one out).  Burstiness and variance both 
affect the reaction to lessening the incoming traffic.  More variable 
traffic sees better improvement for the same drop in traffic (because it was 
much worse to begin with).

Sincerely,
Randy Jennings

The squirrels are your friends!

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:ep3bdq$lbp$2@news.Stanford.EDU...
> manj wrote:
>> In #6, part b), should we assume the same average queue occupancy of 
>> 128kbytes, even when the router drops 15% of the incoming packets?
> Assume that the amount of incoming data is still the same as in part a). 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #6
Date: Mon, 22 Jan 2007 19:07:33 -0800
Lines: 39
Distribution: su
Message-ID: <ep3u4c$85d$1@news.Stanford.EDU>
References: <ep1kln$rkf$1@news.Stanford.EDU> <ep3bdq$lbp$2@news.Stanford.EDU> <ep3st2$6ji$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169521612 8365 127.0.0.1 (23 Jan 2007 03:06:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11216

Yeah, that was a stupid comment on the constant bit rate process.  There are 
a lot of those...

If we can assume the arrival process and the departure process are Poisson, 
I am happy...

Sincerely,
Randy Jennings

The squirrels are your friends!
"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:ep3st2$6ji$1@news.Stanford.EDU...
> That does not answer the question.
>
> The effect of changing the arrival rate on average queue length depends on 
> the incoming (and outgoing) process.  For instance, changing the arrival 
> rate on a constant bit rate pattern modifies the length of the queue in a 
> certain manner (yes, I know the manner), but lowering the bit rate on a 
> Poisson process would lessen the queue length more than the constant bit 
> rate process (I'd have to work that one out).  Burstiness and variance 
> both affect the reaction to lessening the incoming traffic.  More variable 
> traffic sees better improvement for the same drop in traffic (because it 
> was much worse to begin with).
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
>
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:ep3bdq$lbp$2@news.Stanford.EDU...
>> manj wrote:
>>> In #6, part b), should we assume the same average queue occupancy of 
>>> 128kbytes, even when the router drops 15% of the incoming packets?
>> Assume that the amount of incoming data is still the same as in part a).
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: problem 9
Date: Mon, 22 Jan 2007 19:13:55 -0800
Lines: 49
Distribution: su
Message-ID: <ep3uho$8ln$1@news.Stanford.EDU>
References: <ep14ee$fhn$1@news.Stanford.EDU> <ep3bkm$lkp$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1169522040 8887 128.12.197.229 (23 Jan 2007 03:14:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11217

Part a)
I don't see how you can express the delay d(t) at t=0 when there are 200 
different delays at t = 0.  The only way to do this would be to introduce a 
new variable representing the bit number that you are deferring to and say 
something like
d ( t ) = bit_number * some_constant   for t = 0
d ( t ) = something else, for other ts
However you mention that we need to express it in terms of time. Please 
clarify.


Part b)
"Big hint: I don't see why you would need p"

I would need P because the only way I can see of modeling this recurring 
event is to say what happens in a 1-second interval.  I don't want to say 
what happens between second 0 and second 1 because that doesn't tell me what 
happens later.  Instead, I want to say what happens between second P and 
second P+1 where P goes from 0 to infinity... or equivalently, what happens 
between the arrival of packet P and packet P+1.  Could you give me a hint as 
to your way of getting rid of this variable P?






"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:ep3bkm$lkp$1@news.Stanford.EDU...
> Tom Deane wrote:
>> Part a) iii)
>>     A(t) = 200 + 2t.  At t=0, we have 200 bits in the queue.  Each of 
>> those bits has a different queue delay: bit 0 goes out right way, whereas 
>> bit 199 has to wait a while.  So, d(t) at t = 0 is different depending on 
>> which of the 200 bits you are referring to.  How do you want us to 
>> express this? Alternatively, we can ignore the first 199 bits and just 
>> take the worst delay at t = 0.
> Making a function that does that isn't too hard is it? Please write the 
> function based on time, not ignoring parts of the packets.
>
>>
>> Part b)
>>     Is it ok to express the answer in terms of some variable (say "p") 
>> that represents the packet number, where "p" is an integer ranging from 0 
>> to infinity?
>
> Big hint: I don't see why you would need p :) 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: problem 9
Date: Mon, 22 Jan 2007 19:22:32 -0800
Lines: 17
Distribution: su
Message-ID: <ep3v0f$958$1@news.Stanford.EDU>
References: <ep14ee$fhn$1@news.Stanford.EDU> <ep3bkm$lkp$1@news.Stanford.EDU> <ep3uho$8ln$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169522511 9384 127.0.0.1 (23 Jan 2007 03:21:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11218

> Part a)
> I don't see how you can express the delay d(t) at t=0 when there are 200 
> different delays at t = 0.  The only way to do this would be to introduce 
> a new variable representing the bit number that you are deferring to and 
> say something like
> d ( t ) = bit_number * some_constant   for t = 0
> d ( t ) = something else, for other ts
> However you mention that we need to express it in terms of time. Please 
> clarify.
I'd recommend looking at slide 37 of H3.  It helped me with this.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: problem 9
Date: Mon, 22 Jan 2007 19:29:46 -0800
Lines: 24
Distribution: su
Message-ID: <ep3vff$9ao$1@news.Stanford.EDU>
References: <ep14ee$fhn$1@news.Stanford.EDU> <ep3bkm$lkp$1@news.Stanford.EDU> <ep3uho$8ln$1@news.Stanford.EDU> <ep3v0f$958$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1169522991 9560 128.12.197.229 (23 Jan 2007 03:29:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11219

Slide 37 has a train of bits arriving one at a time at some given rate.  As 
opposed to this question which has 200 bits at t = 0.


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:ep3v0f$958$1@news.Stanford.EDU...
>> Part a)
>> I don't see how you can express the delay d(t) at t=0 when there are 200 
>> different delays at t = 0.  The only way to do this would be to introduce 
>> a new variable representing the bit number that you are deferring to and 
>> say something like
>> d ( t ) = bit_number * some_constant   for t = 0
>> d ( t ) = something else, for other ts
>> However you mention that we need to express it in terms of time. Please 
>> clarify.
> I'd recommend looking at slide 37 of H3.  It helped me with this.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #9
Date: Mon, 22 Jan 2007 19:52:51 -0800
Lines: 23
Distribution: su
Message-ID: <ep40pa$act$1@news.Stanford.EDU>
References: <ep155u$g41$1@news.Stanford.EDU> <ep3bsj$lq1$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169524331 10653 127.0.0.1 (23 Jan 2007 03:52:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11220

>> (2) In the discrete arrival case, does a packet enter the queue as soon 
>> as the first bit of the packet is recieved or when the entire packet is 
>> recieved? Likewise, does the packet leave the queue when the first bit is 
>> transmitted or when the last bit is? The basic question is: when working 
>> with these simplified router models, does each link have a local buffer 
>> of the current packet it's dealing with or are all operations done 
>> directly on the queue?
> Don't think too much about multiple queues, local buffers, etc.. Just read 
> the preamble of the question:
>
> "The router is a store-and-forward device, which means that arriving 
> packets are completely stored before starting transmission on the outgoing 
> link."

I think he means should our D(t) remain in terms of bits, or should it be in 
terms of packets?  I would think in terms of bits (per slide 37).

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 #9
Date: Mon, 22 Jan 2007 20:00:28 -0800
Lines: 26
Distribution: su
Message-ID: <ep418l$alf$1@news.Stanford.EDU>
References: <ep155u$g41$1@news.Stanford.EDU> <ep3bsj$lq1$1@news.Stanford.EDU> <ep40pa$act$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169524821 10927 127.0.0.1 (23 Jan 2007 04:00:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep40pa$act$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11221

Randy Jennings wrote:
>>> (2) In the discrete arrival case, does a packet enter the queue as soon 
>>> as the first bit of the packet is recieved or when the entire packet is 
>>> recieved? Likewise, does the packet leave the queue when the first bit is 
>>> transmitted or when the last bit is? The basic question is: when working 
>>> with these simplified router models, does each link have a local buffer 
>>> of the current packet it's dealing with or are all operations done 
>>> directly on the queue?
>> Don't think too much about multiple queues, local buffers, etc.. Just read 
>> the preamble of the question:
>>
>> "The router is a store-and-forward device, which means that arriving 
>> packets are completely stored before starting transmission on the outgoing 
>> link."
> 
> I think he means should our D(t) remain in terms of bits, or should it be in 
> terms of packets?  I would think in terms of bits (per slide 37).
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 

Correct.
-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: problem 9
Date: Mon, 22 Jan 2007 20:38:35 -0800
Lines: 30
Distribution: su
Message-ID: <ep43f1$cbc$1@news.Stanford.EDU>
References: <ep14ee$fhn$1@news.Stanford.EDU> <ep3bkm$lkp$1@news.Stanford.EDU> <ep3uho$8ln$1@news.Stanford.EDU> <ep3v0f$958$1@news.Stanford.EDU> <ep3vff$9ao$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169527073 12652 127.0.0.1 (23 Jan 2007 04:37:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11222

Okay.  Then look at the definition of d(t) on slide 36.

"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:ep3vff$9ao$1@news.Stanford.EDU...
> Slide 37 has a train of bits arriving one at a time at some given rate. 
> As opposed to this question which has 200 bits at t = 0.
>
>
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:ep3v0f$958$1@news.Stanford.EDU...
>>> Part a)
>>> I don't see how you can express the delay d(t) at t=0 when there are 200 
>>> different delays at t = 0.  The only way to do this would be to 
>>> introduce a new variable representing the bit number that you are 
>>> deferring to and say something like
>>> d ( t ) = bit_number * some_constant   for t = 0
>>> d ( t ) = something else, for other ts
>>> However you mention that we need to express it in terms of time. Please 
>>> clarify.
>> I'd recommend looking at slide 37 of H3.  It helped me with this.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem 9(b)(i)
Date: Mon, 22 Jan 2007 20:38:20 -0800
Lines: 13
Distribution: su
Message-ID: <ep43ge$cbu$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1169527118 12670 171.64.75.59 (23 Jan 2007 04:38:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11223


Hi,

I wonder if I am thinking correctly about d(t) for Problem 9(b)(i).
Suppose we want to evaluate d(t) when a packet is only half stored.
Does d(t) include the time for the other half of the packet to be stored
plus the transmission time for the first half of the packet after the whole 
packet is stored?

- Steven



.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 problem 7
Date: Mon, 22 Jan 2007 22:21:46 -0800
Lines: 9
Distribution: su
Message-ID: <ep49hs$gug$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169533308 17360 127.0.0.1 (23 Jan 2007 06:21:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11224

problem 7 states: "consecutive packets must be separated by at least G 
seconds." just for clarification, i'm wondering if this means <each packet> 
is separated by G seconds, or if the packet is separated by G seconds <only 
if it would transmit in under G seconds otherwise>. i.e., if the transmit 
time is G/5, would the new time become t = G/5 + G, or simply t = G.

-darius 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem 9(b)(i)
Date: Mon, 22 Jan 2007 22:30:32 -0800
Lines: 14
Distribution: su
Message-ID: <ep4a21$h4r$1@news.Stanford.EDU>
References: <ep43ge$cbu$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169533825 17563 127.0.0.1 (23 Jan 2007 06:30:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep43ge$cbu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11225

Euijong Whang wrote:
> Hi,
> 
> I wonder if I am thinking correctly about d(t) for Problem 9(b)(i).
> Suppose we want to evaluate d(t) when a packet is only half stored.
> Does d(t) include the time for the other half of the packet to be stored
> plus the transmission time for the first half of the packet after the whole 
> packet is stored?
> 
> - Steven

You do need to take the transmission time into account.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 problem 7
Date: Mon, 22 Jan 2007 22:35:16 -0800
Lines: 13
Distribution: su
Message-ID: <ep4aat$h4r$2@news.Stanford.EDU>
References: <ep49hs$gug$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169534110 17563 127.0.0.1 (23 Jan 2007 06:35:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep49hs$gug$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11226

Darius Henderson wrote:
> problem 7 states: "consecutive packets must be separated by at least G 
> seconds." just for clarification, i'm wondering if this means <each packet> 
> is separated by G seconds, or if the packet is separated by G seconds <only 
> if it would transmit in under G seconds otherwise>. i.e., if the transmit 
> time is G/5, would the new time become t = G/5 + G, or simply t = G.
> 
> -darius 

The key phrase here is "consecutive packets", so in between every packet 
you send there must be a pause of G seconds.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Midterm Date
Date: Mon, 22 Jan 2007 23:36:34 -0800
Lines: 8
Distribution: su
Message-ID: <C1DAFB02.79A1%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169537796 20757 127.0.0.1 (23 Jan 2007 07:36:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Midterm Date
Thread-Index: Acc+wTTfczkk/Kq0Edui7AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11227

Due to a scheduling conflict, the midterm has been moved back to Tuesday,
February 20.  We may move the Friday review sessions around to reflect this,
so keep an eye on the schedule.

Good luck on your problem set!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Brian Thompson" <Brian.C.Thompson@Boeing.com>
Newsgroups: su.class.cs244a
Subject: Understanding sr
Date: Tue, 23 Jan 2007 22:19:26 -0800
Lines: 14
Distribution: su
Message-ID: <ep6tpg$2vj$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169619568 3059 127.0.0.1 (24 Jan 2007 06:19:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Xref: shelby.stanford.edu su.class.cs244a:11228

I started to take a look at the sr program supplied and don't understand how 
it is to function.  From what I can tell if I run it by "./sr -s 
nv-1.stanford.edu -t 0"  It will show me the the route table loaded, the 
addr for eth0, eth1, and eth2, and then "REad to process packets", as 
expected from the PA2 text.  The next part suggests that if I run a 
traceroute or ping to the IP address of eth0 (171.67.71.2) in another xterm 
I should see in the sr xterm the Interfaces similiar to what is shown in the 
text.  I do not see the sr xterm display anything.  Likewise I tried using 
the -l Logfile option and ended up with an empty file.  Am I reading the 
text correctly or running the sr program correctly?

--Brian 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Understanding sr
Date: Tue, 23 Jan 2007 23:31:20 -0800
Lines: 20
Distribution: su
Message-ID: <ep725f$5t9$1@news.Stanford.EDU>
References: <ep6tpg$2vj$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169624047 6057 171.64.74.54 (24 Jan 2007 07:34:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <ep6tpg$2vj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11229

The IP addresses in the current assignment description are out of date. 
  I'll be sending out the sr assignment topologies for everyone tonight, 
so you should be able to try things out with your own topology shortly.

Clay
Brian Thompson wrote:
> I started to take a look at the sr program supplied and don't understand how 
> it is to function.  From what I can tell if I run it by "./sr -s 
> nv-1.stanford.edu -t 0"  It will show me the the route table loaded, the 
> addr for eth0, eth1, and eth2, and then "REad to process packets", as 
> expected from the PA2 text.  The next part suggests that if I run a 
> traceroute or ping to the IP address of eth0 (171.67.71.2) in another xterm 
> I should see in the sr xterm the Interfaces similiar to what is shown in the 
> text.  I do not see the sr xterm display anything.  Likewise I tried using 
> the -l Logfile option and ended up with an empty file.  Am I reading the 
> text correctly or running the sr program correctly?
> 
> --Brian 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: sr Topologies Posted
Date: Wed, 24 Jan 2007 01:08:45 -0800
Lines: 19
Distribution: su
Message-ID: <ep77s6$dt1$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169629895 14241 171.64.74.54 (24 Jan 2007 09:11:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11230

Topology assignments for PA 2 were just sent out.  You should have 
received an email describing your topology (including the relevant IP 
addresses) and an attached text file that you can feed to the sr client 
to set up your routing table.  Take a look at the assignment section 
called 'Test Driving the sr Stub Code' for instructions on how to verify 
that your topology is working correctly.

If you received an email about a topology but are no longer in the 
class, that's fine- if you can email ccollier@stanford.edu so that we 
know that your topology/IP assignment is available, that would be helpful.

If you are in the class but didn't get a topology assignment, email 
ccollier@stanford.edu.

Questions about the assignment itself should still be directed to the 
newsgroup.  I'll be going over the details of the assignment this Friday 
in the 11 o'clock section.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sr Topologies Posted
Date: Wed, 24 Jan 2007 08:45:43 -0800
Lines: 52
Distribution: su
Message-ID: <ep82l2$5rk$1@news.Stanford.EDU>
References: <ep77s6$dt1$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169657314 6004 171.64.74.54 (24 Jan 2007 16:48:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <ep77s6$dt1$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11231

Notice that the output that you will see on starting up the sr stub code 
is slightly different from what is described in the email.  What you 
will initially see will look something like this:

Loading routing table
---------------------------------------------
Destination     Gateway         Mask    Iface
192.168.128.6           192.168.128.6   255.255.255.255 eth1
192.168.128.8           192.168.128.8   255.255.255.255 eth2
0.0.0.0         172.24.74.17    0.0.0.0 eth0
---------------------------------------------
Client ccollier connecting to Server vns-2:12345
Requesting topology 154
Router interfaces:
eth0    HWaddr70:00:00:9a:00:01
         inet addr 192.168.128.4
eth1    HWaddr70:00:00:9a:00:02
         inet addr 192.168.128.5
eth2    HWaddr70:00:00:9a:00:06
         inet addr 192.168.128.7
  <-- Ready to process packets -->

Just make sure that the IP addresses are correct for your topology, and 
that when you ping one of the IP's for your router, you see a message 
like this:

*** -> Received packet of length 60

in the same window where you are running the sr router.

Clay

Clay Collier wrote:
> Topology assignments for PA 2 were just sent out.  You should have 
> received an email describing your topology (including the relevant IP 
> addresses) and an attached text file that you can feed to the sr client 
> to set up your routing table.  Take a look at the assignment section 
> called 'Test Driving the sr Stub Code' for instructions on how to verify 
> that your topology is working correctly.
> 
> If you received an email about a topology but are no longer in the 
> class, that's fine- if you can email ccollier@stanford.edu so that we 
> know that your topology/IP assignment is available, that would be helpful.
> 
> If you are in the class but didn't get a topology assignment, email 
> ccollier@stanford.edu.
> 
> Questions about the assignment itself should still be directed to the 
> newsgroup.  I'll be going over the details of the assignment this Friday 
> in the 11 o'clock section.
> 
> Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sr Topologies Posted
Date: Wed, 24 Jan 2007 11:14:18 -0800
Lines: 6
Distribution: su
Message-ID: <ep8bbm$dkv$1@news.Stanford.EDU>
References: <ep77s6$dt1$1@news.Stanford.EDU> <ep82l2$5rk$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169666231 13983 171.64.74.54 (24 Jan 2007 19:17:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <ep82l2$5rk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11232

One final caveat: the IPs in your assigned topologies are from a private 
block, and can only be routed to from within Stanford's network.  That 
means that in order to ping or traceroute to an IP in your topology, you 
must be logged into one of the Stanford machines.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: sr code changes
Date: Wed, 24 Jan 2007 16:40:30 -0800
Lines: 7
Distribution: su
Message-ID: <ep8ua1$t0q$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169685634 29722 171.64.74.36 (25 Jan 2007 00:40:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11233

Hi,

Are all the empty functions/functions we are supposed to modify in
sr_router.c?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sr code changes
Date: Wed, 24 Jan 2007 17:19:23 -0800
Lines: 13
Distribution: su
Message-ID: <ep90ih$1cn$1@news.Stanford.EDU>
References: <ep8ua1$t0q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169687953 1431 127.0.0.1 (25 Jan 2007 01:19:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep8ua1$t0q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11234

Jad Naous wrote:
> Hi,
> 
> Are all the empty functions/functions we are supposed to modify in
> sr_router.c?
> 
> Thanks,
> Jad.

Yes, the only two files that you may modify are sr_router.h and 
sr_router.c, however you can add further .c/.h files to the program.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA2 IP options
Date: Wed, 24 Jan 2007 18:16:34 -0800
Lines: 4
Distribution: su
Message-ID: <ep93u6$4ad$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169691398 4429 171.64.74.36 (25 Jan 2007 02:16:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11235

Are we required to implement all the IP options?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Jin Wang" <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: TA phone numbers
Date: Wed, 24 Jan 2007 21:47:29 -0500
Lines: 7
Distribution: su
Message-ID: <ep95qf$5k9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169693328 5769 127.0.0.1 (25 Jan 2007 02:48:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Xref: shelby.stanford.edu su.class.cs244a:11236

What phone number can remote SCPD students call to reach TA's during office
hours?  (I don't live in the Bay Area.)

Thank you,
Jin


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2 IP options
Date: Wed, 24 Jan 2007 18:57:32 -0800
Lines: 10
Distribution: su
Message-ID: <ep96ai$5qn$1@news.Stanford.EDU>
References: <ep93u6$4ad$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169693842 5975 127.0.0.1 (25 Jan 2007 02:57:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep93u6$4ad$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11237

Jad Naous wrote:
> Are we required to implement all the IP options?
> 
> Thanks,
> Jad.

Please see the FAQ, most questions are covered there: 
http://yuba.stanford.edu/vns/assignments/sr_faq.html

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: IP address with switch
Date: Thu, 25 Jan 2007 03:26:47 +0000 (UTC)
Organization: Your Company
Lines: 4
Distribution: su
Message-ID: <Xns98C2C5D2F302Cchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1169695607 7316 128.12.22.217 (25 Jan 2007 03:26:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11238

say i have 2 computers connected to a router that connects to the outside 
world. to the outside world the 2 computers appear to have the same IP 
address... how does this work? how will the router know which computer to 
route the packet to since both of them have the same IP address...
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: IP address with switch
Date: Wed, 24 Jan 2007 20:14:37 -0800
Lines: 9
Distribution: su
Message-ID: <ep9ar3$916$1@news.Stanford.EDU>
References: <Xns98C2C5D2F302Cchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169698467 9254 127.0.0.1 (25 Jan 2007 04:14:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98C2C5D2F302Cchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11239

Chun Kai Wang wrote:
> say i have 2 computers connected to a router that connects to the outside 
> world. to the outside world the 2 computers appear to have the same IP 
> address... how does this work? how will the router know which computer to 
> route the packet to since both of them have the same IP address...

Checkout wikipedia or the book on NAT

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Check destination MAC address?
Date: Wed, 24 Jan 2007 21:35:03 -0800
Lines: 4
Distribution: su
Message-ID: <ep9fi1$c79$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169703297 12521 128.12.194.72 (25 Jan 2007 05:34:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11240

Should I check that the destination MAC address of a received packet 
matches that of my router? Or is that already done for me?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Trying to run tcpdump and wireshark.
Date: Wed, 24 Jan 2007 22:04:11 -0800
Lines: 31
Distribution: su
Message-ID: <ep9h8m$dir$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169705046 13915 128.12.194.72 (25 Jan 2007 06:04:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11241

How do I use tcpdump and wireshark? I copied the files over, but I can't 
seem to get them to run.

I'm logging in remotely via ssh, so maybe this only works in the lab?

myth22:~/CS244A/hw2> ls
sr_stub.tar  stub  tcpdump  wireshark

myth22:~/CS244A/hw2> tcpdump
tcpdump: Command not found.

myth22:~/CS244A/hw2> ./tcpdump
tcpdump: no suitable device found

myth22:~/CS244A/hw2> wireshark
wireshark: Command not found.

myth22:~/CS244A/hw2> ./wireshark
The program 'wireshark' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
   (Details: serial 116 error_code 3 request_code 38 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() 
function.)
myth22:~/CS244A/hw2>

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Trying to run tcpdump and wireshark.
Date: Wed, 24 Jan 2007 22:30:30 -0800
Lines: 25
Distribution: su
Message-ID: <ep9ios$elb$1@news.Stanford.EDU>
References: <ep9h8m$dir$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169706589 15019 127.0.0.1 (25 Jan 2007 06:29:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11242

Funny that the error message stated that the problem was probably a bug in 
the program (wireshark).  It could be more wrong, but not much.

Good luck figuring out tcpdump if you like.

If you want to run wireshark over an ssh connection, you need to tunnel X 
back to your machine.  There are other options, but I assume that your 
machine is Windows, and that you already have Cygwin installed on your 
machine (if not, get it).  Then see:
http://sources.redhat.com/cygwin/xfree/docs/ug/using.html

If you are not using windows and already have X running, just add the -Y 
flag to the ssh command, (there is a DISPLAY variable that needs setting, 
but it is probably already done).

However, I would recommend d/l Wireshark to your machine and copying the 
dump files over there.  I think you will find the application much more 
responsive (and it is fun to sniff your own bus sometimes anyway).

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Trying to run tcpdump and wireshark.
Date: Wed, 24 Jan 2007 22:43:56 -0800
Lines: 47
Distribution: su
Message-ID: <C1DD91AC.7ACB%jpettit@stanford.edu>
References: <ep9h8m$dir$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169707439 15646 127.0.0.1 (25 Jan 2007 06:43:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Trying to run tcpdump and wireshark.
Thread-Index: AcdATC9ibiwWQqw/EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11243

Randy did a good job explaining wireshark.  If you want to work remotely,
you'll need to get X forwarding working.

For tcpdump, take a look at the section titled "Inspecting Packets with
tcpdump" in the assignment.  The gist of the problem is that since you
aren't root, you can't open a raw device, so it can only dump previously
saved packets.  To read packets from a file, you need the "-r" option.

--Justin
 

On 1/24/07 10:04 PM, in article ep9h8m$dir$1@news.Stanford.EDU, "Yangfan
Wang" <yfw@stanford.edu> wrote:

> How do I use tcpdump and wireshark? I copied the files over, but I can't
> seem to get them to run.
> 
> I'm logging in remotely via ssh, so maybe this only works in the lab?
> 
> myth22:~/CS244A/hw2> ls
> sr_stub.tar  stub  tcpdump  wireshark
> 
> myth22:~/CS244A/hw2> tcpdump
> tcpdump: Command not found.
> 
> myth22:~/CS244A/hw2> ./tcpdump
> tcpdump: no suitable device found
> 
> myth22:~/CS244A/hw2> wireshark
> wireshark: Command not found.
> 
> myth22:~/CS244A/hw2> ./wireshark
> The program 'wireshark' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>    (Details: serial 116 error_code 3 request_code 38 minor_code 0)
>    (Note to programmers: normally, X errors are reported asynchronously;
>     that is, you will receive the error a while after causing it.
>     To debug your program, run it with the --sync command line
>     option to change this behavior. You can then get a meaningful
>     backtrace from your debugger if you break on the gdk_x_error()
> function.)
> myth22:~/CS244A/hw2>
> 
> -Yangfan


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Check destination MAC address?
Date: Wed, 24 Jan 2007 22:49:33 -0800
Lines: 9
Distribution: su
Message-ID: <ep9jtt$fbm$1@news.Stanford.EDU>
References: <ep9fi1$c79$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169707773 15734 127.0.0.1 (25 Jan 2007 06:49:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ep9fi1$c79$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11244

Yangfan Wang wrote:
> Should I check that the destination MAC address of a received packet 
> matches that of my router? Or is that already done for me?
> 
> -Yangfan

I believe this is already done for you.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA2: network byte order?
Date: Thu, 25 Jan 2007 16:31:53 -0800
Lines: 5
Distribution: su
Message-ID: <epbi5t$i4q$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169771517 18586 171.64.74.36 (26 Jan 2007 00:31:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11245

Are the addresses in the sr_if and the sr_rt structs in network byte
order or in host byte order?

Thanks,
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: watching lectures
Date: Thu, 25 Jan 2007 17:58:40 -0800
Lines: 20
Distribution: su
Message-ID: <epbn8j$mn1$1@news.Stanford.EDU>
References: <eour2u$e8d$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1169776723 23265 127.0.0.1 (26 Jan 2007 01:58:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:11246

On 2007-01-20 20:44:13 -0800, Benjamin Nham <nham@stanford.edu> said:

> I can't seem to watch lectures online. Anyone else having this problem? 
> I can't exactly watch it in person, since I'm also in CS161, which 
> isn't offered online...
> 
> Ben

The cs244a website has a link to the online classroom page, but it puts 
it in a frame, so your browser still says "cs244a.stanford.edu" in it. 
When you click the video link, it tries to open a relative address -- 
basically, a string of numbers that it expects will follow 
cetus.stanford.edu. Since cetus.stanford.edu is not in  your browser, 
it won't load. If you go directly to the Online Classroom website it 
will actually work.

At the very least, that was my problem.

AC

.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Check destination MAC address?
Date: Thu, 25 Jan 2007 23:40:21 -0800
Lines: 17
Distribution: su
Message-ID: <epcbf6$78v$1@news.Stanford.EDU>
References: <ep9fi1$c79$1@news.Stanford.EDU> <ep9jtt$fbm$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169797415 7455 171.64.74.54 (26 Jan 2007 07:43:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <ep9jtt$fbm$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11247

You do not need to check that the MAC address matches that of the 
router.  Ethernet frames that have other destination MAC addresses 
(other than ARP request packets, which are broadcast) should never show 
up at your router.

Clay

David Erickson wrote:
> Yangfan Wang wrote:
>> Should I check that the destination MAC address of a received packet 
>> matches that of my router? Or is that already done for me?
>>
>> -Yangfan
> 
> I believe this is already done for you.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: VNS Connectivity from the brambles
Date: Thu, 25 Jan 2007 23:48:14 -0800
Lines: 9
Distribution: su
Message-ID: <epcbtv$9dg$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169797887 9648 171.64.74.54 (26 Jan 2007 07:51:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11248

There were a few reports earlier today of people having trouble getting 
their router stub code to connect from the machines in the bramble 
cluster.  It turns out that there was a routing problem that was 
preventing anything from getting back to the brambles from the VNS 
machines, resulting in routers hanging at the 'Requesting topology' 
stage without ever hearing anything back.  This should be resolved now; 
if you still can't get your router to connect, please let me know.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2: network byte order?
Date: Fri, 26 Jan 2007 00:03:10 -0800
Lines: 15
Distribution: su
Message-ID: <C1DEF5BE.7B8E%jpettit@stanford.edu>
References: <epbi5t$i4q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169798591 11897 127.0.0.1 (26 Jan 2007 08:03:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA2: network byte order?
Thread-Index: AcdBIGtmqjJlAq0TEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11249

Network byte order.

--Justin


On 1/25/07 4:31 PM, in article epbi5t$i4q$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> Are the addresses in the sr_if and the sr_rt structs in network byte
> order or in host byte order?
> 
> Thanks,
> Jad


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Assignment 2 Update
Date: Fri, 26 Jan 2007 12:33:54 -0800
Lines: 18
Distribution: su
Message-ID: <epdopn$jbs$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169843831 19836 171.64.74.54 (26 Jan 2007 20:37:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11250

The first version of assignment 2 posted on the website incorrectly 
stated that enforcing timeouts for unreachable hosts was an optional 
part of the assignment.  It is actually required functionality (the 
confusion was caused by the fact that we linked to the version of the 
assignment that is used outside of Stanford).

Essentially, if you send out ARP requests for a host and do not hear a 
reply, an ICMP Host Unreachable message must be generated and sent by 
your router, even if no more packets arrive at the router.  You should 
state the timeout periods for ARP requests and the ARP cache in your 
README; since you can't control the OS scheduler, the timing does not 
have to be exact, but you do need to be able to guarantee that timeouts 
will be correctly noticed and reported by the router.

Additionally, slides from todays problem session have been posted on the 
website.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Assignment 2 Update
Date: Fri, 26 Jan 2007 16:25:39 -0800
Lines: 8
Distribution: su
Message-ID: <epe64o$1r9$1@news.Stanford.EDU>
References: <epdopn$jbs$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169857496 1897 127.0.0.1 (27 Jan 2007 00:24:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11251

Did the FAQ or source code change?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ARP requests timeout value
Date: Fri, 26 Jan 2007 18:49:58 -0800
Lines: 5
Distribution: su
Message-ID: <epeeks$86l$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169866204 8405 171.64.74.36 (27 Jan 2007 02:50:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11252

how long should we wait before we resend a new ARP request if a reply is
not received?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Assignment 2 Update
Date: Fri, 26 Jan 2007 19:07:58 -0800
Lines: 20
Distribution: su
Message-ID: <C1E0020E.7C45%jpettit@stanford.edu>
References: <epdopn$jbs$1@news.Stanford.EDU> <epe64o$1r9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169867282 9313 127.0.0.1 (27 Jan 2007 03:08:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Assignment 2 Update
Thread-Index: AcdBwFijl1W8VK2zEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11253

Nope, they're still the same.  We may need to update the FAQ as the quarter
progresses.  If so, we'll put up the date it was last updated (similar to
what we did with PA1's grading script).

--Justin


On 1/26/07 4:25 PM, in article epe64o$1r9$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> Did the FAQ or source code change?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP requests timeout value
Date: Fri, 26 Jan 2007 19:15:21 -0800
Lines: 15
Distribution: su
Message-ID: <C1E003C9.7C49%jpettit@stanford.edu>
References: <epeeks$86l$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169867727 9705 127.0.0.1 (27 Jan 2007 03:15:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ARP requests timeout value
Thread-Index: AcdBwWCwnw63dK20EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11254

Anything reasonable.  One second sounds good to me.

--Justin


On 1/26/07 6:49 PM, in article epeeks$86l$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> how long should we wait before we resend a new ARP request if a reply is
> not received?
> 
> Thanks,
> Jad.


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Grading project 2 on myth?
Date: Sat, 27 Jan 2007 01:25:20 -0700
Lines: 8
Distribution: su
Message-ID: <epf29h$pr7$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169886321 26471 127.0.0.1 (27 Jan 2007 08:25:21 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11255

Hi,

Will you be grading project 2 on myth?

Thanks,
Kevin 


.

Path: shelby.stanford.edu!not-for-mail
From: "Matt Page" <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Timing out ARP cache entries
Date: Sat, 27 Jan 2007 13:13:03 -0800
Lines: 7
Distribution: su
Message-ID: <epgf90$f7$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
X-Trace: news.Stanford.EDU 1169932384 487 128.12.104.45 (27 Jan 2007 21:13:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11256

Are we allowed to use pthreads(or another thread library) to aid timing out 
arp cache entries?

Thanks,
Matt 


.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Memory Allocation Contract
Date: Sat, 27 Jan 2007 13:51:59 -0800
Lines: 8
Distribution: su
Message-ID: <paun-F4A62F.13515927012007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1169934721 2018 128.12.135.184 (27 Jan 2007 21:52:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11257

   My question deals with the comments:
      /* borrowed */
      /* lent */
found next to several parameters.

   For each one, who is responsible for freeing the memory allocated for 
that parameter?  
   Thank you.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Memory Allocation Contract
Date: Sat, 27 Jan 2007 14:08:51 -0800
Lines: 20
Distribution: su
Message-ID: <C1E10D73.7CA9%jpettit@stanford.edu>
References: <paun-F4A62F.13515927012007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169935734 2671 127.0.0.1 (27 Jan 2007 22:08:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Memory Allocation Contract
Thread-Index: AcdCX7nO+Dr4va5SEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11258

These terms are from the perspective of you as the borrower or lender of a
memory block.  So, for something borrowed, they are responsible.  For
something lent, you are.

--Justin


On 1/27/07 1:51 PM, in article paun-F4A62F.13515927012007@nntp.stanford.edu,
"Filip Paun" <paun@stanford.edu> wrote:

>    My question deals with the comments:
>       /* borrowed */
>       /* lent */
> found next to several parameters.
> 
>    For each one, who is responsible for freeing the memory allocated for
> that parameter?  
>    Thank you.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Timing out ARP cache entries
Date: Sat, 27 Jan 2007 14:13:32 -0800
Lines: 17
Distribution: su
Message-ID: <C1E10E8C.7CAC%jpettit@stanford.edu>
References: <epgf90$f7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169936035 2903 127.0.0.1 (27 Jan 2007 22:13:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Timing out ARP cache entries
Thread-Index: AcdCYGFLn7fpEq5TEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11259

Yes.  Just make sure that it compiles cleanly on the Myths.

--Justin


On 1/27/07 1:13 PM, in article epgf90$f7$1@news.Stanford.EDU, "Matt Page"
<mpage@stanford.edu> wrote:

> Are we allowed to use pthreads(or another thread library) to aid timing out
> arp cache entries?
> 
> Thanks,
> Matt 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Grading project 2 on myth?
Date: Sat, 27 Jan 2007 14:14:37 -0800
Lines: 18
Distribution: su
Message-ID: <C1E10ECD.7CAE%jpettit@stanford.edu>
References: <epf29h$pr7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169936078 2903 127.0.0.1 (27 Jan 2007 22:14:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Grading project 2 on myth?
Thread-Index: AcdCYIgKxtIi4a5TEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11260

Yes.

--Justin


On 1/27/07 12:25 AM, in article epf29h$pr7$1@news.Stanford.EDU, "Kevin Hart"
<kevin.hart@hp.com> wrote:

> Hi,
> 
> Will you be grading project 2 on myth?
> 
> Thanks,
> Kevin 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Packet validation
Date: Sat, 27 Jan 2007 16:43:40 -0800
Lines: 8
Distribution: su
Message-ID: <epgrjt$931$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1169945021 9313 127.0.0.1 (28 Jan 2007 00:43:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11261

Can we assume that all packets passed to sr_handlepacket() are of the proper 
format and are destined for this router? Or do we need to do any validation 
inside sr_handlepacket()?

Thanks,
Riju 


.

Path: shelby.stanford.edu!not-for-mail
From: Raymond Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: "FIXME" in sr_protocol.h
Date: Sun, 28 Jan 2007 04:20:30 -0800
Lines: 15
Distribution: su
Message-ID: <epi4ej$d33$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1169986835 13411 127.0.0.1 (28 Jan 2007 12:20:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11262

Any insight into this comment that I found in the file sr_protocol.h?

/* FIXME
  * ohh how lame .. how very, very lame... how can I ever go out in public
  * again?! /mc
  */
<system byte order #defines here>

I can't really tell if there is actually anything wrong with the code. 
[I don't see anything wrong, personally.]

Some clarification would be appreciated.

TIA
- Raymond
.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 15:07:24 -0800
Lines: 160
Distribution: su
Message-ID: <epjabj$b0v$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170025651 11295 127.0.0.1 (28 Jan 2007 23:07:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11263

Hi,

I've been fixing up little bugs in my proxy for PA4, but I still can't seeem 
to get that grading script running. The proxy never crashed on the queries 
from the script, at least from what I can see (entering the script's 
addresses in telnet works just fine). Any other possibilities for this error 
(exact same error as Alex from the post quoted below)?

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1D6AA04.785A%jpettit@stanford.edu...
> It looks like you may be closing the socket you have listening on 32454,
> since the script is complaining that it can't connect to your proxy.  You
> may want to telnet to your proxy and manually type in the requests from 
> the
> grading script.  Is your proxy crashing on one of the queries?
>
> --Justin
>
>
> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
> Henderson" <darius.henderson@stanford.edu> wrote:
>
>> I've been testing my proxy through telnet and my browsers mostly, so I 
>> just
>> started using the grading script and I've got this error too. I don't 
>> have
>> any trouble making connections through the browsers though. Anyone know 
>> some
>> reasons why this would occur only with the script or if there's a way to
>> debug my program while the script is executing?
>>
>> Thanks,
>> Darius
>>
>>
>> "Alex" <axle@sonic.net> wrote in message
>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>> I gave a port in the valid range and I still see this issue. I was able 
>>> to
>>> run my proxy on that port and use telnet and do GET correctly but I'm 
>>> still
>>> having problems with the grading script.
>>>
>>> vine7:~/proj1> ./grade proxy.c 32454
>>> Binary: proxy.c
>>> Running on port 32454
>>> Traceback (most recent call last):
>>>  File "./grade", line 97, in ?
>>>    main()
>>>  File "./grade", line 42, in main
>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>>> line
>>> 82, in urlopen
>>>    return opener.open(url)
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>>> line
>>> 190, in open
>>>    return getattr(self, name)(url)
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py", 
>>> line
>>> 313, in open_http
>>>    h.endheaders()
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 798, in endheaders
>>>    self._send_output()
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 679, in _send_output
>>>    self.send(msg)
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 646, in send
>>>    self.connect()
>>>  File
>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>> line 630, in connect
>>>    raise socket.error, msg
>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>
>>> Alex
>>>
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>> TCP and UDP port numbers are 16-bit values, which means the maximum 
>>>> value
>>>> is
>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>> check
>>>> to make sure that you're checking all your socket return values and
>>>> compiler
>>>> warnings.
>>>>
>>>> --Justin
>>>>
>>>>
>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>> <axle@sonic.net> wrote:
>>>>
>>>>> I was trying to run the grading script on my proxy and I get the
>>>>> messages
>>>>> below. Why is this happening?
>>>>>
>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>> Binary: proxy.c
>>>>> Running on port 98235
>>>>> Traceback (most recent call last):
>>>>>   File "./grade", line 100, in ?
>>>>>     main()
>>>>>   File "./grade", line 45, in main
>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 82, in urlopen
>>>>>     return opener.open(url)
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 190, in open
>>>>>     return getattr(self, name)(url)
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line 313, in open_http
>>>>>     h.endheaders()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 798, in endheaders
>>>>>     self._send_output()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 679, in _send_output
>>>>>     self.send(msg)
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 646, in send
>>>>>     self.connect()
>>>>>   File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line
>>>>> 630, in connect
>>>>>     raise socket.error, msg
>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: "FIXME" in sr_protocol.h
Date: Sun, 28 Jan 2007 16:05:50 -0800
Lines: 28
Distribution: su
Message-ID: <C1E27A5E.7CF3%jpettit@stanford.edu>
References: <epi4ej$d33$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170029156 13724 127.0.0.1 (29 Jan 2007 00:05:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: "FIXME" in sr_protocol.h
Thread-Index: AcdDOTveeljpCK8sEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11264

He felt that he shouldn't be using #defines to determine the endian-ness of
the system.  It would be better to figure it out dynamically.  Keep in mind
that Linux, Solaris, and Darwin (Mac OS X) are all available on platforms
with the opposite endian-ness as defined there.

--Justin


On 1/28/07 4:20 AM, in article epi4ej$d33$1@news.Stanford.EDU, "Raymond
Thang" <rlt5654@stanford.edu> wrote:

> Any insight into this comment that I found in the file sr_protocol.h?
> 
> /* FIXME
>   * ohh how lame .. how very, very lame... how can I ever go out in public
>   * again?! /mc
>   */
> <system byte order #defines here>
> 
> I can't really tell if there is actually anything wrong with the code.
> [I don't see anything wrong, personally.]
> 
> Some clarification would be appreciated.
> 
> TIA
> - Raymond


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 16:10:12 -0800
Lines: 172
Distribution: su
Message-ID: <C1E27B64.7CF6%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu> <epjabj$b0v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170029417 13975 127.0.0.1 (29 Jan 2007 00:10:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: AcdDOdgIFtaui68tEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11265

Is it possible that you are not handling HTTP/1.1 requests as defined in the
FAQ?  If you are still having trouble, I would recommend coming to office
hours, since it's hard to debug this without more information.

--Justin


On 1/28/07 3:07 PM, in article epjabj$b0v$1@news.Stanford.EDU, "Darius
Henderson" <darius.henderson@stanford.edu> wrote:

> Hi,
> 
> I've been fixing up little bugs in my proxy for PA4, but I still can't seeem
> to get that grading script running. The proxy never crashed on the queries
> from the script, at least from what I can see (entering the script's
> addresses in telnet works just fine). Any other possibilities for this error
> (exact same error as Alex from the post quoted below)?
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1D6AA04.785A%jpettit@stanford.edu...
>> It looks like you may be closing the socket you have listening on 32454,
>> since the script is complaining that it can't connect to your proxy.  You
>> may want to telnet to your proxy and manually type in the requests from
>> the
>> grading script.  Is your proxy crashing on one of the queries?
>> 
>> --Justin
>> 
>> 
>> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
>> Henderson" <darius.henderson@stanford.edu> wrote:
>> 
>>> I've been testing my proxy through telnet and my browsers mostly, so I
>>> just
>>> started using the grading script and I've got this error too. I don't
>>> have
>>> any trouble making connections through the browsers though. Anyone know
>>> some
>>> reasons why this would occur only with the script or if there's a way to
>>> debug my program while the script is executing?
>>> 
>>> Thanks,
>>> Darius
>>> 
>>> 
>>> "Alex" <axle@sonic.net> wrote in message
>>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>>> I gave a port in the valid range and I still see this issue. I was able
>>>> to
>>>> run my proxy on that port and use telnet and do GET correctly but I'm
>>>> still
>>>> having problems with the grading script.
>>>> 
>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>> Binary: proxy.c
>>>> Running on port 32454
>>>> Traceback (most recent call last):
>>>>  File "./grade", line 97, in ?
>>>>    main()
>>>>  File "./grade", line 42, in main
>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line
>>>> 82, in urlopen
>>>>    return opener.open(url)
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line
>>>> 190, in open
>>>>    return getattr(self, name)(url)
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>> line
>>>> 313, in open_http
>>>>    h.endheaders()
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line 798, in endheaders
>>>>    self._send_output()
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line 679, in _send_output
>>>>    self.send(msg)
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line 646, in send
>>>>    self.connect()
>>>>  File
>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>> line 630, in connect
>>>>    raise socket.error, msg
>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>> 
>>>> Alex
>>>> 
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>> value
>>>>> is
>>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>>> check
>>>>> to make sure that you're checking all your socket return values and
>>>>> compiler
>>>>> warnings.
>>>>> 
>>>>> --Justin
>>>>> 
>>>>> 
>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>> <axle@sonic.net> wrote:
>>>>> 
>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>> messages
>>>>>> below. Why is this happening?
>>>>>> 
>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>> Binary: proxy.c
>>>>>> Running on port 98235
>>>>>> Traceback (most recent call last):
>>>>>>   File "./grade", line 100, in ?
>>>>>>     main()
>>>>>>   File "./grade", line 45, in main
>>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line 82, in urlopen
>>>>>>     return opener.open(url)
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line 190, in open
>>>>>>     return getattr(self, name)(url)
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line 313, in open_http
>>>>>>     h.endheaders()
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line
>>>>>> 798, in endheaders
>>>>>>     self._send_output()
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line
>>>>>> 679, in _send_output
>>>>>>     self.send(msg)
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line
>>>>>> 646, in send
>>>>>>     self.connect()
>>>>>>   File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line
>>>>>> 630, in connect
>>>>>>     raise socket.error, msg
>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PA2 how to broadcast ARP request?
Date: Mon, 29 Jan 2007 00:40:24 +0000 (UTC)
Lines: 11
Distribution: su
Message-ID: <epjfpo$ffn$1@news.Stanford.EDU>
NNTP-Posting-Host: vine10.stanford.edu
X-Trace: news.Stanford.EDU 1170031224 15863 171.64.15.247 (29 Jan 2007 00:40:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11266

Hi,

After getting an IP packet, shall we broadcast ARP req for hw addr from
all router ports or shall we get the destination port from routing table
and broadcast from only that particular port? If we broadcast from the
particular interface then is it possible to not get reply? Because ip
addr is correct and application servers running so no way we won't get
it!

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 17:34:04 -0800
Lines: 200
Distribution: su
Message-ID: <epjiuj$i52$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu> <epjabj$b0v$1@news.Stanford.EDU> <C1E27B64.7CF6%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170034451 18594 127.0.0.1 (29 Jan 2007 01:34:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11267

Hi,

I think narrowed down the problem in my code to this one snippet:

if((new_sock = accept(sock_num, (struct sockaddr *)&addr, &addr_size)) >= 0)
    printf("\nIncoming connection from %s...\n", inet_ntoa(addr.sin_addr));
else printf("Invalid socket given: %d\n", new_sock);

The grading script gets here, to the accept call, but never makes it to 
either of printfs. The fact that I can connect just fine from my computer 
makes me think the accept call and the parameters are okay, so I have no 
idea why the script keeps saying "connection refused." Hope this information 
helps any, if not I'll just go to office hours.

Thanks,
Darius

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1E27B64.7CF6%jpettit@stanford.edu...
> Is it possible that you are not handling HTTP/1.1 requests as defined in 
> the
> FAQ?  If you are still having trouble, I would recommend coming to office
> hours, since it's hard to debug this without more information.
>
> --Justin
>
>
> On 1/28/07 3:07 PM, in article epjabj$b0v$1@news.Stanford.EDU, "Darius
> Henderson" <darius.henderson@stanford.edu> wrote:
>
>> Hi,
>>
>> I've been fixing up little bugs in my proxy for PA4, but I still can't 
>> seeem
>> to get that grading script running. The proxy never crashed on the 
>> queries
>> from the script, at least from what I can see (entering the script's
>> addresses in telnet works just fine). Any other possibilities for this 
>> error
>> (exact same error as Alex from the post quoted below)?
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1D6AA04.785A%jpettit@stanford.edu...
>>> It looks like you may be closing the socket you have listening on 32454,
>>> since the script is complaining that it can't connect to your proxy. 
>>> You
>>> may want to telnet to your proxy and manually type in the requests from
>>> the
>>> grading script.  Is your proxy crashing on one of the queries?
>>>
>>> --Justin
>>>
>>>
>>> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>>
>>>> I've been testing my proxy through telnet and my browsers mostly, so I
>>>> just
>>>> started using the grading script and I've got this error too. I don't
>>>> have
>>>> any trouble making connections through the browsers though. Anyone know
>>>> some
>>>> reasons why this would occur only with the script or if there's a way 
>>>> to
>>>> debug my program while the script is executing?
>>>>
>>>> Thanks,
>>>> Darius
>>>>
>>>>
>>>> "Alex" <axle@sonic.net> wrote in message
>>>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>>>> I gave a port in the valid range and I still see this issue. I was 
>>>>> able
>>>>> to
>>>>> run my proxy on that port and use telnet and do GET correctly but I'm
>>>>> still
>>>>> having problems with the grading script.
>>>>>
>>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>>> Binary: proxy.c
>>>>> Running on port 32454
>>>>> Traceback (most recent call last):
>>>>>  File "./grade", line 97, in ?
>>>>>    main()
>>>>>  File "./grade", line 42, in main
>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line
>>>>> 82, in urlopen
>>>>>    return opener.open(url)
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line
>>>>> 190, in open
>>>>>    return getattr(self, name)(url)
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>> line
>>>>> 313, in open_http
>>>>>    h.endheaders()
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 798, in endheaders
>>>>>    self._send_output()
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 679, in _send_output
>>>>>    self.send(msg)
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 646, in send
>>>>>    self.connect()
>>>>>  File
>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>> line 630, in connect
>>>>>    raise socket.error, msg
>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>
>>>>> Alex
>>>>>
>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>>> value
>>>>>> is
>>>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>>>> check
>>>>>> to make sure that you're checking all your socket return values and
>>>>>> compiler
>>>>>> warnings.
>>>>>>
>>>>>> --Justin
>>>>>>
>>>>>>
>>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>>> <axle@sonic.net> wrote:
>>>>>>
>>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>>> messages
>>>>>>> below. Why is this happening?
>>>>>>>
>>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>>> Binary: proxy.c
>>>>>>> Running on port 98235
>>>>>>> Traceback (most recent call last):
>>>>>>>   File "./grade", line 100, in ?
>>>>>>>     main()
>>>>>>>   File "./grade", line 45, in main
>>>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 82, in urlopen
>>>>>>>     return opener.open(url)
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 190, in open
>>>>>>>     return getattr(self, name)(url)
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line 313, in open_http
>>>>>>>     h.endheaders()
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 798, in endheaders
>>>>>>>     self._send_output()
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 679, in _send_output
>>>>>>>     self.send(msg)
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 646, in send
>>>>>>>     self.connect()
>>>>>>>   File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line
>>>>>>> 630, in connect
>>>>>>>     raise socket.error, msg
>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 17:54:07 -0800
Lines: 216
Distribution: su
Message-ID: <C1E293BF.7CFD%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu> <epjabj$b0v$1@news.Stanford.EDU> <C1E27B64.7CF6%jpettit@stanford.edu> <epjiuj$i52$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170035651 19381 127.0.0.1 (29 Jan 2007 01:54:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: AcdDSFximu6dNK87EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11268

Did you set "addr_size" before you call accept()?  You should have a line
like the following before your call to accept():

    addr_size = sizeof(addr);

The third argument is used to both pass something in and to retrieve
something.

--Justin


On 1/28/07 5:34 PM, in article epjiuj$i52$1@news.Stanford.EDU, "Darius
Henderson" <darius.henderson@stanford.edu> wrote:

> Hi,
> 
> I think narrowed down the problem in my code to this one snippet:
> 
> if((new_sock = accept(sock_num, (struct sockaddr *)&addr, &addr_size)) >= 0)
>     printf("\nIncoming connection from %s...\n", inet_ntoa(addr.sin_addr));
> else printf("Invalid socket given: %d\n", new_sock);
> 
> The grading script gets here, to the accept call, but never makes it to
> either of printfs. The fact that I can connect just fine from my computer
> makes me think the accept call and the parameters are okay, so I have no
> idea why the script keeps saying "connection refused." Hope this information
> helps any, if not I'll just go to office hours.
> 
> Thanks,
> Darius
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1E27B64.7CF6%jpettit@stanford.edu...
>> Is it possible that you are not handling HTTP/1.1 requests as defined in
>> the
>> FAQ?  If you are still having trouble, I would recommend coming to office
>> hours, since it's hard to debug this without more information.
>> 
>> --Justin
>> 
>> 
>> On 1/28/07 3:07 PM, in article epjabj$b0v$1@news.Stanford.EDU, "Darius
>> Henderson" <darius.henderson@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> I've been fixing up little bugs in my proxy for PA4, but I still can't
>>> seeem
>>> to get that grading script running. The proxy never crashed on the
>>> queries
>>> from the script, at least from what I can see (entering the script's
>>> addresses in telnet works just fine). Any other possibilities for this
>>> error
>>> (exact same error as Alex from the post quoted below)?
>>> 
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1D6AA04.785A%jpettit@stanford.edu...
>>>> It looks like you may be closing the socket you have listening on 32454,
>>>> since the script is complaining that it can't connect to your proxy.
>>>> You
>>>> may want to telnet to your proxy and manually type in the requests from
>>>> the
>>>> grading script.  Is your proxy crashing on one of the queries?
>>>> 
>>>> --Justin
>>>> 
>>>> 
>>>> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
>>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>>> 
>>>>> I've been testing my proxy through telnet and my browsers mostly, so I
>>>>> just
>>>>> started using the grading script and I've got this error too. I don't
>>>>> have
>>>>> any trouble making connections through the browsers though. Anyone know
>>>>> some
>>>>> reasons why this would occur only with the script or if there's a way
>>>>> to
>>>>> debug my program while the script is executing?
>>>>> 
>>>>> Thanks,
>>>>> Darius
>>>>> 
>>>>> 
>>>>> "Alex" <axle@sonic.net> wrote in message
>>>>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>>>>> I gave a port in the valid range and I still see this issue. I was
>>>>>> able
>>>>>> to
>>>>>> run my proxy on that port and use telnet and do GET correctly but I'm
>>>>>> still
>>>>>> having problems with the grading script.
>>>>>> 
>>>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>>>> Binary: proxy.c
>>>>>> Running on port 32454
>>>>>> Traceback (most recent call last):
>>>>>>  File "./grade", line 97, in ?
>>>>>>    main()
>>>>>>  File "./grade", line 42, in main
>>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line
>>>>>> 82, in urlopen
>>>>>>    return opener.open(url)
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line
>>>>>> 190, in open
>>>>>>    return getattr(self, name)(url)
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>> line
>>>>>> 313, in open_http
>>>>>>    h.endheaders()
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line 798, in endheaders
>>>>>>    self._send_output()
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line 679, in _send_output
>>>>>>    self.send(msg)
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line 646, in send
>>>>>>    self.connect()
>>>>>>  File
>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>> line 630, in connect
>>>>>>    raise socket.error, msg
>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>>>> value
>>>>>>> is
>>>>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>>>>> check
>>>>>>> to make sure that you're checking all your socket return values and
>>>>>>> compiler
>>>>>>> warnings.
>>>>>>> 
>>>>>>> --Justin
>>>>>>> 
>>>>>>> 
>>>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>>>> <axle@sonic.net> wrote:
>>>>>>> 
>>>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>>>> messages
>>>>>>>> below. Why is this happening?
>>>>>>>> 
>>>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>>>> Binary: proxy.c
>>>>>>>> Running on port 98235
>>>>>>>> Traceback (most recent call last):
>>>>>>>>   File "./grade", line 100, in ?
>>>>>>>>     main()
>>>>>>>>   File "./grade", line 45, in main
>>>>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line 82, in urlopen
>>>>>>>>     return opener.open(url)
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line 190, in open
>>>>>>>>     return getattr(self, name)(url)
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line 313, in open_http
>>>>>>>>     h.endheaders()
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line
>>>>>>>> 798, in endheaders
>>>>>>>>     self._send_output()
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line
>>>>>>>> 679, in _send_output
>>>>>>>>     self.send(msg)
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line
>>>>>>>> 646, in send
>>>>>>>>     self.connect()
>>>>>>>>   File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line
>>>>>>>> 630, in connect
>>>>>>>>     raise socket.error, msg
>>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 18:14:37 -0800
Lines: 234
Distribution: su
Message-ID: <C1E2988D.7D02%jpettit@stanford.edu>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu> <epjabj$b0v$1@news.Stanford.EDU> <C1E27B64.7CF6%jpettit@stanford.edu> <epjiuj$i52$1@news.Stanford.EDU> <C1E293BF.7CFD%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170036881 20220 127.0.0.1 (29 Jan 2007 02:14:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: running grading script
Thread-Index: AcdDSFximu6dNK87EduZHwARJDbi7gAAt0gV
Xref: shelby.stanford.edu su.class.cs244a:11269

Sorry, I was talking to somebody while writing that last sentence, so it
wasn't very clear.  Here's what the accept() man page has to say:

    The addrlen is a value-result parameter; it should initially
    contain the amount of space pointed to by addr; on return
    it will contain the actual length (in bytes) of the address
    returned.

This is an easy thing to miss.  I've been stung by it myself.

--Justin


On 1/28/07 5:54 PM, in article C1E293BF.7CFD%jpettit@stanford.edu, "Justin
Pettit" <jpettit@stanford.edu> wrote:

> Did you set "addr_size" before you call accept()?  You should have a line
> like the following before your call to accept():
> 
>     addr_size = sizeof(addr);
> 
> The third argument is used to both pass something in and to retrieve
> something.
> 
> --Justin
> 
> 
> On 1/28/07 5:34 PM, in article epjiuj$i52$1@news.Stanford.EDU, "Darius
> Henderson" <darius.henderson@stanford.edu> wrote:
> 
>> Hi,
>> 
>> I think narrowed down the problem in my code to this one snippet:
>> 
>> if((new_sock = accept(sock_num, (struct sockaddr *)&addr, &addr_size)) >= 0)
>>     printf("\nIncoming connection from %s...\n", inet_ntoa(addr.sin_addr));
>> else printf("Invalid socket given: %d\n", new_sock);
>> 
>> The grading script gets here, to the accept call, but never makes it to
>> either of printfs. The fact that I can connect just fine from my computer
>> makes me think the accept call and the parameters are okay, so I have no
>> idea why the script keeps saying "connection refused." Hope this information
>> helps any, if not I'll just go to office hours.
>> 
>> Thanks,
>> Darius
>> 
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>> news:C1E27B64.7CF6%jpettit@stanford.edu...
>>> Is it possible that you are not handling HTTP/1.1 requests as defined in
>>> the
>>> FAQ?  If you are still having trouble, I would recommend coming to office
>>> hours, since it's hard to debug this without more information.
>>> 
>>> --Justin
>>> 
>>> 
>>> On 1/28/07 3:07 PM, in article epjabj$b0v$1@news.Stanford.EDU, "Darius
>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've been fixing up little bugs in my proxy for PA4, but I still can't
>>>> seeem
>>>> to get that grading script running. The proxy never crashed on the
>>>> queries
>>>> from the script, at least from what I can see (entering the script's
>>>> addresses in telnet works just fine). Any other possibilities for this
>>>> error
>>>> (exact same error as Alex from the post quoted below)?
>>>> 
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>> news:C1D6AA04.785A%jpettit@stanford.edu...
>>>>> It looks like you may be closing the socket you have listening on 32454,
>>>>> since the script is complaining that it can't connect to your proxy.
>>>>> You
>>>>> may want to telnet to your proxy and manually type in the requests from
>>>>> the
>>>>> grading script.  Is your proxy crashing on one of the queries?
>>>>> 
>>>>> --Justin
>>>>> 
>>>>> 
>>>>> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, "Darius
>>>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>>>> 
>>>>>> I've been testing my proxy through telnet and my browsers mostly, so I
>>>>>> just
>>>>>> started using the grading script and I've got this error too. I don't
>>>>>> have
>>>>>> any trouble making connections through the browsers though. Anyone know
>>>>>> some
>>>>>> reasons why this would occur only with the script or if there's a way
>>>>>> to
>>>>>> debug my program while the script is executing?
>>>>>> 
>>>>>> Thanks,
>>>>>> Darius
>>>>>> 
>>>>>> 
>>>>>> "Alex" <axle@sonic.net> wrote in message
>>>>>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>>>>>> I gave a port in the valid range and I still see this issue. I was
>>>>>>> able
>>>>>>> to
>>>>>>> run my proxy on that port and use telnet and do GET correctly but I'm
>>>>>>> still
>>>>>>> having problems with the grading script.
>>>>>>> 
>>>>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>>>>> Binary: proxy.c
>>>>>>> Running on port 32454
>>>>>>> Traceback (most recent call last):
>>>>>>>  File "./grade", line 97, in ?
>>>>>>>    main()
>>>>>>>  File "./grade", line 42, in main
>>>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line
>>>>>>> 82, in urlopen
>>>>>>>    return opener.open(url)
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line
>>>>>>> 190, in open
>>>>>>>    return getattr(self, name)(url)
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>> line
>>>>>>> 313, in open_http
>>>>>>>    h.endheaders()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line 798, in endheaders
>>>>>>>    self._send_output()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line 679, in _send_output
>>>>>>>    self.send(msg)
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line 646, in send
>>>>>>>    self.connect()
>>>>>>>  File
>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>> line 630, in connect
>>>>>>>    raise socket.error, msg
>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>> 
>>>>>>> Alex
>>>>>>> 
>>>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>>>>> TCP and UDP port numbers are 16-bit values, which means the maximum
>>>>>>>> value
>>>>>>>> is
>>>>>>>> 65535.  Try something between 1024 and 65535.  You also might want to
>>>>>>>> check
>>>>>>>> to make sure that you're checking all your socket return values and
>>>>>>>> compiler
>>>>>>>> warnings.
>>>>>>>> 
>>>>>>>> --Justin
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, "Alex"
>>>>>>>> <axle@sonic.net> wrote:
>>>>>>>> 
>>>>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>>>>> messages
>>>>>>>>> below. Why is this happening?
>>>>>>>>> 
>>>>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>>>>> Binary: proxy.c
>>>>>>>>> Running on port 98235
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>   File "./grade", line 100, in ?
>>>>>>>>>     main()
>>>>>>>>>   File "./grade", line 45, in main
>>>>>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>> line 82, in urlopen
>>>>>>>>>     return opener.open(url)
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>> line 190, in open
>>>>>>>>>     return getattr(self, name)(url)
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>> line 313, in open_http
>>>>>>>>>     h.endheaders()
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>> line
>>>>>>>>> 798, in endheaders
>>>>>>>>>     self._send_output()
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>> line
>>>>>>>>> 679, in _send_output
>>>>>>>>>     self.send(msg)
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>> line
>>>>>>>>> 646, in send
>>>>>>>>>     self.connect()
>>>>>>>>>   File
>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>> line
>>>>>>>>> 630, in connect
>>>>>>>>>     raise socket.error, msg
>>>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Packet validation
Date: Sun, 28 Jan 2007 19:35:54 -0800
Lines: 17
Distribution: su
Message-ID: <epjq2s$n62$1@news.Stanford.EDU>
References: <epgrjt$931$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170041756 23746 128.12.133.106 (29 Jan 2007 03:35:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epgrjt$931$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11270

Do as much checking as you can. You will have to inspect most of the 
fields of all the packets anyways, right? Just check for crazy values as 
you go through the read procedures.

Remember, your routers are live on the Internet, so you will get all 
sorts of crazy traffic since you are accessible from any computer on the 
net.

Riju Kallivalappil wrote:
> Can we assume that all packets passed to sr_handlepacket() are of the proper 
> format and are destined for this router? Or do we need to do any validation 
> inside sr_handlepacket()?
> 
> Thanks,
> Riju 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2 how to broadcast ARP request?
Date: Sun, 28 Jan 2007 19:41:42 -0800
Lines: 20
Distribution: su
Message-ID: <epjqdn$ne3$1@news.Stanford.EDU>
References: <epjfpo$ffn$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170042103 24003 128.12.133.106 (29 Jan 2007 03:41:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epjfpo$ffn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11271

What if I'm pinging a machine that isn't on and isn't in your arp table 
what will you do? You won't know the machine isn't on until you send 
your arp packet, right? So, there is always a chance that the arp won't 
get a reply.

As for where the computer is, you can assume that the routing table is 
correct.

Dinesh Gupta wrote:
> Hi,
> 
> After getting an IP packet, shall we broadcast ARP req for hw addr from
> all router ports or shall we get the destination port from routing table
> and broadcast from only that particular port? If we broadcast from the
> particular interface then is it possible to not get reply? Because ip
> addr is correct and application servers running so no way we won't get
> it!
> 
> Thanks,
> Dinesh
.

Path: shelby.stanford.edu!myth13.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Turn off all printf for PA2?
Date: Sun, 28 Jan 2007 19:44:13 -0800
Lines: 7
Distribution: su
Message-ID: <Pine.LNX.4.44.0701281942290.306-100000@myth13.Stanford.EDU>
NNTP-Posting-Host: myth13.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170042255 24076 171.64.15.2 (29 Jan 2007 03:44:15 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11272

In the original stub code provided, the printf("*** -> Received packet of
length %d \n", len); is not in a DEBUGGING bracket of any sort. When we
submit our submission, should all printf be turned off?

Also, there are other things being displayed on the terminal. In general, what output
should we keep and what should we turn off? Thanks.

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Broadcast packets
Date: Sun, 28 Jan 2007 20:05:33 -0800
Lines: 6
Distribution: su
Message-ID: <epjrqe$o9k$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170043534 24884 127.0.0.1 (29 Jan 2007 04:05:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11273

Do we need to handle IP broadcast packets?

Thanks,
Riju 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Non TCP/UDP packets
Date: Sun, 28 Jan 2007 20:08:36 -0800
Lines: 8
Distribution: su
Message-ID: <epjs04$oeq$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170043716 25050 127.0.0.1 (29 Jan 2007 04:08:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11274

What should we do if we receive a packet that is not TCP or UDP and is 
destined for one of the router interfaces? Can we silently discard such 
packets?

Thanks,
Riju 


.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: running grading script
Date: Sun, 28 Jan 2007 20:41:53 -0800
Lines: 267
Distribution: su
Message-ID: <epjtuo$pps$1@news.Stanford.EDU>
References: <eoeheb$l9m$1@news.Stanford.EDU> <C1D00C6D.7506%jpettit@stanford.edu> <eoel8m$ob8$1@news.Stanford.EDU> <eorjfo$h9a$1@news.Stanford.EDU> <C1D6AA04.785A%jpettit@stanford.edu> <epjabj$b0v$1@news.Stanford.EDU> <C1E27B64.7CF6%jpettit@stanford.edu> <epjiuj$i52$1@news.Stanford.EDU> <C1E293BF.7CFD%jpettit@stanford.edu> <C1E2988D.7D02%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170045720 26428 127.0.0.1 (29 Jan 2007 04:42:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11275

Hi,

Thanks for the help, but after doublechecking the parameters to accept(), 
I'm still having the problem. The addrlen parameter is correctly initialized 
to sizeof(struct sockaddr), and the value always ends up as 16 (even after 
accept() returns the actual length), so I don't think is the problem. I'm 
going to try Paul's office hours tomorrow though.

Thanks,
Darius

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1E2988D.7D02%jpettit@stanford.edu...
> Sorry, I was talking to somebody while writing that last sentence, so it
> wasn't very clear.  Here's what the accept() man page has to say:
>
>    The addrlen is a value-result parameter; it should initially
>    contain the amount of space pointed to by addr; on return
>    it will contain the actual length (in bytes) of the address
>    returned.
>
> This is an easy thing to miss.  I've been stung by it myself.
>
> --Justin
>
>
> On 1/28/07 5:54 PM, in article C1E293BF.7CFD%jpettit@stanford.edu, "Justin
> Pettit" <jpettit@stanford.edu> wrote:
>
>> Did you set "addr_size" before you call accept()?  You should have a line
>> like the following before your call to accept():
>>
>>     addr_size = sizeof(addr);
>>
>> The third argument is used to both pass something in and to retrieve
>> something.
>>
>> --Justin
>>
>>
>> On 1/28/07 5:34 PM, in article epjiuj$i52$1@news.Stanford.EDU, "Darius
>> Henderson" <darius.henderson@stanford.edu> wrote:
>>
>>> Hi,
>>>
>>> I think narrowed down the problem in my code to this one snippet:
>>>
>>> if((new_sock = accept(sock_num, (struct sockaddr *)&addr, &addr_size)) 
>>>  >= 0)
>>>     printf("\nIncoming connection from %s...\n", 
>>> inet_ntoa(addr.sin_addr));
>>> else printf("Invalid socket given: %d\n", new_sock);
>>>
>>> The grading script gets here, to the accept call, but never makes it to
>>> either of printfs. The fact that I can connect just fine from my 
>>> computer
>>> makes me think the accept call and the parameters are okay, so I have no
>>> idea why the script keeps saying "connection refused." Hope this 
>>> information
>>> helps any, if not I'll just go to office hours.
>>>
>>> Thanks,
>>> Darius
>>>
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>> news:C1E27B64.7CF6%jpettit@stanford.edu...
>>>> Is it possible that you are not handling HTTP/1.1 requests as defined 
>>>> in
>>>> the
>>>> FAQ?  If you are still having trouble, I would recommend coming to 
>>>> office
>>>> hours, since it's hard to debug this without more information.
>>>>
>>>> --Justin
>>>>
>>>>
>>>> On 1/28/07 3:07 PM, in article epjabj$b0v$1@news.Stanford.EDU, "Darius
>>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've been fixing up little bugs in my proxy for PA4, but I still can't
>>>>> seeem
>>>>> to get that grading script running. The proxy never crashed on the
>>>>> queries
>>>>> from the script, at least from what I can see (entering the script's
>>>>> addresses in telnet works just fine). Any other possibilities for this
>>>>> error
>>>>> (exact same error as Alex from the post quoted below)?
>>>>>
>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>> news:C1D6AA04.785A%jpettit@stanford.edu...
>>>>>> It looks like you may be closing the socket you have listening on 
>>>>>> 32454,
>>>>>> since the script is complaining that it can't connect to your proxy.
>>>>>> You
>>>>>> may want to telnet to your proxy and manually type in the requests 
>>>>>> from
>>>>>> the
>>>>>> grading script.  Is your proxy crashing on one of the queries?
>>>>>>
>>>>>> --Justin
>>>>>>
>>>>>>
>>>>>> On 1/19/07 3:16 PM, in article eorjfo$h9a$1@news.Stanford.EDU, 
>>>>>> "Darius
>>>>>> Henderson" <darius.henderson@stanford.edu> wrote:
>>>>>>
>>>>>>> I've been testing my proxy through telnet and my browsers mostly, so 
>>>>>>> I
>>>>>>> just
>>>>>>> started using the grading script and I've got this error too. I 
>>>>>>> don't
>>>>>>> have
>>>>>>> any trouble making connections through the browsers though. Anyone 
>>>>>>> know
>>>>>>> some
>>>>>>> reasons why this would occur only with the script or if there's a 
>>>>>>> way
>>>>>>> to
>>>>>>> debug my program while the script is executing?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Darius
>>>>>>>
>>>>>>>
>>>>>>> "Alex" <axle@sonic.net> wrote in message
>>>>>>> news:eoel8m$ob8$1@news.Stanford.EDU...
>>>>>>>> I gave a port in the valid range and I still see this issue. I was
>>>>>>>> able
>>>>>>>> to
>>>>>>>> run my proxy on that port and use telnet and do GET correctly but 
>>>>>>>> I'm
>>>>>>>> still
>>>>>>>> having problems with the grading script.
>>>>>>>>
>>>>>>>> vine7:~/proj1> ./grade proxy.c 32454
>>>>>>>> Binary: proxy.c
>>>>>>>> Running on port 32454
>>>>>>>> Traceback (most recent call last):
>>>>>>>>  File "./grade", line 97, in ?
>>>>>>>>    main()
>>>>>>>>  File "./grade", line 42, in main
>>>>>>>>    foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line
>>>>>>>> 82, in urlopen
>>>>>>>>    return opener.open(url)
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line
>>>>>>>> 190, in open
>>>>>>>>    return getattr(self, name)(url)
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>> line
>>>>>>>> 313, in open_http
>>>>>>>>    h.endheaders()
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line 798, in endheaders
>>>>>>>>    self._send_output()
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line 679, in _send_output
>>>>>>>>    self.send(msg)
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line 646, in send
>>>>>>>>    self.connect()
>>>>>>>>  File
>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>> line 630, in connect
>>>>>>>>    raise socket.error, msg
>>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>>>>>> news:C1D00C6D.7506%jpettit@stanford.edu...
>>>>>>>>> TCP and UDP port numbers are 16-bit values, which means the 
>>>>>>>>> maximum
>>>>>>>>> value
>>>>>>>>> is
>>>>>>>>> 65535.  Try something between 1024 and 65535.  You also might want 
>>>>>>>>> to
>>>>>>>>> check
>>>>>>>>> to make sure that you're checking all your socket return values 
>>>>>>>>> and
>>>>>>>>> compiler
>>>>>>>>> warnings.
>>>>>>>>>
>>>>>>>>> --Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/14/07 4:21 PM, in article eoeheb$l9m$1@news.Stanford.EDU, 
>>>>>>>>> "Alex"
>>>>>>>>> <axle@sonic.net> wrote:
>>>>>>>>>
>>>>>>>>>> I was trying to run the grading script on my proxy and I get the
>>>>>>>>>> messages
>>>>>>>>>> below. Why is this happening?
>>>>>>>>>>
>>>>>>>>>> vine7:~/proj1> ./grade proxy.c 98235
>>>>>>>>>> Binary: proxy.c
>>>>>>>>>> Running on port 98235
>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>   File "./grade", line 100, in ?
>>>>>>>>>>     main()
>>>>>>>>>>   File "./grade", line 45, in main
>>>>>>>>>>     foblist.append(urllib.urlopen(url, None, proxy_map))
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>>> line 82, in urlopen
>>>>>>>>>>     return opener.open(url)
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>>> line 190, in open
>>>>>>>>>>     return getattr(self, name)(url)
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/urllib.py",
>>>>>>>>>> line 313, in open_http
>>>>>>>>>>     h.endheaders()
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>>> line
>>>>>>>>>> 798, in endheaders
>>>>>>>>>>     self._send_output()
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>>> line
>>>>>>>>>> 679, in _send_output
>>>>>>>>>>     self.send(msg)
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>>> line
>>>>>>>>>> 646, in send
>>>>>>>>>>     self.connect()
>>>>>>>>>>   File
>>>>>>>>>> "/afs/.ir/pubsw/Languages/python-2.4.3/@sys/lib/python2.4/httplib.py",
>>>>>>>>>> line
>>>>>>>>>> 630, in connect
>>>>>>>>>>     raise socket.error, msg
>>>>>>>>>> IOError: [Errno socket error] (111, 'Connection refused')
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Loopback address
Date: Sun, 28 Jan 2007 23:30:24 -0800
Lines: 4
Distribution: su
Message-ID: <epk7qh$39e$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170055825 3374 127.0.0.1 (29 Jan 2007 07:30:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11276

In the router, do we need to handle IP packets with a loopback address in 
the source or destination address field? 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: How to use gdb with router?
Date: Sun, 28 Jan 2007 23:43:02 -0800
Lines: 16
Distribution: su
Message-ID: <epk8i6$3n5$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170056582 3813 128.12.194.72 (29 Jan 2007 07:43:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11277

What is the proper way to run gdb on our router code?

Here's what I'm getting right now:

myth16:~/CS244A/hw2/stub> gdb ./sr --args -t <my topology> -r rtable
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
....

(gdb) start
No symbol table loaded.  Use the "file" command.
(gdb)

And yes, I have "-g" as a compiler flag in my Makefile.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Running out of disk quota.
Date: Mon, 29 Jan 2007 02:43:50 -0800
Lines: 4
Distribution: su
Message-ID: <epkj56$f3d$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170067430 15469 128.12.194.72 (29 Jan 2007 10:43:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11278

Can we get some disk quota allocated for this class? The default 200MB 
limit is killing me. :p

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Turn off all printf for PA2?
Date: Mon, 29 Jan 2007 10:50:27 -0800
Lines: 12
Distribution: su
Message-ID: <eplfll$do2$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701281942290.306-100000@myth13.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096629 14082 128.12.133.106 (29 Jan 2007 18:50:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0701281942290.306-100000@myth13.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11279

Please don't have anything printing when you hand in your assignments. 
Those prints are just there to get you started. We didn't want to 
surround them with our DEBUG removal scheme in case you like yours more.

Ryan Chen wrote:
> In the original stub code provided, the printf("*** -> Received packet of
> length %d \n", len); is not in a DEBUGGING bracket of any sort. When we
> submit our submission, should all printf be turned off?
> 
> Also, there are other things being displayed on the terminal. In general, what output
> should we keep and what should we turn off? Thanks.
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Broadcast packets
Date: Mon, 29 Jan 2007 10:52:13 -0800
Lines: 10
Distribution: su
Message-ID: <eplfov$do2$2@news.Stanford.EDU>
References: <epjrqe$o9k$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096735 14082 128.12.133.106 (29 Jan 2007 18:52:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epjrqe$o9k$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11280

Do you mean multicast? Those you don't have to deal with.

Riju Kallivalappil wrote:
> Do we need to handle IP broadcast packets?
> 
> Thanks,
> Riju 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Non TCP/UDP packets
Date: Mon, 29 Jan 2007 10:52:57 -0800
Lines: 12
Distribution: su
Message-ID: <eplfqb$do2$3@news.Stanford.EDU>
References: <epjs04$oeq$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096779 14082 128.12.133.106 (29 Jan 2007 18:52:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epjs04$oeq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11281

You are an IP router. Don't even care what is inside it. That is the 
beauty of protocol encapsulation.

Riju Kallivalappil wrote:
> What should we do if we receive a packet that is not TCP or UDP and is 
> destined for one of the router interfaces? Can we silently discard such 
> packets?
> 
> Thanks,
> Riju 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Loopback address
Date: Mon, 29 Jan 2007 10:53:52 -0800
Lines: 8
Distribution: su
Message-ID: <eplfs1$do2$4@news.Stanford.EDU>
References: <epk7qh$39e$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096833 14082 128.12.133.106 (29 Jan 2007 18:53:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epk7qh$39e$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11282

If it doesn't match your routing table, then don't route it. The RFC 
says IPs shouldn't ever be routed (private addresses).

Riju Kallivalappil wrote:
> In the router, do we need to handle IP packets with a loopback address in 
> the source or destination address field? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use gdb with router?
Date: Mon, 29 Jan 2007 10:54:36 -0800
Lines: 19
Distribution: su
Message-ID: <eplfte$do2$5@news.Stanford.EDU>
References: <epk8i6$3n5$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096878 14082 128.12.133.106 (29 Jan 2007 18:54:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epk8i6$3n5$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11283

I think the command is "run" instead of "start".

Yangfan Wang wrote:
> What is the proper way to run gdb on our router code?
> 
> Here's what I'm getting right now:
> 
> myth16:~/CS244A/hw2/stub> gdb ./sr --args -t <my topology> -r rtable
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> ...
> 
> (gdb) start
> No symbol table loaded.  Use the "file" command.
> (gdb)
> 
> And yes, I have "-g" as a compiler flag in my Makefile.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Running out of disk quota.
Date: Mon, 29 Jan 2007 10:55:40 -0800
Lines: 9
Distribution: su
Message-ID: <eplfve$do2$6@news.Stanford.EDU>
References: <epkj56$f3d$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170096942 14082 128.12.133.106 (29 Jan 2007 18:55:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epkj56$f3d$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11284

We did put in a request for adding 500 MB for the students. Are you 
enrolled in the class via axess? I'll talk to the other TAs and Nick 
about this.

Yangfan Wang wrote:
> Can we get some disk quota allocated for this class? The default 200MB 
> limit is killing me. :p
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Broadcast packets
Date: Mon, 29 Jan 2007 11:49:04 -0800
Lines: 15
Distribution: su
Message-ID: <eplj3i$h26$1@news.Stanford.EDU>
References: <epjrqe$o9k$1@news.Stanford.EDU> <eplfov$do2$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170100146 17478 127.0.0.1 (29 Jan 2007 19:49:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11285

I meant broadcast. What should I do if I receive a packet with an IP 
broadcast address as the destination address?

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eplfov$do2$2@news.Stanford.EDU...
> Do you mean multicast? Those you don't have to deal with.
>
> Riju Kallivalappil wrote:
>> Do we need to handle IP broadcast packets?
>>
>> Thanks,
>> Riju
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Non TCP/UDP packets
Date: Mon, 29 Jan 2007 11:52:30 -0800
Lines: 18
Distribution: su
Message-ID: <eplja0$h81$1@news.Stanford.EDU>
References: <epjs04$oeq$1@news.Stanford.EDU> <eplfqb$do2$3@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170100353 17665 127.0.0.1 (29 Jan 2007 19:52:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11286

I think it should care about what is inside if the packet's destination IP 
is one of the router interfaces. How else can it return an ICMP Port 
Unreachable message?

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eplfqb$do2$3@news.Stanford.EDU...
> You are an IP router. Don't even care what is inside it. That is the 
> beauty of protocol encapsulation.
>
> Riju Kallivalappil wrote:
>> What should we do if we receive a packet that is not TCP or UDP and is 
>> destined for one of the router interfaces? Can we silently discard such 
>> packets?
>>
>> Thanks,
>> Riju 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Loopback address
Date: Mon, 29 Jan 2007 11:59:25 -0800
Lines: 15
Distribution: su
Message-ID: <epljnu$hgi$1@news.Stanford.EDU>
References: <epk7qh$39e$1@news.Stanford.EDU> <eplfs1$do2$4@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170100798 17938 127.0.0.1 (29 Jan 2007 19:59:58 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11287

I understand that it should not be routed. But, it could be delivered 
locally if it's received on the loopback interface? Since we don't have any 
layer above to receive a locally delivered packet, we could drop it 
silently. Or we could return an ICMP error message. I'm not sure.

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eplfs1$do2$4@news.Stanford.EDU...
> If it doesn't match your routing table, then don't route it. The RFC says 
> IPs shouldn't ever be routed (private addresses).
>
> Riju Kallivalappil wrote:
>> In the router, do we need to handle IP packets with a loopback address in 
>> the source or destination address field? 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: PA2 how to broadcast ARP request?
Date: Mon, 29 Jan 2007 20:27:09 +0000 (UTC)
Lines: 30
Distribution: su
Message-ID: <epllat$ipd$1@news.Stanford.EDU>
References: <epjfpo$ffn$1@news.Stanford.EDU> <epjqdn$ne3$1@news.Stanford.EDU>
NNTP-Posting-Host: vine10.stanford.edu
X-Trace: news.Stanford.EDU 1170102429 19245 171.64.15.247 (29 Jan 2007 20:27:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11288

HI Paul,

Thanks for the explaination.
In this case how can we test it. How can we shut down these m/cs for testing
purpose. 

Thanks,
Dinesh

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote:
> What if I'm pinging a machine that isn't on and isn't in your arp table 
> what will you do? You won't know the machine isn't on until you send 
> your arp packet, right? So, there is always a chance that the arp won't 
> get a reply.

> As for where the computer is, you can assume that the routing table is 
> correct.

> Dinesh Gupta wrote:
> > Hi,
> > 
> > After getting an IP packet, shall we broadcast ARP req for hw addr from
> > all router ports or shall we get the destination port from routing table
> > and broadcast from only that particular port? If we broadcast from the
> > particular interface then is it possible to not get reply? Because ip
> > addr is correct and application servers running so no way we won't get
> > it!
> > 
> > Thanks,
> > Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Broadcast packets
Date: Mon, 29 Jan 2007 13:28:21 -0800
Lines: 7
Distribution: su
Message-ID: <eplotl$m93$1@news.Stanford.EDU>
References: <epjrqe$o9k$1@news.Stanford.EDU> <eplfov$do2$2@news.Stanford.EDU> <eplj3i$h26$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170106101 22819 127.0.0.1 (29 Jan 2007 21:28:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eplj3i$h26$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11289

Riju Kallivalappil wrote:
> I meant broadcast. What should I do if I receive a packet with an IP 
> broadcast address as the destination address?

Just go ahead and drop it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Loopback address
Date: Mon, 29 Jan 2007 13:30:13 -0800
Lines: 10
Distribution: su
Message-ID: <eplp15$m93$2@news.Stanford.EDU>
References: <epk7qh$39e$1@news.Stanford.EDU> <eplfs1$do2$4@news.Stanford.EDU> <epljnu$hgi$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170106213 22819 127.0.0.1 (29 Jan 2007 21:30:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epljnu$hgi$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11290

Riju Kallivalappil wrote:
> I understand that it should not be routed. But, it could be delivered 
> locally if it's received on the loopback interface? Since we don't have any 
> layer above to receive a locally delivered packet, we could drop it 
> silently. Or we could return an ICMP error message. I'm not sure.
> 

Just drop it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem with wireshark
Date: Mon, 29 Jan 2007 16:16:58 -0800
Lines: 30
Distribution: su
Message-ID: <epm2pe$2nr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170116206 2811 127.0.0.1 (30 Jan 2007 00:16:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11291

Hi,

When I run wireshark and and start the capture, I get the following error:
../wireshark
/afs/ir.stanford.edu/users/b/n/bneelima/CS244a/./dumpcap: line 87: cd: 
/usr/class/cs244a/wireshark-0.99.4-jdp: No such file or directory
gcc: capture-pcap-util-unix.o: No such file or directory
gcc: capture_opts.o: No such file or directory
gcc: capture_loop.o: No such file or directory
gcc: capture-pcap-util.o: No such file or directory
gcc: capture_stop_conditions.o: No such file or directory
gcc: clopts_common.o: No such file or directory
gcc: conditions.o: No such file or directory
gcc: dumpcap.o: No such file or directory
gcc: pcapio.o: No such file or directory
gcc: ringbuffer.o: No such file or directory
gcc: sync_pipe_write.o: No such file or directory
gcc: tempfile.o: No such file or directory
gcc: version_info.o: No such file or directory
gcc: unicode-utils.o: No such file or directory
gcc: wiretap/.libs/libwiretap.so: No such file or directory

Looks like it is trying to change the directory to 
/usr/class/cs244a/wireshark-0.99.4-jdp while the actual directory there 
seems to be - /usr/class/cs244a/wireshark-0.99.4/

Am I doing something wrong here?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem with wireshark
Date: Mon, 29 Jan 2007 16:27:31 -0800
Lines: 12
Distribution: su
Message-ID: <C1E3D0F3.7DA7%jpettit@stanford.edu>
References: <epm2pe$2nr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170116856 3451 127.0.0.1 (30 Jan 2007 00:27:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Problem with wireshark
Thread-Index: AcdEBW29rJI5q6/4EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11292

> When I run wireshark and and start the capture, I get the following error:
> ./wireshark
> 
> Am I doing something wrong here?

Try running it with the absolute path:

    /usr/class/cs244a/bin/wireshark

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem with wireshark
Date: Mon, 29 Jan 2007 16:38:07 -0800
Lines: 19
Distribution: su
Message-ID: <epm412$3qr$1@news.Stanford.EDU>
References: <epm2pe$2nr$1@news.Stanford.EDU> <C1E3D0F3.7DA7%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170117475 3931 127.0.0.1 (30 Jan 2007 00:37:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1E3D0F3.7DA7%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11293

On doing that getting an error saying Child process exited.
"Couldn't run /usr/class/cs244a/bin/dumpcap in child process: No such 
file or directory"

Neelima

Justin Pettit wrote:
>> When I run wireshark and and start the capture, I get the following error:
>> ./wireshark
>>
>> Am I doing something wrong here?
> 
> Try running it with the absolute path:
> 
>     /usr/class/cs244a/bin/wireshark
> 
> --Justin
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem with wireshark
Date: Mon, 29 Jan 2007 16:56:01 -0800
Lines: 30
Distribution: su
Message-ID: <C1E3D7A1.7DB0%jpettit@stanford.edu>
References: <epm2pe$2nr$1@news.Stanford.EDU> <C1E3D0F3.7DA7%jpettit@stanford.edu> <epm412$3qr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170118563 4910 127.0.0.1 (30 Jan 2007 00:56:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Problem with wireshark
Thread-Index: AcdECWj6p2N0zq/8EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11294

It looks like you are trying to run the actual dump file.  Run Wireshark
like I mentioned and then load the dump file.

--Justin


On 1/29/07 4:38 PM, in article epm412$3qr$1@news.Stanford.EDU, "Neelima
Balakrishnan" <bneelima@stanford.edu> wrote:

> On doing that getting an error saying Child process exited.
> "Couldn't run /usr/class/cs244a/bin/dumpcap in child process: No such
> file or directory"
> 
> Neelima
> 
> Justin Pettit wrote:
>>> When I run wireshark and and start the capture, I get the following error:
>>> ./wireshark
>>> 
>>> Am I doing something wrong here?
>> 
>> Try running it with the absolute path:
>> 
>>     /usr/class/cs244a/bin/wireshark
>> 
>> --Justin
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: working sample
Date: Mon, 29 Jan 2007 21:14:13 -0500
Lines: 8
Distribution: su
Message-ID: <epm9oa$8fu$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170123338 8702 127.0.0.1 (30 Jan 2007 02:15:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:11295

Topology 2 was mentioned as a sample topology in the assignment, but I 
don't think it's working.

Is there a working sample topology we can use (ping/traceroute/ftp...) 
for reference?

Thanks,
Jin
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: working sample
Date: Mon, 29 Jan 2007 19:26:12 -0800
Lines: 25
Distribution: su
Message-ID: <epme3u$bmj$1@news.Stanford.EDU>
References: <epm9oa$8fu$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170127806 11987 171.64.74.54 (30 Jan 2007 03:30:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epm9oa$8fu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11296

There is a working demo on topology 2, but the IP addresses listed in 
the assignment are likely incorrect.  Here are the correct IPs for the 
demo router:

Router IPs:
eth0: 171.67.71.20
eth1: 171.67.71.21
eth2: 171.67.71.23

Application Servers:
Ap Server 1: 171.67.71.22
Ap Server 2: 171.67.71.24

Clay


Jin Wang wrote:
> Topology 2 was mentioned as a sample topology in the assignment, but I 
> don't think it's working.
> 
> Is there a working sample topology we can use (ping/traceroute/ftp...) 
> for reference?
> 
> Thanks,
> Jin
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: "FIXME" in sr_protocol.h
Date: Mon, 29 Jan 2007 10:21:54 -0800
Lines: 43
Distribution: su
Message-ID: <epmk6h$g0c$1@news.Stanford.EDU>
References: <epi4ej$d33$1@news.Stanford.EDU> <C1E27A5E.7CF3%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170134033 16396 127.0.0.1 (30 Jan 2007 05:13:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11297

Expecting to have anywhere close to reasonable performance and finding out
the endianness dynamically is rather ridiculous and publicly mockable.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Justin Pettit" <jpettit@stanford.edu> wrote in message
news:C1E27A5E.7CF3%jpettit@stanford.edu...
> He felt that he shouldn't be using #defines to determine the endian-ness
> of
> the system.  It would be better to figure it out dynamically.  Keep in
> mind
> that Linux, Solaris, and Darwin (Mac OS X) are all available on platforms
> with the opposite endian-ness as defined there.
>
> --Justin
>
>
> On 1/28/07 4:20 AM, in article epi4ej$d33$1@news.Stanford.EDU, "Raymond
> Thang" <rlt5654@stanford.edu> wrote:
>
>> Any insight into this comment that I found in the file sr_protocol.h?
>>
>> /* FIXME
>>   * ohh how lame .. how very, very lame... how can I ever go out in
>> public
>>   * again?! /mc
>>   */
>> <system byte order #defines here>
>>
>> I can't really tell if there is actually anything wrong with the code.
>> [I don't see anything wrong, personally.]
>>
>> Some clarification would be appreciated.
>>
>> TIA
>> - Raymond
>
>



.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA#2: sanity checks on the FAQ
Date: Mon, 29 Jan 2007 21:13:07 -0800
Lines: 12
Distribution: su
Message-ID: <epmk6i$g0c$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170134034 16396 127.0.0.1 (30 Jan 2007 05:13:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11298

"You should also discard packets that are obviously corrupted e.g. if the IP 
version is not IPv4, if the packet length is negative or above the Ethernet 
MTU etc."

How does one get a negative packet length?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem with wireshark
Date: Mon, 29 Jan 2007 21:49:58 -0800
Lines: 35
Distribution: su
Message-ID: <epmma7$hn5$1@news.Stanford.EDU>
References: <epm2pe$2nr$1@news.Stanford.EDU> <C1E3D0F3.7DA7%jpettit@stanford.edu> <epm412$3qr$1@news.Stanford.EDU> <C1E3D7A1.7DB0%jpettit@stanford.edu>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170136199 18149 128.12.133.106 (30 Jan 2007 05:49:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1E3D7A1.7DB0%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11299

You can also use JEthereal. It is a java applet that can read your pcap 
files and lets you examine them.

http://yuba.stanford.edu/JEthereal/

Justin Pettit wrote:
> It looks like you are trying to run the actual dump file.  Run Wireshark
> like I mentioned and then load the dump file.
> 
> --Justin
> 
> 
> On 1/29/07 4:38 PM, in article epm412$3qr$1@news.Stanford.EDU, "Neelima
> Balakrishnan" <bneelima@stanford.edu> wrote:
> 
>> On doing that getting an error saying Child process exited.
>> "Couldn't run /usr/class/cs244a/bin/dumpcap in child process: No such
>> file or directory"
>>
>> Neelima
>>
>> Justin Pettit wrote:
>>>> When I run wireshark and and start the capture, I get the following error:
>>>> ./wireshark
>>>>
>>>> Am I doing something wrong here?
>>> Try running it with the absolute path:
>>>
>>>     /usr/class/cs244a/bin/wireshark
>>>
>>> --Justin
>>>
>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Accepting ARP replies
Date: Mon, 29 Jan 2007 22:09:26 -0800
Lines: 7
Distribution: su
Message-ID: <epmnem$iea$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170137366 18890 128.12.104.61 (30 Jan 2007 06:09:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11300

Do we need to maintain a list of arp requests that we've transmitted? 
Suppose we receive an arp reply for which for did not send an arp 
request? I'm assuming normally we would discard the packet, but can we 
assume that this wont happen?

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA#2: sanity checks on the FAQ
Date: Mon, 29 Jan 2007 22:39:48 -0800
Lines: 12
Distribution: su
Message-ID: <epmp7d$jn0$1@news.Stanford.EDU>
References: <epmk6i$g0c$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170139181 20192 127.0.0.1 (30 Jan 2007 06:39:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epmk6i$g0c$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11301

Randy Jennings wrote:
> "You should also discard packets that are obviously corrupted e.g. if the IP 
> version is not IPv4, if the packet length is negative or above the Ethernet 
> MTU etc."
> 
> How does one get a negative packet length?

I would assume if the length of the packet reported by handlepacket was 
negative.. however I don't believe that this should ever happen.  But if 
its in the FAQ maybe you should check for it =)

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Accepting ARP replies
Date: Mon, 29 Jan 2007 22:42:05 -0800
Lines: 14
Distribution: su
Message-ID: <epmpbm$jn0$2@news.Stanford.EDU>
References: <epmnem$iea$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170139318 20192 127.0.0.1 (30 Jan 2007 06:41:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epmnem$iea$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11302

Matt Page wrote:
> Do we need to maintain a list of arp requests that we've transmitted? 
> Suppose we receive an arp reply for which for did not send an arp 
> request? I'm assuming normally we would discard the packet, but can we 
> assume that this wont happen?
> 
> Thanks,
> Matt

For timeout purposes you should already be maintaining a list of who you 
have sent ARP requests for, so I would say you should check that when 
you get a reply that it is a reply for a request you have sent.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: "FIXME" in sr_protocol.h
Date: Mon, 29 Jan 2007 23:22:10 -0800
Lines: 53
Distribution: su
Message-ID: <C1E43222.7DCC%jpettit@stanford.edu>
References: <epi4ej$d33$1@news.Stanford.EDU> <C1E27A5E.7CF3%jpettit@stanford.edu> <epmk6h$g0c$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170141735 22120 127.0.0.1 (30 Jan 2007 07:22:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: "FIXME" in sr_protocol.h
Thread-Index: AcdEP1rHmWl7xrAyEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11303

No kidding, but you can do it at compile time with a configure script.

--Justin


On 1/29/07 10:21 AM, in article epmk6h$g0c$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> Expecting to have anywhere close to reasonable performance and finding out
> the endianness dynamically is rather ridiculous and publicly mockable.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1E27A5E.7CF3%jpettit@stanford.edu...
>> He felt that he shouldn't be using #defines to determine the endian-ness
>> of
>> the system.  It would be better to figure it out dynamically.  Keep in
>> mind
>> that Linux, Solaris, and Darwin (Mac OS X) are all available on platforms
>> with the opposite endian-ness as defined there.
>> 
>> --Justin
>> 
>> 
>> On 1/28/07 4:20 AM, in article epi4ej$d33$1@news.Stanford.EDU, "Raymond
>> Thang" <rlt5654@stanford.edu> wrote:
>> 
>>> Any insight into this comment that I found in the file sr_protocol.h?
>>> 
>>> /* FIXME
>>>   * ohh how lame .. how very, very lame... how can I ever go out in
>>> public
>>>   * again?! /mc
>>>   */
>>> <system byte order #defines here>
>>> 
>>> I can't really tell if there is actually anything wrong with the code.
>>> [I don't see anything wrong, personally.]
>>> 
>>> Some clarification would be appreciated.
>>> 
>>> TIA
>>> - Raymond
>> 
>> 
> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Non TCP/UDP packets
Date: Mon, 29 Jan 2007 23:50:53 -0800
Lines: 26
Distribution: su
Message-ID: <epmt2g$mk2$1@news.Stanford.EDU>
References: <epjs04$oeq$1@news.Stanford.EDU> <eplfqb$do2$3@news.Stanford.EDU> <eplja0$h81$1@news.Stanford.EDU>
NNTP-Posting-Host: paralax.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170143120 23170 172.24.74.102 (30 Jan 2007 07:45:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <eplja0$h81$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11304

Sorry, I missed the part about it being to the router interfaces.

I think there is an ICMP Protocol Unknown response. Just send that one 
if there is one, if not, pick some other ICMP message, but you should 
respond telling the other machine that you don't understand whatever 
they are trying to talk to you about.

Riju Kallivalappil wrote:
> I think it should care about what is inside if the packet's destination IP 
> is one of the router interfaces. How else can it return an ICMP Port 
> Unreachable message?
> 
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:eplfqb$do2$3@news.Stanford.EDU...
>> You are an IP router. Don't even care what is inside it. That is the 
>> beauty of protocol encapsulation.
>>
>> Riju Kallivalappil wrote:
>>> What should we do if we receive a packet that is not TCP or UDP and is 
>>> destined for one of the router interfaces? Can we silently discard such 
>>> packets?
>>>
>>> Thanks,
>>> Riju 
> 
> 
.

Path: shelby.stanford.edu!myth20.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [PA2] sr_init() before sr_read_from_server()?
Date: Tue, 30 Jan 2007 00:10:36 -0800
Lines: 14
Distribution: su
Message-ID: <Pine.LNX.4.44.0701300002500.17562-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170144638 27815 171.64.15.38 (30 Jan 2007 08:10:38 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11305


It seems somewhat logical to me that in sr_init() I should be able to
know/store my router's physical MAC address so that later when I ARP reply
whoever I can package that into an ARP reply.

However, in the stub code, sr_read_from_server contains a portion of the
code that gets this particular hardware information, namely, the VNSHWINFO
case statement, and this won't call the student's sr_handlepacket(). So it
seems to me that I won't be able to store my router's MAC address until
the first time sr_handlepacket is called in which I will need to look it
up in the sr instance...

Is this correct or am I thinking wrong? Thanks.

.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ARP timeouts
Date: Tue, 30 Jan 2007 00:56:33 -0800
Lines: 10
Distribution: su
Message-ID: <epn181$ub$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170147393 971 128.12.104.53 (30 Jan 2007 08:56:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11306

Hi--

The class FAQ recommends an ARP cache timeout on the order of 15 
seconds. Stevens recommends ones on the other of 20 minutes. Is this 
simply indicative of the fact that no one can agree what the correct 
value is, or is there rationale for using a shorter time period in VNS?

Cheers,
Peter

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Tue, 30 Jan 2007 01:10:33 -0800
Lines: 21
Distribution: su
Message-ID: <C1E44B89.7DDB%jpettit@stanford.edu>
References: <epn181$ub$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170148237 1789 127.0.0.1 (30 Jan 2007 09:10:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ARP timeouts
Thread-Index: AcdETn7evTrNerBBEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11307

I think the short timeout in VNS is more a function of easing our testing.
20 minutes is common in real systems.

--Justin


On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
Pawlowski" <pawlowski@stanford.edu> wrote:

> Hi--
> 
> The class FAQ recommends an ARP cache timeout on the order of 15
> seconds. Stevens recommends ones on the other of 20 minutes. Is this
> simply indicative of the fact that no one can agree what the correct
> value is, or is there rationale for using a shorter time period in VNS?
> 
> Cheers,
> Peter
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Sleep()
Date: Tue, 30 Jan 2007 03:40:45 -0800
Lines: 7
Distribution: su
Message-ID: <epnart$7o9$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170157245 7945 128.12.104.61 (30 Jan 2007 11:40:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11308

I'm tired and can't remember if sleep() forces a context switch or not 
(ie doesn't busy wait and is thus suitable for use inside my arp cache 
timeout thread). Man and Info aren't particularly helpful. Someone help 
a brother out.

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Sleep()
Date: Tue, 30 Jan 2007 09:50:02 -0800
Lines: 18
Distribution: su
Message-ID: <C1E4C54A.7DF5%jpettit@stanford.edu>
References: <epnart$7o9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170179409 29487 127.0.0.1 (30 Jan 2007 17:50:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Sleep()
Thread-Index: AcdElxEKT9yIsbCKEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11309

It doesn't busy wait, but that particular thread of execution can't do
anything until the time has elapsed.  Any other threads/process are not
affected by the sleep and will execute.

--Justin

On 1/30/07 3:40 AM, in article epnart$7o9$1@news.Stanford.EDU, "Matt Page"
<mpage@stanford.edu> wrote:

> I'm tired and can't remember if sleep() forces a context switch or not
> (ie doesn't busy wait and is thus suitable for use inside my arp cache
> timeout thread). Man and Info aren't particularly helpful. Someone help
> a brother out.
> 
> Thanks,
> Matt


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] sr_init() before sr_read_from_server()?
Date: Tue, 30 Jan 2007 12:56:34 -0800
Lines: 22
Distribution: su
Message-ID: <epoblk$92t$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0701300002500.17562-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170190837 9309 171.64.74.54 (30 Jan 2007 21:00:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.44.0701300002500.17562-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11310

You really don't need to do anything special to store the MAC addresses 
for the router- the stub code ensures that these fields are initialized 
before sr_handlepacket() is called the first time.  At that point, you 
need to look up the correct interface in the sr instance's interface 
list and retrieve the correct MAC address- remember that you could get 
an ARP request/reply for any of the router's three network interfaces.

Clay
Ryan Chen wrote:
> It seems somewhat logical to me that in sr_init() I should be able to
> know/store my router's physical MAC address so that later when I ARP reply
> whoever I can package that into an ARP reply.
> 
> However, in the stub code, sr_read_from_server contains a portion of the
> code that gets this particular hardware information, namely, the VNSHWINFO
> case statement, and this won't call the student's sr_handlepacket(). So it
> seems to me that I won't be able to store my router's MAC address until
> the first time sr_handlepacket is called in which I will need to look it
> up in the sr instance...
> 
> Is this correct or am I thinking wrong? Thanks.
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 solutions
Date: Tue, 30 Jan 2007 15:07:23 -0800
Lines: 6
Distribution: su
Message-ID: <epoj3e$f31$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170198446 15457 171.64.74.36 (30 Jan 2007 23:07:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11311

Hi,

Where can I find PS1 solutions?

Thanks,
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: "Matt Page" <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Cache timeout strategy
Date: Tue, 30 Jan 2007 17:30:39 -0800
Lines: 17
Distribution: su
Message-ID: <eporg2$lr0$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
X-Trace: news.Stanford.EDU 1170207042 22368 128.12.104.45 (31 Jan 2007 01:30:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11312

Is it better to have a single thread that checks the arp cache every 15 
seconds
 and times out entries or to spawn a new thread any time an entry is added 
that
 sleeps for 15 seconds and then removes it from the cache?

A single thread wouldn't be able to *strictly* enforce the 15 second timeout
policy as an entry added right after the timeout thread ran would stay in 
the
cache for close to twice the timeout period.

How strictly must we enforce the timeout period?

Thanks,
Matt 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA#2: sanity checks on the FAQ
Date: Tue, 30 Jan 2007 17:56:49 -0800
Lines: 28
Distribution: su
Message-ID: <eposvl$nav$1@news.Stanford.EDU>
References: <epmk6i$g0c$2@news.Stanford.EDU> <epmp7d$jn0$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170208565 23903 127.0.0.1 (31 Jan 2007 01:56:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11313

It's sent in as an unsigned int.  Yes, we could range check it, but when I 
check if an unsigned int is less than zero, it tells me I am doing something 
rather stupid.  I do not see how someone could sanely consider the length 
field in the IP header as anything but unsigned.

I don't get it.

Sincerely,
Randy Jennings

The squirrels are your friends!

"David Erickson" <derickso@stanford.edu> wrote in message 
news:epmp7d$jn0$1@news.Stanford.EDU...
> Randy Jennings wrote:
>> "You should also discard packets that are obviously corrupted e.g. if the 
>> IP version is not IPv4, if the packet length is negative or above the 
>> Ethernet MTU etc."
>>
>> How does one get a negative packet length?
>
> I would assume if the length of the packet reported by handlepacket was 
> negative.. however I don't believe that this should ever happen.  But if 
> its in the FAQ maybe you should check for it =)
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cache timeout strategy
Date: Tue, 30 Jan 2007 20:14:22 -0800
Lines: 23
Distribution: su
Message-ID: <epp5ak$su9$1@news.Stanford.EDU>
References: <eporg2$lr0$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170217108 29641 171.64.74.54 (31 Jan 2007 04:18:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eporg2$lr0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11314

Either strategy is acceptable- the 15 second timeout for ARP cache 
entries is meant as a guideline for your expiration strategy and settings.

Clay

Matt Page wrote:
> Is it better to have a single thread that checks the arp cache every 15 
> seconds
>  and times out entries or to spawn a new thread any time an entry is added 
> that
>  sleeps for 15 seconds and then removes it from the cache?
> 
> A single thread wouldn't be able to *strictly* enforce the 15 second timeout
> policy as an entry added right after the timeout thread ran would stay in 
> the
> cache for close to twice the timeout period.
> 
> How strictly must we enforce the timeout period?
> 
> Thanks,
> Matt 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Spawning new threads.
Date: Tue, 30 Jan 2007 20:27:06 -0800
Lines: 7
Distribution: su
Message-ID: <epp5qm$15$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170217623 37 128.12.194.72 (31 Jan 2007 04:27:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11315

Where can I find a good resource on learning how to spawn new threads in 
  Unix?

We learned the theory in CS140, but a quick review and some practical 
details on threads in Unix would be very helpful.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Running out of disk quota.
Date: Tue, 30 Jan 2007 20:28:10 -0800
Lines: 15
Distribution: su
Message-ID: <epp5sm$15$2@news.Stanford.EDU>
References: <epkj56$f3d$1@news.Stanford.EDU> <eplfve$do2$6@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170217687 37 128.12.194.72 (31 Jan 2007 04:28:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eplfve$do2$6@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11316

Yep, I'm in the class.

-Yangfan

Paul Tarjan (TA) wrote:
> We did put in a request for adding 500 MB for the students. Are you 
> enrolled in the class via axess? I'll talk to the other TAs and Nick 
> about this.
> 
> Yangfan Wang wrote:
> 
>> Can we get some disk quota allocated for this class? The default 200MB 
>> limit is killing me. :p
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Non TCP/UDP packets
Date: Tue, 30 Jan 2007 21:17:17 -0800
Lines: 36
Distribution: su
Message-ID: <epp8nh$221$1@news.Stanford.EDU>
References: <epjs04$oeq$1@news.Stanford.EDU> <eplfqb$do2$3@news.Stanford.EDU> <eplja0$h81$1@news.Stanford.EDU> <epmt2g$mk2$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170220593 2113 127.0.0.1 (31 Jan 2007 05:16:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11317

That is contrary to the FAQ answer on what ICMP messages we have to 
generate.  Does the newsgroup (post by a TA, of course) or the FAQ take 
precedence?

Sincerely,
Randy Jennings

The squirrels are your friends!
"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:epmt2g$mk2$1@news.Stanford.EDU...
> Sorry, I missed the part about it being to the router interfaces.
>
> I think there is an ICMP Protocol Unknown response. Just send that one if 
> there is one, if not, pick some other ICMP message, but you should respond 
> telling the other machine that you don't understand whatever they are 
> trying to talk to you about.
>
> Riju Kallivalappil wrote:
>> I think it should care about what is inside if the packet's destination 
>> IP is one of the router interfaces. How else can it return an ICMP Port 
>> Unreachable message?
>>
>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
>> news:eplfqb$do2$3@news.Stanford.EDU...
>>> You are an IP router. Don't even care what is inside it. That is the 
>>> beauty of protocol encapsulation.
>>>
>>> Riju Kallivalappil wrote:
>>>> What should we do if we receive a packet that is not TCP or UDP and is 
>>>> destined for one of the router interfaces? Can we silently discard such 
>>>> packets?
>>>>
>>>> Thanks,
>>>> Riju
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Accepting ARP replies
Date: Tue, 30 Jan 2007 21:19:45 -0800
Lines: 26
Distribution: su
Message-ID: <epp8s4$24d$1@news.Stanford.EDU>
References: <epmnem$iea$1@news.Stanford.EDU> <epmpbm$jn0$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170220741 2189 127.0.0.1 (31 Jan 2007 05:19:01 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11318

Whether you have record of sending the ARP request determines if you will be 
sending a packet because of the response, but should you put the IP-MAC in 
your arp cache?  I can see arguments both ways...

Sincerely,
Randy Jennings

The squirrels are your friends!
"David Erickson" <derickso@stanford.edu> wrote in message 
news:epmpbm$jn0$2@news.Stanford.EDU...
> Matt Page wrote:
>> Do we need to maintain a list of arp requests that we've transmitted? 
>> Suppose we receive an arp reply for which for did not send an arp 
>> request? I'm assuming normally we would discard the packet, but can we 
>> assume that this wont happen?
>>
>> Thanks,
>> Matt
>
> For timeout purposes you should already be maintaining a list of who you 
> have sent ARP requests for, so I would say you should check that when you 
> get a reply that it is a reply for a request you have sent.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Spawning new threads.
Date: Tue, 30 Jan 2007 21:14:15 -0800
Lines: 11
Distribution: su
Message-ID: <epp8qt$1u5$1@news.Stanford.EDU>
References: <epp5qm$15$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170220746 1989 171.64.74.54 (31 Jan 2007 05:19:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epp5qm$15$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11319

'man pthreads' is a good place to start.

Clay
Yangfan Wang wrote:
> Where can I find a good resource on learning how to spawn new threads in 
>  Unix?
> 
> We learned the theory in CS140, but a quick review and some practical 
> details on threads in Unix would be very helpful.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cache timeout strategy
Date: Tue, 30 Jan 2007 21:23:49 -0800
Lines: 30
Distribution: su
Message-ID: <epp93p$2cg$1@news.Stanford.EDU>
References: <eporg2$lr0$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170220985 2448 127.0.0.1 (31 Jan 2007 05:23:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11320

There is another strategy.  When the timeout thread goes back to sleep, it 
can adjust the sleep time based on the request that is the closest to timing 
out.  (I think this adjustable timeout is common practice on select loops 
with timeouts.)

Sincerely,
Randy Jennings

The squirrels are your friends!
"Matt Page" <mpage@stanford.edu> wrote in message 
news:eporg2$lr0$1@news.Stanford.EDU...
> Is it better to have a single thread that checks the arp cache every 15 
> seconds
> and times out entries or to spawn a new thread any time an entry is added 
> that
> sleeps for 15 seconds and then removes it from the cache?
>
> A single thread wouldn't be able to *strictly* enforce the 15 second 
> timeout
> policy as an entry added right after the timeout thread ran would stay in 
> the
> cache for close to twice the timeout period.
>
> How strictly must we enforce the timeout period?
>
> Thanks,
> Matt
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Accepting ARP replies
Date: Tue, 30 Jan 2007 22:54:47 -0800
Lines: 40
Distribution: su
Message-ID: <C1E57D37.7E48%jpettit@stanford.edu>
References: <epmnem$iea$1@news.Stanford.EDU> <epmpbm$jn0$2@news.Stanford.EDU> <epp8s4$24d$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170226490 6509 127.0.0.1 (31 Jan 2007 06:54:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Accepting ARP replies
Thread-Index: AcdFBLHj8EVrYLD3EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11321

There are obvious performance advantages to caching information that you may
not have requested.  However, most modern systems do not accept these for
security reasons.  There are a number of very serious ARP and DNS poisoning
attacks that were a big deal a few years ago.  By flooding the network with
fake responses, the attacker can redirect traffic to his/her system.

--Justin


On 1/30/07 9:19 PM, in article epp8s4$24d$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> Whether you have record of sending the ARP request determines if you will be
> sending a packet because of the response, but should you put the IP-MAC in
> your arp cache?  I can see arguments both ways...
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "David Erickson" <derickso@stanford.edu> wrote in message
> news:epmpbm$jn0$2@news.Stanford.EDU...
>> Matt Page wrote:
>>> Do we need to maintain a list of arp requests that we've transmitted?
>>> Suppose we receive an arp reply for which for did not send an arp
>>> request? I'm assuming normally we would discard the packet, but can we
>>> assume that this wont happen?
>>> 
>>> Thanks,
>>> Matt
>> 
>> For timeout purposes you should already be maintaining a list of who you
>> have sent ARP requests for, so I would say you should check that when you
>> get a reply that it is a reply for a request you have sent.
>> 
>> -David 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Non TCP/UDP packets
Date: Tue, 30 Jan 2007 23:03:26 -0800
Lines: 48
Distribution: su
Message-ID: <C1E57F3E.7E4C%jpettit@stanford.edu>
References: <epjs04$oeq$1@news.Stanford.EDU> <eplfqb$do2$3@news.Stanford.EDU> <eplja0$h81$1@news.Stanford.EDU> <epmt2g$mk2$1@news.Stanford.EDU> <epp8nh$221$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170227009 6990 127.0.0.1 (31 Jan 2007 07:03:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Non TCP/UDP packets
Thread-Index: AcdFBec8JbypiLD5EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11322

Paul responded with what a router should generate in that circumstance.  The
FAQ specifies what your project must support.  I think you're safe in either
case. 

--Justin


On 1/30/07 9:17 PM, in article epp8nh$221$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> That is contrary to the FAQ answer on what ICMP messages we have to
> generate.  Does the newsgroup (post by a TA, of course) or the FAQ take
> precedence?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message
> news:epmt2g$mk2$1@news.Stanford.EDU...
>> Sorry, I missed the part about it being to the router interfaces.
>> 
>> I think there is an ICMP Protocol Unknown response. Just send that one if
>> there is one, if not, pick some other ICMP message, but you should respond
>> telling the other machine that you don't understand whatever they are
>> trying to talk to you about.
>> 
>> Riju Kallivalappil wrote:
>>> I think it should care about what is inside if the packet's destination
>>> IP is one of the router interfaces. How else can it return an ICMP Port
>>> Unreachable message?
>>> 
>>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message
>>> news:eplfqb$do2$3@news.Stanford.EDU...
>>>> You are an IP router. Don't even care what is inside it. That is the
>>>> beauty of protocol encapsulation.
>>>> 
>>>> Riju Kallivalappil wrote:
>>>>> What should we do if we receive a packet that is not TCP or UDP and is
>>>>> destined for one of the router interfaces? Can we silently discard such
>>>>> packets?
>>>>> 
>>>>> Thanks,
>>>>> Riju
>>> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS1 solutions
Date: Tue, 30 Jan 2007 23:17:57 -0800
Lines: 11
Distribution: su
Message-ID: <eppg3a$7km$1@news.Stanford.EDU>
References: <epoj3e$f31$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170228162 7830 171.64.74.54 (31 Jan 2007 07:22:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epoj3e$f31$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11323

The TAs are putting together a solution set.  We'll let you know when 
it's made available.

Clay
Jad Naous wrote:
> Hi,
> 
> Where can I find PS1 solutions?
> 
> Thanks,
> Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ICMP reply assumption
Date: Tue, 30 Jan 2007 23:27:29 -0800
Lines: 13
Distribution: su
Message-ID: <eppgd1$7pa$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170228449 7978 128.12.104.53 (31 Jan 2007 07:27:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11324

Hello--

Is it safe to assume that if we recieve a packet from a certain host 
over a certain interface, and that packet warrants an ICMP response 
(for whatever reason), that is it safe to send that response over the 
interface on which it was recieved via the router which send it to us? 
Or, should we do a full route/ARP lookup for every outgoing case, 
regardless of such insight (because perhaps routes are not always 
transative)?

Thanks!
Peter

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Byte ordering in struct sr_if.
Date: Tue, 30 Jan 2007 23:50:15 -0800
Lines: 9
Distribution: su
Message-ID: <epphnj$8ut$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170229811 9181 128.12.194.72 (31 Jan 2007 07:50:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11325

Um, why are the IP addresses in the list of interfaces in network byte 
order? This is very counter-intuitive for me.

Also, what about the rest of the data in the interface table? The 
routing table?

Or, am I doing something very screwy with my code?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Byte ordering in struct sr_if.
Date: Wed, 31 Jan 2007 00:14:59 -0800
Lines: 14
Distribution: su
Message-ID: <eppj5v$dk9$1@news.Stanford.EDU>
References: <epphnj$8ut$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170231295 13961 128.12.194.72 (31 Jan 2007 08:14:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epphnj$8ut$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11326

Or perhaps the structs in sr_protocol.h is doing the conversions for me?

-Yangfan

Yangfan Wang wrote:
> Um, why are the IP addresses in the list of interfaces in network byte 
> order? This is very counter-intuitive for me.
> 
> Also, what about the rest of the data in the interface table? The 
> routing table?
> 
> Or, am I doing something very screwy with my code?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Byte ordering in struct sr_if.
Date: Wed, 31 Jan 2007 00:29:44 -0800
Lines: 21
Distribution: su
Message-ID: <eppk1j$e7q$1@news.Stanford.EDU>
References: <epphnj$8ut$1@news.Stanford.EDU> <eppj5v$dk9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170232180 14586 128.12.194.72 (31 Jan 2007 08:29:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eppj5v$dk9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11327

Never mind. Those are 8-bit values, which appearantly don't get affected 
by byte ordering.

-Yangfan

Yangfan Wang wrote:
> Or perhaps the structs in sr_protocol.h is doing the conversions for me?
> 
> -Yangfan
> 
> Yangfan Wang wrote:
> 
>> Um, why are the IP addresses in the list of interfaces in network byte 
>> order? This is very counter-intuitive for me.
>>
>> Also, what about the rest of the data in the interface table? The 
>> routing table?
>>
>> Or, am I doing something very screwy with my code?
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cache timeout strategy
Date: Wed, 31 Jan 2007 01:24:34 -0800
Lines: 34
Distribution: su
Message-ID: <eppn5k$g78$1@news.Stanford.EDU>
References: <eporg2$lr0$1@news.Stanford.EDU> <epp93p$2cg$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170235380 16616 128.12.134.140 (31 Jan 2007 09:23:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
In-Reply-To: <epp93p$2cg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11328

Or you can make the thread sleep for a second or two instead of the full
15 seconds.

Randy Jennings wrote:
> There is another strategy.  When the timeout thread goes back to sleep, it 
> can adjust the sleep time based on the request that is the closest to timing 
> out.  (I think this adjustable timeout is common practice on select loops 
> with timeouts.)
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Matt Page" <mpage@stanford.edu> wrote in message 
> news:eporg2$lr0$1@news.Stanford.EDU...
>> Is it better to have a single thread that checks the arp cache every 15 
>> seconds
>> and times out entries or to spawn a new thread any time an entry is added 
>> that
>> sleeps for 15 seconds and then removes it from the cache?
>>
>> A single thread wouldn't be able to *strictly* enforce the 15 second 
>> timeout
>> policy as an entry added right after the timeout thread ran would stay in 
>> the
>> cache for close to twice the timeout period.
>>
>> How strictly must we enforce the timeout period?
>>
>> Thanks,
>> Matt
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Byte ordering in struct sr_if.
Date: Wed, 31 Jan 2007 01:28:04 -0800
Lines: 27
Distribution: su
Message-ID: <eppnms$ge7$1@news.Stanford.EDU>
References: <epphnj$8ut$1@news.Stanford.EDU> <eppj5v$dk9$1@news.Stanford.EDU> <eppk1j$e7q$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170235932 16839 171.64.74.54 (31 Jan 2007 09:32:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eppk1j$e7q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11329

Exactly.  Byte ordering refers to which byte in a 16 or 32 bit integer 
contains the most significant and least significant bits- an 8-bit value 
thus isn't effected by byte ordering issues.

Clay
Yangfan Wang wrote:
> Never mind. Those are 8-bit values, which appearantly don't get affected 
> by byte ordering.
> 
> -Yangfan
> 
> Yangfan Wang wrote:
>> Or perhaps the structs in sr_protocol.h is doing the conversions for me?
>>
>> -Yangfan
>>
>> Yangfan Wang wrote:
>>
>>> Um, why are the IP addresses in the list of interfaces in network 
>>> byte order? This is very counter-intuitive for me.
>>>
>>> Also, what about the rest of the data in the interface table? The 
>>> routing table?
>>>
>>> Or, am I doing something very screwy with my code?
>>>
>>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Byte ordering in struct sr_if.
Date: Wed, 31 Jan 2007 01:34:49 -0800
Lines: 35
Distribution: su
Message-ID: <eppnrl$gjg$1@news.Stanford.EDU>
References: <epphnj$8ut$1@news.Stanford.EDU> <eppj5v$dk9$1@news.Stanford.EDU> <eppk1j$e7q$1@news.Stanford.EDU> <eppnms$ge7$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170236085 17008 128.12.194.72 (31 Jan 2007 09:34:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eppnms$ge7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11330

Hmm, but the IP addresses are 32 bits though. The IP values in the 
interface table appear to be in network byte order. Or is it just me?

-Yangfan

Clay Collier wrote:
> Exactly.  Byte ordering refers to which byte in a 16 or 32 bit integer 
> contains the most significant and least significant bits- an 8-bit value 
> thus isn't effected by byte ordering issues.
> 
> Clay
> Yangfan Wang wrote:
> 
>> Never mind. Those are 8-bit values, which appearantly don't get 
>> affected by byte ordering.
>>
>> -Yangfan
>>
>> Yangfan Wang wrote:
>>
>>> Or perhaps the structs in sr_protocol.h is doing the conversions for me?
>>>
>>> -Yangfan
>>>
>>> Yangfan Wang wrote:
>>>
>>>> Um, why are the IP addresses in the list of interfaces in network 
>>>> byte order? This is very counter-intuitive for me.
>>>>
>>>> Also, what about the rest of the data in the interface table? The 
>>>> routing table?
>>>>
>>>> Or, am I doing something very screwy with my code?
>>>>
>>>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Byte ordering in struct sr_if.
Date: Wed, 31 Jan 2007 01:41:02 -0800
Lines: 44
Distribution: su
Message-ID: <eppo7e$grj$1@news.Stanford.EDU>
References: <epphnj$8ut$1@news.Stanford.EDU> <eppj5v$dk9$1@news.Stanford.EDU> <eppk1j$e7q$1@news.Stanford.EDU> <eppnms$ge7$1@news.Stanford.EDU> <eppnrl$gjg$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170236462 17267 128.12.104.53 (31 Jan 2007 09:41:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11331

They're in network byte order. There's a previous posting about this.

Cheers,
Peter

On 2007-01-31 01:34:49 -0800, Yangfan Wang <yfw@stanford.edu> said:

> Hmm, but the IP addresses are 32 bits though. The IP values in the 
> interface table appear to be in network byte order. Or is it just me?
> 
> -Yangfan
> 
> Clay Collier wrote:
>> Exactly.  Byte ordering refers to which byte in a 16 or 32 bit integer 
>> contains the most significant and least significant bits- an 8-bit 
>> value thus isn't effected by byte ordering issues.
>> 
>> Clay
>> Yangfan Wang wrote:
>> 
>>> Never mind. Those are 8-bit values, which appearantly don't get 
>>> affected by byte ordering.
>>> 
>>> -Yangfan
>>> 
>>> Yangfan Wang wrote:
>>> 
>>>> Or perhaps the structs in sr_protocol.h is doing the conversions for me?
>>>> 
>>>> -Yangfan
>>>> 
>>>> Yangfan Wang wrote:
>>>> 
>>>>> Um, why are the IP addresses in the list of interfaces in network byte 
>>>>> order? This is very counter-intuitive for me.
>>>>> 
>>>>> Also, what about the rest of the data in the interface table? The 
>>>>> routing table?
>>>>> 
>>>>> Or, am I doing something very screwy with my code?
>>>>> 
>>>>> -Yangfan


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Still getting bad checksum in ICMP
Date: Wed, 31 Jan 2007 01:41:06 -0800
Lines: 17
Distribution: su
Message-ID: <eppo7e$gs7$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170236462 17287 128.12.194.72 (31 Jan 2007 09:41:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11332

 From the FAQ:

"Ethereal reports that the ICMP checksums generated by the unix ping 
application are wrong. What is going on!?

The stub code only saves the first 96 bytes of the packets it receives 
and the generated ICMP packets are 98 bytes, hence Ethereal's checksum 
does not take into account the last 2 bytes. The latest version of the 
stub code has the packet dump length increased to 100 bytes. You may 
also modify sr_router.h to increase PACKET_DUMP_SIZE yourself."

It appears that my sr_router.h had its PACKET_DUMP_SIZE increased to 
1024, but Wireshark is still telling me that the ICMP checksum is incorrect.

I do need to check this checksum, right?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 01:37:09 -0800
Lines: 24
Distribution: su
Message-ID: <eppo80$gsd$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170236480 17293 171.64.74.54 (31 Jan 2007 09:41:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eppgd1$7pa$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11333

It's probably a better idea to treat all of the outgoing packets the 
same and run them through the routing table lookup- ARP cache - ARP 
request process rather than pull information from the link layer up in 
as inputs to the ICMP protocol.  While it's not really an issue in the 
specific topologies that you have for this assignment, it is certainly 
possible to have a temporary or permanent asymmetric route between two 
hosts.

Clay

Peter Pawlowski wrote:
> Hello--
> 
> Is it safe to assume that if we recieve a packet from a certain host 
> over a certain interface, and that packet warrants an ICMP response (for 
> whatever reason), that is it safe to send that response over the 
> interface on which it was recieved via the router which send it to us? 
> Or, should we do a full route/ARP lookup for every outgoing case, 
> regardless of such insight (because perhaps routes are not always 
> transative)?
> 
> Thanks!
> Peter
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2 how to broadcast ARP request?
Date: Wed, 31 Jan 2007 01:54:10 -0800
Lines: 38
Distribution: su
Message-ID: <eppp7q$hct$1@news.Stanford.EDU>
References: <epjfpo$ffn$1@news.Stanford.EDU> <epjqdn$ne3$1@news.Stanford.EDU> <epllat$ipd$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170237501 17821 171.64.74.54 (31 Jan 2007 09:58:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epllat$ipd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11334

Coming up with a method to test unreachable hosts is part of your task 
for this assignment.  It's entirely possible to ensure that your router 
will send out ARP requests that it never hears replies to without 
needing to be able to do anything to any machine in your topology other 
than your router.

Clay
Dinesh Gupta wrote:
> HI Paul,
> 
> Thanks for the explaination.
> In this case how can we test it. How can we shut down these m/cs for testing
> purpose. 
> 
> Thanks,
> Dinesh
> 
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote:
>> What if I'm pinging a machine that isn't on and isn't in your arp table 
>> what will you do? You won't know the machine isn't on until you send 
>> your arp packet, right? So, there is always a chance that the arp won't 
>> get a reply.
> 
>> As for where the computer is, you can assume that the routing table is 
>> correct.
> 
>> Dinesh Gupta wrote:
>>> Hi,
>>>
>>> After getting an IP packet, shall we broadcast ARP req for hw addr from
>>> all router ports or shall we get the destination port from routing table
>>> and broadcast from only that particular port? If we broadcast from the
>>> particular interface then is it possible to not get reply? Because ip
>>> addr is correct and application servers running so no way we won't get
>>> it!
>>>
>>> Thanks,
>>> Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Still getting bad checksum in ICMP
Date: Wed, 31 Jan 2007 12:49:59 -0800
Lines: 24
Distribution: su
Message-ID: <epqvdk$nb9$1@news.Stanford.EDU>
References: <eppo7e$gs7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170276596 23913 127.0.0.1 (31 Jan 2007 20:49:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eppo7e$gs7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11335

Yangfan Wang wrote:
>  From the FAQ:
> 
> "Ethereal reports that the ICMP checksums generated by the unix ping 
> application are wrong. What is going on!?
> 
> The stub code only saves the first 96 bytes of the packets it receives 
> and the generated ICMP packets are 98 bytes, hence Ethereal's checksum 
> does not take into account the last 2 bytes. The latest version of the 
> stub code has the packet dump length increased to 100 bytes. You may 
> also modify sr_router.h to increase PACKET_DUMP_SIZE yourself."
> 
> It appears that my sr_router.h had its PACKET_DUMP_SIZE increased to 
> 1024, but Wireshark is still telling me that the ICMP checksum is 
> incorrect.
> 
> I do need to check this checksum, right?
> 
> -Yangfan

The ICMP replies you create do need to pass the checksum test otherwise 
they may not be accepted by the host that sent the original packet.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 12:53:00 -0800
Lines: 40
Distribution: su
Message-ID: <epqvhv$nk0$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170276736 24192 127.0.0.1 (31 Jan 2007 20:52:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11336

I thought that the Ethernet source address was included in the packet for 
just this reason...  You can still run the packet through the regular 
routing table lookup/ARP cache, just put the link address in your ARP cache 
before you do so.  Are you saying that we should only do so for IP's on the 
same network as us?  That makes partial sense to me.

Justin raised an important security concern, but if you are just going to 
send out an ARP anyway, the same malicious person sending the packet would 
just respond to the ARP also.

Sincerely,
Randy Jennings

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eppo80$gsd$1@news.Stanford.EDU...
> It's probably a better idea to treat all of the outgoing packets the same 
> and run them through the routing table lookup- ARP cache - ARP request 
> process rather than pull information from the link layer up in as inputs 
> to the ICMP protocol.  While it's not really an issue in the specific 
> topologies that you have for this assignment, it is certainly possible to 
> have a temporary or permanent asymmetric route between two hosts.
>
> Clay
>
> Peter Pawlowski wrote:
>> Hello--
>>
>> Is it safe to assume that if we recieve a packet from a certain host over 
>> a certain interface, and that packet warrants an ICMP response (for 
>> whatever reason), that is it safe to send that response over the 
>> interface on which it was recieved via the router which send it to us? 
>> Or, should we do a full route/ARP lookup for every outgoing case, 
>> regardless of such insight (because perhaps routes are not always 
>> transative)?
>>
>> Thanks!
>> Peter
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 14:57:25 -0800
Lines: 71
Distribution: su
Message-ID: <epr74p$3so$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170284505 3992 171.64.74.54 (31 Jan 2007 23:01:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epqvhv$nk0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11337

In regards to the unsolicited ARP issue: a solicited ARP reply COULD 
contain bad information, but since there's nothing in the ARP protocol 
that calls for someone to send out unsolicited ARP replies if you 
receive an unsolicited ARP reply, you already know something funny is 
going on.

Regarding the routing issue- if you use the ethernet header to route 
packets back rather than consulting the routing table, you can end up in 
a situation where the router is ignoring the routing table- which may 
lead to worse routes, or could just be a pain to diagnose.

Consider this topology:

  /B\
A   D
  \C/

A's routing table says 'send packets to D via B'
D's routing table says 'send packets to A via C'

Now, if you ignore the routing table and just look at the ethernet 
header, A is going to attempt to send packets to D via C rather than B. 
  If the links are directionally asymetric in some way- in terms of 
upload vs. download speeds (think cable modems), filtering (host C may 
be configured to block packets from reaching D), then you may end up in 
a situation where your packets are traversing what you already know is a 
less optimal route, or aren't reaching the intended destination at all.

Clay

Randy Jennings wrote:
> I thought that the Ethernet source address was included in the packet for 
> just this reason...  You can still run the packet through the regular 
> routing table lookup/ARP cache, just put the link address in your ARP cache 
> before you do so.  Are you saying that we should only do so for IP's on the 
> same network as us?  That makes partial sense to me.
> 
> Justin raised an important security concern, but if you are just going to 
> send out an ARP anyway, the same malicious person sending the packet would 
> just respond to the ARP also.
> 
> Sincerely,
> Randy Jennings
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eppo80$gsd$1@news.Stanford.EDU...
>> It's probably a better idea to treat all of the outgoing packets the same 
>> and run them through the routing table lookup- ARP cache - ARP request 
>> process rather than pull information from the link layer up in as inputs 
>> to the ICMP protocol.  While it's not really an issue in the specific 
>> topologies that you have for this assignment, it is certainly possible to 
>> have a temporary or permanent asymmetric route between two hosts.
>>
>> Clay
>>
>> Peter Pawlowski wrote:
>>> Hello--
>>>
>>> Is it safe to assume that if we recieve a packet from a certain host over 
>>> a certain interface, and that packet warrants an ICMP response (for 
>>> whatever reason), that is it safe to send that response over the 
>>> interface on which it was recieved via the router which send it to us? 
>>> Or, should we do a full route/ARP lookup for every outgoing case, 
>>> regardless of such insight (because perhaps routes are not always 
>>> transative)?
>>>
>>> Thanks!
>>> Peter
>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 16:29:55 -0800
Lines: 76
Distribution: su
Message-ID: <eprca6$7t7$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170289798 8103 127.0.0.1 (1 Feb 2007 00:29:58 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11338

On a similar note, is it ok to cache the MAC maddress of the sender when we 
receive an ARP request?

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:epr74p$3so$1@news.Stanford.EDU...
> In regards to the unsolicited ARP issue: a solicited ARP reply COULD 
> contain bad information, but since there's nothing in the ARP protocol 
> that calls for someone to send out unsolicited ARP replies if you receive 
> an unsolicited ARP reply, you already know something funny is going on.
>
> Regarding the routing issue- if you use the ethernet header to route 
> packets back rather than consulting the routing table, you can end up in a 
> situation where the router is ignoring the routing table- which may lead 
> to worse routes, or could just be a pain to diagnose.
>
> Consider this topology:
>
>  /B\
> A   D
>  \C/
>
> A's routing table says 'send packets to D via B'
> D's routing table says 'send packets to A via C'
>
> Now, if you ignore the routing table and just look at the ethernet header, 
> A is going to attempt to send packets to D via C rather than B. If the 
> links are directionally asymetric in some way- in terms of upload vs. 
> download speeds (think cable modems), filtering (host C may be configured 
> to block packets from reaching D), then you may end up in a situation 
> where your packets are traversing what you already know is a less optimal 
> route, or aren't reaching the intended destination at all.
>
> Clay
>
> Randy Jennings wrote:
>> I thought that the Ethernet source address was included in the packet for 
>> just this reason...  You can still run the packet through the regular 
>> routing table lookup/ARP cache, just put the link address in your ARP 
>> cache before you do so.  Are you saying that we should only do so for 
>> IP's on the same network as us?  That makes partial sense to me.
>>
>> Justin raised an important security concern, but if you are just going to 
>> send out an ARP anyway, the same malicious person sending the packet 
>> would just respond to the ARP also.
>>
>> Sincerely,
>> Randy Jennings
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:eppo80$gsd$1@news.Stanford.EDU...
>>> It's probably a better idea to treat all of the outgoing packets the 
>>> same and run them through the routing table lookup- ARP cache - ARP 
>>> request process rather than pull information from the link layer up in 
>>> as inputs to the ICMP protocol.  While it's not really an issue in the 
>>> specific topologies that you have for this assignment, it is certainly 
>>> possible to have a temporary or permanent asymmetric route between two 
>>> hosts.
>>>
>>> Clay
>>>
>>> Peter Pawlowski wrote:
>>>> Hello--
>>>>
>>>> Is it safe to assume that if we recieve a packet from a certain host 
>>>> over a certain interface, and that packet warrants an ICMP response 
>>>> (for whatever reason), that is it safe to send that response over the 
>>>> interface on which it was recieved via the router which send it to us? 
>>>> Or, should we do a full route/ARP lookup for every outgoing case, 
>>>> regardless of such insight (because perhaps routes are not always 
>>>> transative)?
>>>>
>>>> Thanks!
>>>> Peter
>>>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: How to link pthread
Date: Thu, 1 Feb 2007 02:01:29 +0000 (UTC)
Lines: 8
Distribution: su
Message-ID: <eprhlp$em9$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170295289 15049 171.64.15.42 (1 Feb 2007 02:01:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11339

Hi,

Make is returning undefined reference to pthread_create.

Can someone let me know how to link it.

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: How to link pthread
Date: Thu, 1 Feb 2007 02:07:08 +0000 (UTC)
Lines: 15
Distribution: su
Message-ID: <epri0c$evd$1@news.Stanford.EDU>
References: <eprhlp$em9$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170295628 15341 171.64.15.42 (1 Feb 2007 02:07:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11340

HI,

Figured this out...

Dinesh

Dinesh Gupta <dineshg@stanford.edu> wrote:
> Hi,

> Make is returning undefined reference to pthread_create.

> Can someone let me know how to link it.

> Thanks,
> Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: arp requests
Date: Thu, 1 Feb 2007 05:18:10 +0000 (UTC)
Lines: 8
Distribution: su
Message-ID: <eprt6i$pok$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170307090 26388 171.64.15.42 (1 Feb 2007 05:18:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11341

Hi,

Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
send one ARP req then wait then send another one, wait and so on, totalling 5-7
secs.

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 21:24:18 -0800
Lines: 83
Distribution: su
Message-ID: <eprtgl$qel$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170307413 27093 127.0.0.1 (1 Feb 2007 05:23:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11342

Sounds like no (although, I await answering my question about if the IP is 
in the same network).

"Riju Kallivalappil" <riju@stanford.edu> wrote in message 
news:eprca6$7t7$1@news.Stanford.EDU...
> On a similar note, is it ok to cache the MAC maddress of the sender when 
> we receive an ARP request?
>
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:epr74p$3so$1@news.Stanford.EDU...
>> In regards to the unsolicited ARP issue: a solicited ARP reply COULD 
>> contain bad information, but since there's nothing in the ARP protocol 
>> that calls for someone to send out unsolicited ARP replies if you receive 
>> an unsolicited ARP reply, you already know something funny is going on.
>>
>> Regarding the routing issue- if you use the ethernet header to route 
>> packets back rather than consulting the routing table, you can end up in 
>> a situation where the router is ignoring the routing table- which may 
>> lead to worse routes, or could just be a pain to diagnose.
>>
>> Consider this topology:
>>
>>  /B\
>> A   D
>>  \C/
>>
>> A's routing table says 'send packets to D via B'
>> D's routing table says 'send packets to A via C'
>>
>> Now, if you ignore the routing table and just look at the ethernet 
>> header, A is going to attempt to send packets to D via C rather than B. 
>> If the links are directionally asymetric in some way- in terms of upload 
>> vs. download speeds (think cable modems), filtering (host C may be 
>> configured to block packets from reaching D), then you may end up in a 
>> situation where your packets are traversing what you already know is a 
>> less optimal route, or aren't reaching the intended destination at all.
>>
>> Clay
>>
>> Randy Jennings wrote:
>>> I thought that the Ethernet source address was included in the packet 
>>> for just this reason...  You can still run the packet through the 
>>> regular routing table lookup/ARP cache, just put the link address in 
>>> your ARP cache before you do so.  Are you saying that we should only do 
>>> so for IP's on the same network as us?  That makes partial sense to me.
>>>
>>> Justin raised an important security concern, but if you are just going 
>>> to send out an ARP anyway, the same malicious person sending the packet 
>>> would just respond to the ARP also.
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>> news:eppo80$gsd$1@news.Stanford.EDU...
>>>> It's probably a better idea to treat all of the outgoing packets the 
>>>> same and run them through the routing table lookup- ARP cache - ARP 
>>>> request process rather than pull information from the link layer up in 
>>>> as inputs to the ICMP protocol.  While it's not really an issue in the 
>>>> specific topologies that you have for this assignment, it is certainly 
>>>> possible to have a temporary or permanent asymmetric route between two 
>>>> hosts.
>>>>
>>>> Clay
>>>>
>>>> Peter Pawlowski wrote:
>>>>> Hello--
>>>>>
>>>>> Is it safe to assume that if we recieve a packet from a certain host 
>>>>> over a certain interface, and that packet warrants an ICMP response 
>>>>> (for whatever reason), that is it safe to send that response over the 
>>>>> interface on which it was recieved via the router which send it to us? 
>>>>> Or, should we do a full route/ARP lookup for every outgoing case, 
>>>>> regardless of such insight (because perhaps routes are not always 
>>>>> transative)?
>>>>>
>>>>> Thanks!
>>>>> Peter
>>>>>
>>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 31 Jan 2007 21:24:35 -0800
Lines: 15
Distribution: su
Message-ID: <eprti8$qan$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170307464 26967 127.0.0.1 (1 Feb 2007 05:24:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eprt6i$pok$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11343

Dinesh Gupta wrote:
> Hi,
> 
> Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
> send one ARP req then wait then send another one, wait and so on, totalling 5-7
> secs.
> 
> Thanks,
> Dinesh

You should have sent 5 arp requests by the time you send the icmp host 
unreachable which should occur 5-7 seconds after the time you send the 
first request.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 21:27:49 -0800
Lines: 81
Distribution: su
Message-ID: <eprtn8$qlp$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170307624 27321 127.0.0.1 (1 Feb 2007 05:27:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11344

I can see what you are saying.  That is why I was wondering if it would be 
okay to stick it in your cache if you checked the IP prefix and saw it was 
in your same network (subnet) (as that should not go through a router)?

Also, I think my scheme would work regardless, as I check the route table 
before firing off the packet.  However, it could displace a useful entry... 
Not the best thing to do, but functionality is not impaired.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:epr74p$3so$1@news.Stanford.EDU...
>
> Regarding the routing issue- if you use the ethernet header to route 
> packets back rather than consulting the routing table, you can end up in a 
> situation where the router is ignoring the routing table- which may lead 
> to worse routes, or could just be a pain to diagnose.
>
> Consider this topology:
>
>  /B\
> A   D
>  \C/
>
> A's routing table says 'send packets to D via B'
> D's routing table says 'send packets to A via C'
>
> Now, if you ignore the routing table and just look at the ethernet header, 
> A is going to attempt to send packets to D via C rather than B. If the 
> links are directionally asymetric in some way- in terms of upload vs. 
> download speeds (think cable modems), filtering (host C may be configured 
> to block packets from reaching D), then you may end up in a situation 
> where your packets are traversing what you already know is a less optimal 
> route, or aren't reaching the intended destination at all.
>
> Clay
>
> Randy Jennings wrote:
>> I thought that the Ethernet source address was included in the packet for 
>> just this reason...  You can still run the packet through the regular 
>> routing table lookup/ARP cache, just put the link address in your ARP 
>> cache before you do so.  Are you saying that we should only do so for 
>> IP's on the same network as us?  That makes partial sense to me.
>>
>> Justin raised an important security concern, but if you are just going to 
>> send out an ARP anyway, the same malicious person sending the packet 
>> would just respond to the ARP also.
>>
>> Sincerely,
>> Randy Jennings
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:eppo80$gsd$1@news.Stanford.EDU...
>>> It's probably a better idea to treat all of the outgoing packets the 
>>> same and run them through the routing table lookup- ARP cache - ARP 
>>> request process rather than pull information from the link layer up in 
>>> as inputs to the ICMP protocol.  While it's not really an issue in the 
>>> specific topologies that you have for this assignment, it is certainly 
>>> possible to have a temporary or permanent asymmetric route between two 
>>> hosts.
>>>
>>> Clay
>>>
>>> Peter Pawlowski wrote:
>>>> Hello--
>>>>
>>>> Is it safe to assume that if we recieve a packet from a certain host 
>>>> over a certain interface, and that packet warrants an ICMP response 
>>>> (for whatever reason), that is it safe to send that response over the 
>>>> interface on which it was recieved via the router which send it to us? 
>>>> Or, should we do a full route/ARP lookup for every outgoing case, 
>>>> regardless of such insight (because perhaps routes are not always 
>>>> transative)?
>>>>
>>>> Thanks!
>>>> Peter
>>>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 31 Jan 2007 21:29:41 -0800
Lines: 20
Distribution: su
Message-ID: <eprtqo$qov$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170307736 27423 127.0.0.1 (1 Feb 2007 05:28:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11345

Considering that all the requests contain exactly the same information, why 
would you want to send them all at the same time?

Sincerely,
Randy Jennings

The squirrels are your friends!
"Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
news:eprt6i$pok$1@news.Stanford.EDU...
> Hi,
>
> Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
> send one ARP req then wait then send another one, wait and so on, 
> totalling 5-7
> secs.
>
> Thanks,
> Dinesh 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 21:30:59 -0800
Lines: 9
Distribution: su
Message-ID: <eprtu9$qan$2@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170307849 26967 127.0.0.1 (1 Feb 2007 05:30:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eprca6$7t7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11346

Riju Kallivalappil wrote:
> On a similar note, is it ok to cache the MAC maddress of the sender when we 
> receive an ARP request?

I would say no, when the destination then sends a packet back through 
your router towards the sender it should send out an arp request in that 
direction to find the next MAC of the next hop.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 21:41:31 -0800
Lines: 19
Distribution: su
Message-ID: <eprugu$rij$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU> <eprtu9$qan$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170308446 28243 127.0.0.1 (1 Feb 2007 05:40:46 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11347


"David Erickson" <derickso@stanford.edu> wrote in message 
news:eprtu9$qan$2@news.Stanford.EDU...
> Riju Kallivalappil wrote:
>> On a similar note, is it ok to cache the MAC maddress of the sender when 
>> we receive an ARP request?
>
> I would say no, when the destination then sends a packet back through your 
> router towards the sender it should send out an arp request in that 
> direction to find the next MAC of the next hop.
Wouldn't the ARP have the IP of the router, which would be on the same 
subnet as you?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 1 Feb 2007 05:43:09 +0000 (UTC)
Lines: 30
Distribution: su
Message-ID: <epruld$rbq$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprtqo$qov$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170308589 28026 171.64.15.42 (1 Feb 2007 05:43:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11348

Hi: Randy,

I thought we are sending multiple requests to make sure that host is
unreachable and it's not loss due to link. For sure all these packets
will contain the same data. Don't understand your point of view.

Thanks,
Dinesh

Randy Jennings <randyj@stanford.edu> wrote:
> Considering that all the requests contain exactly the same information, why 
> would you want to send them all at the same time?

> Sincerely,
> Randy Jennings

> The squirrels are your friends!
> "Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
> news:eprt6i$pok$1@news.Stanford.EDU...
> > Hi,
> >
> > Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
> > send one ARP req then wait then send another one, wait and so on, 
> > totalling 5-7
> > secs.
> >
> > Thanks,
> > Dinesh 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 31 Jan 2007 21:59:29 -0800
Lines: 34
Distribution: su
Message-ID: <eprvjr$sj9$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170309563 29289 128.12.194.72 (1 Feb 2007 05:59:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eprti8$qan$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11349

I only send ARP requests on an ARP cache miss, right?

Also, is it okay to simply drop the packet on the first time there is a 
cache miss for each IP address? (I'd then send an ARP request for the 
corresponding MAC address and hopefully have the cache entry for it the 
next time a packet arrives.)

Or do I always have to send up to five ARP requests, and forward the 
packet if I get a valid ARP reply, and only send host unreachable after 
I'm fairly sure that the link is down? If this is the case, I'm not sure 
how to structure my code, since there is no way to receive another 
packet inside the handle_packet code.

-Yangfan

David Erickson wrote:
> Dinesh Gupta wrote:
> 
>> Hi,
>>
>> Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
>> send one ARP req then wait then send another one, wait and so on, 
>> totalling 5-7
>> secs.
>>
>> Thanks,
>> Dinesh
> 
> 
> You should have sent 5 arp requests by the time you send the icmp host 
> unreachable which should occur 5-7 seconds after the time you send the 
> first request.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Wed, 31 Jan 2007 22:14:03 -0800
Lines: 20
Distribution: su
Message-ID: <eps0fa$6e$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU> <eprtu9$qan$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170310442 206 127.0.0.1 (1 Feb 2007 06:14:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <eprtu9$qan$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11350

David Erickson wrote:
> Riju Kallivalappil wrote:
>> On a similar note, is it ok to cache the MAC maddress of the sender 
>> when we receive an ARP request?
> 
> I would say no, when the destination then sends a packet back through 
> your router towards the sender it should send out an arp request in that 
> direction to find the next MAC of the next hop.
> 
> -David

I think the rfc for arp linked from the homework (rfc 826) says different:

"Notice that the <protocol type, sender protocol address, sender
hardware address> triplet is merged into the table before the
opcode is looked at.  This is on the assumption that communcation
is bidirectional; if A has some reason to talk to B, then B will
probably have some reason to talk to A."

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Questions on computing checksum.
Date: Wed, 31 Jan 2007 22:27:51 -0800
Lines: 14
Distribution: su
Message-ID: <eps190$rq$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170311265 890 128.12.194.72 (1 Feb 2007 06:27:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11351

Okay, a few questions on computing checksum, since I'm not doing them 
correctly... :p

1. An IP checksum computes the sum over the IP header only, but an ICMP 
checksum computes it over both the ICMP header and its entire body (the 
rest of the IP packet's data portion), right?

2. Does the cheskum algorithm treat 8-bit fields differently? For 
example, if it sees two consecutive 8-bit fields, will it add them to 
the sum separately or as one 16-bit field?

Thanks.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ARP cache per interface?
Date: Wed, 31 Jan 2007 22:40:53 -0800
Lines: 5
Distribution: su
Message-ID: <eps21l$1bm$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170312054 1398 128.12.104.61 (1 Feb 2007 06:40:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11352

Not that it matters, but in an actual router is there typically an arp 
cache for each interface or just a single cache for all interfaces?

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP cache per interface?
Date: Thu, 01 Feb 2007 00:58:11 -0800
Lines: 36
Distribution: su
Message-ID: <C1E6EBA3.7EC1%jpettit@stanford.edu>
References: <eps21l$1bm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170320295 13968 127.0.0.1 (1 Feb 2007 08:58:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ARP cache per interface?
Thread-Index: AcdF3xltV8lkWrHSEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11353

On most systems, you can run "arp -a" to dump out the arp cache:

[jpettit@myth4 ~] arp -a
afssvr22.Stanford.EDU (171.64.17.22) at 00:D0:05:5D:27:FC [ether] on eth0
caribou.Stanford.EDU (171.64.7.55) at 00:D0:05:5D:27:FC [ether] on eth0
cicci.Stanford.EDU (171.64.7.121) at 00:D0:05:5D:27:FC [ether] on eth0
myth2.Stanford.EDU (171.64.15.175) at 00:0F:1F:92:B3:56 [ether] on eth0
myth3.Stanford.EDU (171.64.15.178) at 00:0F:1F:84:7B:94 [ether] on eth0
....

So, it looks like its tied to a particular interface.  Also, notice that the
MAC address is the same for most of these IP addresses, with the sole
exception of two Myth systems.  The reason is that the non-Myth systems need
to go through a router, which is providing its MAC address (the one that
ends in 27:FC).  While the Myth systems are supplying their own actual
hardware addresses.

You can find a lot of interesting information on these Linux systems.
Here's a couple of other ones that might be useful for this assignment:

    ifconfig -a          # Print information about the interfaces
    netstat -rn         # Print the routing table

--Justin


On 1/31/07 10:40 PM, in article eps21l$1bm$1@news.Stanford.EDU, "Matt Page"
<mpage@stanford.edu> wrote:

> Not that it matters, but in an actual router is there typically an arp
> cache for each interface or just a single cache for all interfaces?
> 
> Thanks,
> Matt


.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Default Route...
Date: Thu, 01 Feb 2007 00:59:58 -0800
Lines: 5
Distribution: su
Message-ID: <epsa6g$dms$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170320400 14044 128.12.104.61 (1 Feb 2007 09:00:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11354

Given the presence of a default route, how can we determine if a packet 
has an unknown next hop address?

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 01 Feb 2007 01:21:20 -0800
Lines: 17
Distribution: su
Message-ID: <C1E6F110.7EC6%jpettit@stanford.edu>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU> <eprvjr$sj9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170321686 15649 127.0.0.1 (1 Feb 2007 09:21:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp requests
Thread-Index: AcdF4lVWlAlvPrHVEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11355

> I only send ARP requests on an ARP cache miss, right?

Correct.

> Also, is it okay to simply drop the packet on the first time there is a
> cache miss for each IP address? (I'd then send an ARP request for the
> corresponding MAC address and hopefully have the cache entry for it the
> next time a packet arrives.)

That wouldn't be very nice to the poor source that took the time to generate
the packet.  No, you must hold onto the packet until you decide what to do
with it.  If you don't get an ARP reply, you'll use the IP header and first
64-bytes of data into unreachable message.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 01 Feb 2007 01:28:07 -0800
Lines: 41
Distribution: su
Message-ID: <C1E6F2A7.7EC7%jpettit@stanford.edu>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprtqo$qov$1@news.Stanford.EDU> <epruld$rbq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170322091 16000 127.0.0.1 (1 Feb 2007 09:28:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp requests
Thread-Index: AcdF40fthsS+uLHWEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11356

Just send one ARP request at a time spaced out by (approximately) a second
until you hear a response or you've sent five of them.

--Justin


On 1/31/07 9:43 PM, in article epruld$rbq$1@news.Stanford.EDU, "Dinesh
Gupta" <dineshg@Stanford.EDU> wrote:

> Hi: Randy,
> 
> I thought we are sending multiple requests to make sure that host is
> unreachable and it's not loss due to link. For sure all these packets
> will contain the same data. Don't understand your point of view.
> 
> Thanks,
> Dinesh
> 
> Randy Jennings <randyj@stanford.edu> wrote:
>> Considering that all the requests contain exactly the same information, why
>> would you want to send them all at the same time?
> 
>> Sincerely,
>> Randy Jennings
> 
>> The squirrels are your friends!
>> "Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message
>> news:eprt6i$pok$1@news.Stanford.EDU...
>>> Hi,
>>> 
>>> Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
>>> send one ARP req then wait then send another one, wait and so on,
>>> totalling 5-7
>>> secs.
>>> 
>>> Thanks,
>>> Dinesh 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Spawning new threads.
Date: Thu, 01 Feb 2007 02:00:31 -0800
Lines: 19
Distribution: su
Message-ID: <epsdno$hde$1@news.Stanford.EDU>
References: <epp5qm$15$1@news.Stanford.EDU> <epp8qt$1u5$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170324025 17838 128.12.194.72 (1 Feb 2007 10:00:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epp8qt$1u5$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11357

Where are the pthread man pages? For example, pthread_mutex_lock looks 
interesting, but calling man on it doesn't work. "man pthreads" refers 
to Pthreads manual pages.

- Yangfan

Clay Collier wrote:
> 'man pthreads' is a good place to start.
> 
> Clay
> Yangfan Wang wrote:
> 
>> Where can I find a good resource on learning how to spawn new threads 
>> in  Unix?
>>
>> We learned the theory in CS140, but a quick review and some practical 
>> details on threads in Unix would be very helpful.
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Thu, 01 Feb 2007 03:45:31 -0800
Lines: 18
Distribution: su
Message-ID: <epsjsr$mpg$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170330331 23344 127.0.0.1 (1 Feb 2007 11:45:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eps190$rq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11358

Yangfan Wang wrote:
> Okay, a few questions on computing checksum, since I'm not doing them 
> correctly... :p
> 
> 1. An IP checksum computes the sum over the IP header only, but an ICMP 
> checksum computes it over both the ICMP header and its entire body (the 
> rest of the IP packet's data portion), right?

The ICMP checksum is over the ICMP header information and the ICMP 
packet's body, however be careful what you put in the ICMP packet's body.

> 2. Does the cheskum algorithm treat 8-bit fields differently? For 
> example, if it sees two consecutive 8-bit fields, will it add them to 
> the sum separately or as one 16-bit field?

It treats them as a single 16 bit field.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Spawning new threads.
Date: Thu, 01 Feb 2007 09:40:08 -0800
Lines: 35
Distribution: su
Message-ID: <C1E765F8.7EDA%jpettit@stanford.edu>
References: <epp5qm$15$1@news.Stanford.EDU> <epp8qt$1u5$1@news.Stanford.EDU> <epsdno$hde$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170351613 12625 127.0.0.1 (1 Feb 2007 17:40:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Spawning new threads.
Thread-Index: AcdGKAPQQqq6KLIbEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11359

I'm not sure why they're not found on our Linux systems.  There are some
Linux online man pages that cover the material, such as:

    http://www.die.net/doc/linux/man/man3/pthread_mutex_lock.3.html

The Elaines have them, but they are Solaris, so there may be some subtle
differences.

--Justin


On 2/1/07 2:00 AM, in article epsdno$hde$1@news.Stanford.EDU, "Yangfan Wang"
<yfw@stanford.edu> wrote:

> Where are the pthread man pages? For example, pthread_mutex_lock looks
> interesting, but calling man on it doesn't work. "man pthreads" refers
> to Pthreads manual pages.
> 
> - Yangfan
> 
> Clay Collier wrote:
>> 'man pthreads' is a good place to start.
>> 
>> Clay
>> Yangfan Wang wrote:
>> 
>>> Where can I find a good resource on learning how to spawn new threads
>>> in  Unix?
>>> 
>>> We learned the theory in CS140, but a quick review and some practical
>>> details on threads in Unix would be very helpful.
>>> 
>>> -Yangfan


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 01 Feb 2007 09:46:16 -0800
Lines: 24
Distribution: su
Message-ID: <ept914$cd7$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU> <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170351972 12711 127.0.0.1 (1 Feb 2007 17:46:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1E6F110.7EC6%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11360

Jut a clarification... Is it not the first 8 bytes i.e. the first 64 
bits of the data in the IP datagram that must be sent back in the 
unreachable message?

Neelima

Justin Pettit wrote:
>> I only send ARP requests on an ARP cache miss, right?
> 
> Correct.
> 
>> Also, is it okay to simply drop the packet on the first time there is a
>> cache miss for each IP address? (I'd then send an ARP request for the
>> corresponding MAC address and hopefully have the cache entry for it the
>> next time a packet arrives.)
> 
> That wouldn't be very nice to the poor source that took the time to generate
> the packet.  No, you must hold onto the packet until you decide what to do
> with it.  If you don't get an ARP reply, you'll use the IP header and first
> 64-bytes of data into unreachable message.
> 
> --Justin
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Default Route...
Date: Thu, 01 Feb 2007 09:46:22 -0800
Lines: 18
Distribution: su
Message-ID: <C1E7676E.7EDE%jpettit@stanford.edu>
References: <epsa6g$dms$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170351984 12878 127.0.0.1 (1 Feb 2007 17:46:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Default Route...
Thread-Index: AcdGKOK8ITyez7IcEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11361

The only case I can think of is when the packet's destination is in the
router's collision domain, but it couldn't determine the destination's
hardware address.  This could happen because no machine has that IP address
or the one that does is down.

--Justin


On 2/1/07 12:59 AM, in article epsa6g$dms$1@news.Stanford.EDU, "Matt Page"
<mpage@stanford.edu> wrote:

> Given the presence of a default route, how can we determine if a packet
> has an unknown next hop address?
> 
> Thanks,
> Matt


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 01 Feb 2007 09:48:34 -0800
Lines: 35
Distribution: su
Message-ID: <C1E767F2.7EE1%jpettit@stanford.edu>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU> <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu> <ept914$cd7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170352118 12939 127.0.0.1 (1 Feb 2007 17:48:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp requests
Thread-Index: AcdGKTFqcCjSLLIcEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11362

Whoops, you are correct!  I need to be more careful when I'm replying late
at night.  Thanks for catching that!

--Justin


On 2/1/07 9:46 AM, in article ept914$cd7$1@news.Stanford.EDU, "Neelima
Balakrishnan" <bneelima@stanford.edu> wrote:

> Jut a clarification... Is it not the first 8 bytes i.e. the first 64
> bits of the data in the IP datagram that must be sent back in the
> unreachable message?
> 
> Neelima
> 
> Justin Pettit wrote:
>>> I only send ARP requests on an ARP cache miss, right?
>> 
>> Correct.
>> 
>>> Also, is it okay to simply drop the packet on the first time there is a
>>> cache miss for each IP address? (I'd then send an ARP request for the
>>> corresponding MAC address and hopefully have the cache entry for it the
>>> next time a packet arrives.)
>> 
>> That wouldn't be very nice to the poor source that took the time to generate
>> the packet.  No, you must hold onto the packet until you decide what to do
>> with it.  If you don't get an ARP reply, you'll use the IP header and first
>> 64-bytes of data into unreachable message.
>> 
>> --Justin
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS1 Scores
Date: Thu, 01 Feb 2007 09:58:50 -0800
Lines: 14
Distribution: su
Message-ID: <C1E76A5A.7EE6%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170352730 13407 127.0.0.1 (1 Feb 2007 17:58:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS1 Scores
Thread-Index: AcdGKqCU3uYeVbIdEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11363

The first problem set was returned on Tuesday and the scores have been
entered into eeclass.  The score average was 53.42 with a standard deviation
of 9.47.  The highest score was 68 out of 69 possible points.

If you were not in class on Tuesday, they have been placed into the CS244A
filing cabinet on the third floor.  The SCPD submissions that had a routing
form have been sent back to SCPD, so you should receive them in the next
couple of days.

We are in the process of generating a solution set and should have that up
in the next day or two.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PA2 due date
Date: Thu, 1 Feb 2007 19:15:04 +0000 (UTC)
Lines: 6
Distribution: su
Message-ID: <epte7o$gls$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170357304 17084 171.64.15.42 (1 Feb 2007 19:15:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11364

Hi,

PA2 due date is this Friday or next Friday?

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Thu, 1 Feb 2007 19:21:40 +0000 (UTC)
Lines: 44
Distribution: su
Message-ID: <eptek4$h12$1@news.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprtqo$qov$1@news.Stanford.EDU> <epruld$rbq$1@news.Stanford.EDU> <C1E6F2A7.7EC7%jpettit@stanford.edu>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170357700 17442 171.64.15.42 (1 Feb 2007 19:21:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11365

Thanks for clarifying this!

Justin Pettit <jpettit@stanford.edu> wrote:
> Just send one ARP request at a time spaced out by (approximately) a second
> until you hear a response or you've sent five of them.

> --Justin


> On 1/31/07 9:43 PM, in article epruld$rbq$1@news.Stanford.EDU, "Dinesh
> Gupta" <dineshg@Stanford.EDU> wrote:

> > Hi: Randy,
> > 
> > I thought we are sending multiple requests to make sure that host is
> > unreachable and it's not loss due to link. For sure all these packets
> > will contain the same data. Don't understand your point of view.
> > 
> > Thanks,
> > Dinesh
> > 
> > Randy Jennings <randyj@stanford.edu> wrote:
> >> Considering that all the requests contain exactly the same information, why
> >> would you want to send them all at the same time?
> > 
> >> Sincerely,
> >> Randy Jennings
> > 
> >> The squirrels are your friends!
> >> "Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message
> >> news:eprt6i$pok$1@news.Stanford.EDU...
> >>> Hi,
> >>> 
> >>> Do we need to send 5 continous ARP requests and wait for 5-7 seconds or
> >>> send one ARP req then wait then send another one, wait and so on,
> >>> totalling 5-7
> >>> secs.
> >>> 
> >>> Thanks,
> >>> Dinesh 
> > 
> > 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2 due date
Date: Thu, 01 Feb 2007 13:46:44 -0800
Lines: 18
Distribution: su
Message-ID: <C1E79FC4.7F02%jpettit@stanford.edu>
References: <epte7o$gls$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170366406 26081 127.0.0.1 (1 Feb 2007 21:46:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA2 due date
Thread-Index: AcdGSnbrtUHnzLI9EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11366

Next Friday.  The programming assignment due dates are in the second to last
column of the following page:

    http://www.stanford.edu/class/cs244a/timetable.html

--Justin

On 2/1/07 11:15 AM, in article epte7o$gls$1@news.Stanford.EDU, "Dinesh
Gupta" <dineshg@Stanford.EDU> wrote:

> Hi,
> 
> PA2 due date is this Friday or next Friday?
> 
> Thanks,
> Dinesh


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Doubt regarding ICMP error messages
Date: Thu, 01 Feb 2007 18:42:28 -0800
Lines: 24
Distribution: su
Message-ID: <epu8eh$fe9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170384145 15817 127.0.0.1 (2 Feb 2007 02:42:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11367

Hi,

I had a question about handling ICMP timeout and port unreachable messages.

When we receive an IP packet, should we not do the sanity checks on it 
first(including TTL expired) before decoding and checking the protocol 
type of the data it is carrying?

In that case if we get a TCP/UDP packet addressed to one of the router 
interface with TTL = 1 before decrementing, what should the ICMP error 
message sent back be? (timeout or port unreachable?) If we send out ICMP 
timeout error message, then in traceroute the display might indicate 
"!A" annotation indicating that it got a Timeout message instead of Port 
Unreachable message.

This happens because the TTL is 1 by the time the packet reaches us and 
as per the FAQ, if the TTL is 1 or 0 before decrementing, then a ICMP 
timeout error message should be sent out.

So the question is - What should be the correct/expected behavior in 
this scenario?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: arp cache timeouts
Date: Thu, 01 Feb 2007 20:22:37 -0800
Lines: 5
Distribution: su
Message-ID: <epue7e$kfu$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170390062 20990 128.12.134.140 (2 Feb 2007 04:21:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11368

If the ip/mac combo is being used (for example to reply to pings) should
we reset the timeout timer on the arp cache entry for that combo?

Thanks,
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA2 grading script
Date: Thu, 01 Feb 2007 20:23:04 -0800
Lines: 4
Distribution: su
Message-ID: <epue89$kfu$2@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170390089 20990 128.12.134.140 (2 Feb 2007 04:21:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11369

Is it available somewhere?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Doubt regarding ICMP error messages
Date: Thu, 1 Feb 2007 20:46:50 -0800
Lines: 35
Distribution: su
Message-ID: <epufmc$lmt$1@news.Stanford.EDU>
References: <epu8eh$fe9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170391564 22237 127.0.0.1 (2 Feb 2007 04:46:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11370

An earlier post indicated that if the message was addressed to one of our 
interfaces, we should not check the ICMP.

Sincerely,
Randy Jennings

"Neelima Balakrishnan" <bneelima@stanford.edu> wrote in message 
news:epu8eh$fe9$1@news.Stanford.EDU...
> Hi,
>
> I had a question about handling ICMP timeout and port unreachable 
> messages.
>
> When we receive an IP packet, should we not do the sanity checks on it 
> first(including TTL expired) before decoding and checking the protocol 
> type of the data it is carrying?
>
> In that case if we get a TCP/UDP packet addressed to one of the router 
> interface with TTL = 1 before decrementing, what should the ICMP error 
> message sent back be? (timeout or port unreachable?) If we send out ICMP 
> timeout error message, then in traceroute the display might indicate "!A" 
> annotation indicating that it got a Timeout message instead of Port 
> Unreachable message.
>
> This happens because the TTL is 1 by the time the packet reaches us and as 
> per the FAQ, if the TTL is 1 or 0 before decrementing, then a ICMP timeout 
> error message should be sent out.
>
> So the question is - What should be the correct/expected behavior in this 
> scenario?
>
> Thanks
> Neelima 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Doubt regarding ICMP error messages
Date: Thu, 01 Feb 2007 20:53:30 -0800
Lines: 43
Distribution: su
Message-ID: <epug45$lu0$1@news.Stanford.EDU>
References: <epu8eh$fe9$1@news.Stanford.EDU> <epufmc$lmt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170392005 22464 127.0.0.1 (2 Feb 2007 04:53:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <epufmc$lmt$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11371

Maybe I did not phrase my doubts properly.

What I was asking was if we get a TCP/UDP packet in an IP datagram with 
TTL = 1 addressed to the IP of one of the router interfaces, what should 
be the ICMP error message sent back - Timeout or Port Unreachable?

Neelima
Randy Jennings wrote:
> An earlier post indicated that if the message was addressed to one of our 
> interfaces, we should not check the ICMP.
> 
> Sincerely,
> Randy Jennings
> 
> "Neelima Balakrishnan" <bneelima@stanford.edu> wrote in message 
> news:epu8eh$fe9$1@news.Stanford.EDU...
>> Hi,
>>
>> I had a question about handling ICMP timeout and port unreachable 
>> messages.
>>
>> When we receive an IP packet, should we not do the sanity checks on it 
>> first(including TTL expired) before decoding and checking the protocol 
>> type of the data it is carrying?
>>
>> In that case if we get a TCP/UDP packet addressed to one of the router 
>> interface with TTL = 1 before decrementing, what should the ICMP error 
>> message sent back be? (timeout or port unreachable?) If we send out ICMP 
>> timeout error message, then in traceroute the display might indicate "!A" 
>> annotation indicating that it got a Timeout message instead of Port 
>> Unreachable message.
>>
>> This happens because the TTL is 1 by the time the packet reaches us and as 
>> per the FAQ, if the TTL is 1 or 0 before decrementing, then a ICMP timeout 
>> error message should be sent out.
>>
>> So the question is - What should be the correct/expected behavior in this 
>> scenario?
>>
>> Thanks
>> Neelima 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Routing of reply packets
Date: Thu, 1 Feb 2007 23:14:32 -0800
Lines: 167
Distribution: su
Message-ID: <epuocq$se3$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170400474 29123 127.0.0.1 (2 Feb 2007 07:14:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11372

When I connect to one of the application servers in my topology through my 
router, are the packets returned by the application server routed through a 
different path? I don't see any of the packets from the application servers 
going through my code. But, I can access the website on the application 
server without a problem.

The tcpdump output is given below


reading from file tcpdump.pcap, link-type EN10MB (Ethernet)
22:51:22.320859 00:e0:81:04:26:d9 (oui Unknown) > Broadcast, ethertype ARP 
(0x0806), length 60: arp who-has aradia-router-3.Stanford.EDU tell 
vns-firewall.Stanford.EDU
        0x0000:  0001 0800 0604 0001 00e0 8104 26d9 ac18
        0x0010:  4a11 0000 0000 0000 c0a8 813a 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000
22:51:22.320994 70:00:00:d8:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui 
Unknown), ethertype ARP (0x0806), length 42: arp reply 
aradia-router-3.Stanford.EDU is-at 70:00:00:d8:00:01 (oui Unknown)
        0x0000:  0001 0800 0604 0002 7000 00d8 0001 c0a8
        0x0010:  813a 00e0 8104 26d9 ac18 4a11
22:51:22.322648 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29414, 
offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: S, cksum 0x586e (correct), 
3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280412369 
0,nop,wscale 2>
        0x0000:  4510 003c 72e6 4000 3c06 cea7 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
        0x0020:  a002 16d0 586e 0000 0204 05b4 0402 080a
        0x0030:  ff21 e8d1 0000 0000 0103 0302
22:51:22.322699 70:00:00:d8:00:06 (oui Unknown) > Broadcast, ethertype ARP 
(0x0806), length 42: arp who-has aseems-router-3.Stanford.EDU tell 
ftp-arethusa.Stanford.EDU
        0x0000:  0001 0800 0604 0001 7000 00d8 0006 c0a8
        0x0010:  813d 0000 0000 0000 c0a8 813e
22:51:22.324343 00:04:75:7b:e9:22 (oui Unknown) > 70:00:00:d8:00:06 (oui 
Unknown), ethertype ARP (0x0806), length 60: arp reply 
aseems-router-3.Stanford.EDU is-at 00:04:75:7b:e9:22 (oui Unknown)
        0x0000:  0001 0800 0604 0002 0004 757b e922 c0a8
        0x0010:  813e 7000 00d8 0006 c0a8 813d 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000
22:51:22.324376 70:00:00:d8:00:06 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 74: IP3 truncated-ip - 62267 bytes 
missing! (tos 0x59,ECT(1), id 14425, offset 39864, flags [+, DF, rsvd], 
proto: Options (0), length: 62327, options ( EOL (0) len 1 ), bad cksum 20 
(->3783)!) 112.0.0.216 > 0.2.0.0: ip
        0x0000:  3859 f377 3859 f377 0000 0020 7000 00d8
        0x0010:  0002 0000 0000 0000 0000 0000 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0040
        0x0030:  c0a8 813b 0000 0000 0000 0000
22:51:25.314742 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29415, 
offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct), 
3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119 
0,nop,wscale 2>
        0x0000:  4510 003c 72e7 4000 3c06 cea6 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
        0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
        0x0030:  ff21 ebbf 0000 0000 0103 0302
22:51:25.314881 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  59, id 29415, 
offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct), 
3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119 
0,nop,wscale 2>
        0x0000:  4510 003c 72e7 4000 3b06 cfa6 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
        0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
        0x0030:  ff21 ebbf 0000 0000 0103 0302
22:51:25.317031 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29416, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct), 
3079051832:3079051832(0) ack 64737525 win 1460 <nop,nop,timestamp 4280413119 
789674283>
        0x0000:  4510 0034 72e8 4000 3c06 cead ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
        0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
        0x0030:  2f11 792b
22:51:25.317105 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29416, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct), 0:0(0) ack 1 
win 1460 <nop,nop,timestamp 4280413119 789674283>
        0x0000:  4510 0034 72e8 4000 3b06 cfad ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
        0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
        0x0030:  2f11 792b
22:51:30.998908 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  60, id 29417, 
offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack 
1 win 1460 <nop,nop,timestamp 4280414540 789674283>
        0x0000:  4510 0044 72e9 4000 3c06 ce9c ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
        0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
        0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
        0x0040:  2e30 0d0a
22:51:30.999020 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  59, id 29417, 
offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack 
1 win 1460 <nop,nop,timestamp 4280414540 789674283>
        0x0000:  4510 0044 72e9 4000 3b06 cf9c ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
        0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
        0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
        0x0040:  2e30 0d0a
22:51:31.980478 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  60, id 29418, 
offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack 
1 win 1460 <nop,nop,timestamp 4280414785 789674851>
        0x0000:  4510 0036 72ea 4000 3c06 cea9 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
        0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
        0x0030:  2f11 7b63 0d0a
22:51:31.980600 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  59, id 29418, 
offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack 
1 win 1460 <nop,nop,timestamp 4280414785 789674851>
        0x0000:  4510 0036 72ea 4000 3b06 cfa9 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
        0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
        0x0030:  2f11 7b63 0d0a
22:51:31.983665 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29419, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack 
633 win 1776 <nop,nop,timestamp 4280414786 789674950>
        0x0000:  4510 0034 72eb 4000 3c06 ceaa ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
        0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
        0x0030:  2f11 7bc6
22:51:31.983724 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29419, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack 
633 win 1776 <nop,nop,timestamp 4280414786 789674950>
        0x0000:  4510 0034 72eb 4000 3b06 cfaa ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
        0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
        0x0030:  2f11 7bc6
22:51:31.985257 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29420, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack 
634 win 1776 <nop,nop,timestamp 4280414786 789674950>
        0x0000:  4510 0034 72ec 4000 3c06 cea9 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
        0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
        0x0030:  2f11 7bc6
22:51:31.985292 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui 
Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29420, 
offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382 
 > aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack 
634 win 1776 <nop,nop,timestamp 4280414786 789674950>
        0x0000:  4510 0034 72ec 4000 3b06 cfa9 ab40 0ff7
        0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
        0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
        0x0030:  2f11 7bc6



.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2 grading script
Date: Thu, 01 Feb 2007 23:33:16 -0800
Lines: 16
Distribution: su
Message-ID: <C1E8293C.8071%jpettit@stanford.edu>
References: <epue89$kfu$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170401600 94 127.0.0.1 (2 Feb 2007 07:33:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA2 grading script
Thread-Index: AcdGnGb8pWYdJbKPEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11373

Unfortunately, there aren't any from here on out.  All I can recommend is
that you are very careful about meeting all of the bullet points in
"Required Functionality".

--Justin


On 2/1/07 8:23 PM, in article epue89$kfu$2@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> Is it available somewhere?
> 
> Thanks,
> Jad.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Thu, 01 Feb 2007 23:40:06 -0800
Lines: 45
Distribution: su
Message-ID: <C1E82AD6.8072%jpettit@stanford.edu>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU> <eprtu9$qan$2@news.Stanford.EDU> <eps0fa$6e$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170402011 460 127.0.0.1 (2 Feb 2007 07:40:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ICMP reply assumption
Thread-Index: AcdGnVtdmiKMorKQEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11374

Personally, I think the RFC's advice is poor due to security concerns and
possible problems with asynchronous routes.  This RFC was written in the
early 1980's and security is a fairly recent concern for the IETF (the
organization that produces RFCs).  A lot of older RFCs (and even fairly
modern ones) have horrendous security problems.

With all of that said, you can feel free to accept unsolicited ARP replies
(it seems most operating systems do) and cache the source MAC addresses of
ARP requests.  It will just make me sad inside when I grade it.  ;)

If you are interested, here's an article discussing some of the security
implications:

    http://shsc.info/ARPPoisoning

This is purely optional reading; we won't test you on it.

--Justin


On 1/31/07 10:14 PM, in article eps0fa$6e$1@news.Stanford.EDU, "Greg Nelson"
<grourk@stanford.edu> wrote:

> David Erickson wrote:
>> Riju Kallivalappil wrote:
>>> On a similar note, is it ok to cache the MAC maddress of the sender
>>> when we receive an ARP request?
>> 
>> I would say no, when the destination then sends a packet back through
>> your router towards the sender it should send out an arp request in that
>> direction to find the next MAC of the next hop.
>> 
>> -David
> 
> I think the rfc for arp linked from the homework (rfc 826) says different:
> 
> "Notice that the <protocol type, sender protocol address, sender
> hardware address> triplet is merged into the table before the
> opcode is looked at.  This is on the assumption that communcation
> is bidirectional; if A has some reason to talk to B, then B will
> probably have some reason to talk to A."
> 
> Greg


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Doubt regarding ICMP error messages
Date: Thu, 01 Feb 2007 23:46:17 -0800
Lines: 55
Distribution: su
Message-ID: <C1E82C49.8074%jpettit@stanford.edu>
References: <epu8eh$fe9$1@news.Stanford.EDU> <epufmc$lmt$1@news.Stanford.EDU> <epug45$lu0$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170402390 1266 127.0.0.1 (2 Feb 2007 07:46:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Doubt regarding ICMP error messages
Thread-Index: AcdGnjh/dvn87rKREduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11375

As was mentioned in question 28 of the FAQ, you should accept it.  I take
this to mean that you should generate an ICMP port unreachable message in
this circumstance.

--Justin


On 2/1/07 8:53 PM, in article epug45$lu0$1@news.Stanford.EDU, "Neelima
Balakrishnan" <bneelima@stanford.edu> wrote:

> Maybe I did not phrase my doubts properly.
> 
> What I was asking was if we get a TCP/UDP packet in an IP datagram with
> TTL = 1 addressed to the IP of one of the router interfaces, what should
> be the ICMP error message sent back - Timeout or Port Unreachable?
> 
> Neelima
> Randy Jennings wrote:
>> An earlier post indicated that if the message was addressed to one of our
>> interfaces, we should not check the ICMP.
>> 
>> Sincerely,
>> Randy Jennings
>> 
>> "Neelima Balakrishnan" <bneelima@stanford.edu> wrote in message
>> news:epu8eh$fe9$1@news.Stanford.EDU...
>>> Hi,
>>> 
>>> I had a question about handling ICMP timeout and port unreachable
>>> messages.
>>> 
>>> When we receive an IP packet, should we not do the sanity checks on it
>>> first(including TTL expired) before decoding and checking the protocol
>>> type of the data it is carrying?
>>> 
>>> In that case if we get a TCP/UDP packet addressed to one of the router
>>> interface with TTL = 1 before decrementing, what should the ICMP error
>>> message sent back be? (timeout or port unreachable?) If we send out ICMP
>>> timeout error message, then in traceroute the display might indicate "!A"
>>> annotation indicating that it got a Timeout message instead of Port
>>> Unreachable message.
>>> 
>>> This happens because the TTL is 1 by the time the packet reaches us and as
>>> per the FAQ, if the TTL is 1 or 0 before decrementing, then a ICMP timeout
>>> error message should be sent out.
>>> 
>>> So the question is - What should be the correct/expected behavior in this
>>> scenario?
>>> 
>>> Thanks
>>> Neelima 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp cache timeouts
Date: Fri, 02 Feb 2007 00:16:58 -0800
Lines: 16
Distribution: su
Message-ID: <C1E8337A.8077%jpettit@stanford.edu>
References: <epue7e$kfu$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170404224 6819 127.0.0.1 (2 Feb 2007 08:17:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp cache timeouts
Thread-Index: AcdGooHRwKmR1rKVEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11376

You can renew the timeout timer in that circumstance if you like.  We won't
ding you for either way.

--Justin


On 2/1/07 8:22 PM, in article epue7e$kfu$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> If the ip/mac combo is being used (for example to reply to pings) should
> we reset the timeout timer on the arp cache entry for that combo?
> 
> Thanks,
> Jad


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 02:07:40 -0800
Lines: 14
Distribution: su
Message-ID: <epv2h4$bk7$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170410852 11911 128.12.194.72 (2 Feb 2007 10:07:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epsjsr$mpg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11377

>> 1. An IP checksum computes the sum over the IP header only, but an 
>> ICMP checksum computes it over both the ICMP header and its entire 
>> body (the rest of the IP packet's data portion), right?
> 
> 
> The ICMP checksum is over the ICMP header information and the ICMP 
> packet's body, however be careful what you put in the ICMP packet's body.
> 

For the ICMP packet's body, we include both the IP header of the packet 
that caused the ICMP in the first place, plus 8 byte = 64 bits of the 
offending packet's body, right?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 02:14:39 -0800
Lines: 27
Distribution: su
Message-ID: <epv2u7$bs9$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170411271 12169 128.12.194.72 (2 Feb 2007 10:14:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epsjsr$mpg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11378

Also, the checksum is computed and verified *before* the TTL is 
decremented, right?

-Yangfan

David Erickson wrote:
> Yangfan Wang wrote:
> 
>> Okay, a few questions on computing checksum, since I'm not doing them 
>> correctly... :p
>>
>> 1. An IP checksum computes the sum over the IP header only, but an 
>> ICMP checksum computes it over both the ICMP header and its entire 
>> body (the rest of the IP packet's data portion), right?
> 
> 
> The ICMP checksum is over the ICMP header information and the ICMP 
> packet's body, however be careful what you put in the ICMP packet's body.
> 
>> 2. Does the cheskum algorithm treat 8-bit fields differently? For 
>> example, if it sees two consecutive 8-bit fields, will it add them to 
>> the sum separately or as one 16-bit field?
> 
> 
> It treats them as a single 16 bit field.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 02:26:57 -0800
Lines: 41
Distribution: su
Message-ID: <epv3l8$c7q$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU> <epv2u7$bs9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170412008 12538 128.12.194.72 (2 Feb 2007 10:26:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epv2u7$bs9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11379

I ask because my checkum is always 1 too large, which means that it was 
1 too small before I took the 1's complement.

Erm. Off-by-1 bug. Help?

Header checksum: 0x3e39 [incorrect, should be 0x3d39]
computed sum=1d41 != actual sum=1d40

-Yangfan

Yangfan Wang wrote:
> Also, the checksum is computed and verified *before* the TTL is 
> decremented, right?
> 
> -Yangfan
> 
> David Erickson wrote:
> 
>> Yangfan Wang wrote:
>>
>>> Okay, a few questions on computing checksum, since I'm not doing them 
>>> correctly... :p
>>>
>>> 1. An IP checksum computes the sum over the IP header only, but an 
>>> ICMP checksum computes it over both the ICMP header and its entire 
>>> body (the rest of the IP packet's data portion), right?
>>
>>
>>
>> The ICMP checksum is over the ICMP header information and the ICMP 
>> packet's body, however be careful what you put in the ICMP packet's body.
>>
>>> 2. Does the cheskum algorithm treat 8-bit fields differently? For 
>>> example, if it sees two consecutive 8-bit fields, will it add them to 
>>> the sum separately or as one 16-bit field?
>>
>>
>>
>> It treats them as a single 16 bit field.
>>
>> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: testing for errors
Date: Fri, 02 Feb 2007 02:50:25 -0800
Lines: 8
Distribution: su
Message-ID: <epv4ui$d2t$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170413330 13405 128.12.134.140 (2 Feb 2007 10:48:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11380

Hi,

Is there a way to stop arp responses from being sent back from the
servers? If not, does anyone know how we can test whether our routers
are working correctly when no arp response is coming back?

Thanks,
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: testing for errors
Date: Fri, 02 Feb 2007 05:05:32 -0800
Lines: 18
Distribution: su
Message-ID: <epvcui$mha$1@news.Stanford.EDU>
References: <epv4ui$d2t$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170421523 23082 128.12.194.72 (2 Feb 2007 13:05:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <epv4ui$d2t$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11381

I have an idea, and I want to tell it to you. (Because I'm a nice guy, 
and I'd like to verify whether it will work or not.)

However, the TAs have specificially said that this cache testing problem 
is a part of the project. And I want to a TA to confirm that this would 
be acceptable academic collaboration.

-Yangfan

Jad Naous wrote:
> Hi,
> 
> Is there a way to stop arp responses from being sent back from the
> servers? If not, does anyone know how we can test whether our routers
> are working correctly when no arp response is coming back?
> 
> Thanks,
> Jad
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Fri, 02 Feb 2007 08:00:06 -0800
Lines: 49
Distribution: su
Message-ID: <epvn5p$1n2$1@news.Stanford.EDU>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU> <eprtu9$qan$2@news.Stanford.EDU> <eps0fa$6e$1@news.Stanford.EDU> <C1E82AD6.8072%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170431993 1762 127.0.0.1 (2 Feb 2007 15:59:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <C1E82AD6.8072%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11382

Justin Pettit wrote:
> Personally, I think the RFC's advice is poor due to security concerns and
> possible problems with asynchronous routes.  This RFC was written in the
> early 1980's and security is a fairly recent concern for the IETF (the
> organization that produces RFCs).  A lot of older RFCs (and even fairly
> modern ones) have horrendous security problems.
> 
> With all of that said, you can feel free to accept unsolicited ARP replies
> (it seems most operating systems do) and cache the source MAC addresses of
> ARP requests.  It will just make me sad inside when I grade it.  ;)
> 
> If you are interested, here's an article discussing some of the security
> implications:
> 
>     http://shsc.info/ARPPoisoning
> 
> This is purely optional reading; we won't test you on it.
> 
> --Justin
> 
> 
> On 1/31/07 10:14 PM, in article eps0fa$6e$1@news.Stanford.EDU, "Greg Nelson"
> <grourk@stanford.edu> wrote:
> 
>> David Erickson wrote:
>>> Riju Kallivalappil wrote:
>>>> On a similar note, is it ok to cache the MAC maddress of the sender
>>>> when we receive an ARP request?
>>> I would say no, when the destination then sends a packet back through
>>> your router towards the sender it should send out an arp request in that
>>> direction to find the next MAC of the next hop.
>>>
>>> -David
>> I think the rfc for arp linked from the homework (rfc 826) says different:
>>
>> "Notice that the <protocol type, sender protocol address, sender
>> hardware address> triplet is merged into the table before the
>> opcode is looked at.  This is on the assumption that communcation
>> is bidirectional; if A has some reason to talk to B, then B will
>> probably have some reason to talk to A."
>>
>> Greg
> 
> 

Interesting.  I will adjust my code; I don't want you to be sad 
inside...  Especially while grading my assignment.  :)

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 09:54:56 -0800
Lines: 54
Distribution: su
Message-ID: <C1E8BAF0.808C%jpettit@stanford.edu>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU> <epv2u7$bs9$1@news.Stanford.EDU> <epv3l8$c7q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170438900 7942 127.0.0.1 (2 Feb 2007 17:55:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Questions on computing checksum.
Thread-Index: AcdG8z+Efd8hQbLmEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11383

Are you asking about the IP checksum from the original packet within the
ICMP payload?  If that is the case, then you shouldn't recompute the
checksum, just copy the original IP header and the first 64-bits of the
original IP payload into the new ICMP payload.

--Justin


On 2/2/07 2:26 AM, in article epv3l8$c7q$1@news.Stanford.EDU, "Yangfan Wang"
<yfw@stanford.edu> wrote:

> I ask because my checkum is always 1 too large, which means that it was
> 1 too small before I took the 1's complement.
> 
> Erm. Off-by-1 bug. Help?
> 
> Header checksum: 0x3e39 [incorrect, should be 0x3d39]
> computed sum=1d41 != actual sum=1d40
> 
> -Yangfan
> 
> Yangfan Wang wrote:
>> Also, the checksum is computed and verified *before* the TTL is
>> decremented, right?
>> 
>> -Yangfan
>> 
>> David Erickson wrote:
>> 
>>> Yangfan Wang wrote:
>>> 
>>>> Okay, a few questions on computing checksum, since I'm not doing them
>>>> correctly... :p
>>>> 
>>>> 1. An IP checksum computes the sum over the IP header only, but an
>>>> ICMP checksum computes it over both the ICMP header and its entire
>>>> body (the rest of the IP packet's data portion), right?
>>> 
>>> 
>>> 
>>> The ICMP checksum is over the ICMP header information and the ICMP
>>> packet's body, however be careful what you put in the ICMP packet's body.
>>> 
>>>> 2. Does the cheskum algorithm treat 8-bit fields differently? For
>>>> example, if it sees two consecutive 8-bit fields, will it add them to
>>>> the sum separately or as one 16-bit field?
>>> 
>>> 
>>> 
>>> It treats them as a single 16 bit field.
>>> 
>>> -David


.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: testing for errors
Date: Fri, 02 Feb 2007 13:19:01 -0800
Lines: 21
Distribution: su
Message-ID: <eq09s5$jn2$1@news.Stanford.EDU>
References: <epv4ui$d2t$1@news.Stanford.EDU> <epvcui$mha$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170451141 20194 128.12.104.61 (2 Feb 2007 21:19:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
In-Reply-To: <epvcui$mha$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11384

Yangfan Wang wrote:
> I have an idea, and I want to tell it to you. (Because I'm a nice guy, 
> and I'd like to verify whether it will work or not.)
> 
> However, the TAs have specificially said that this cache testing problem 
> is a part of the project. And I want to a TA to confirm that this would 
> be acceptable academic collaboration.
> 
> -Yangfan
> 
> Jad Naous wrote:
>> Hi,
>>
>> Is there a way to stop arp responses from being sent back from the
>> servers? If not, does anyone know how we can test whether our routers
>> are working correctly when no arp response is coming back?
>>
>> Thanks,
>> Jad
Google HPing... I'm not sure if we need root access to use it but it's 
great for sending arbitrary packets.
.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: tcpdump
Date: Fri, 2 Feb 2007 15:40:06 -0800
Lines: 8
Distribution: su
Message-ID: <Pine.LNX.4.44.0702021539370.6697-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170459608 28357 171.64.15.38 (2 Feb 2007 23:40:08 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11385

Hi,

I don't seem to have tcpdump on myth. Is this expected?

Thanks,
-Seung


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: arp src ip address from router
Date: Fri, 2 Feb 2007 15:44:47 -0800
Lines: 34
Distribution: su
Message-ID: <eq0icb$rqi$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170459851 28498 127.0.0.1 (2 Feb 2007 23:44:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11386

There have been quite a bit of questions about ARP requests originated by 
our router.  When a router sends an ARP request, the traffic I have sniffed 
all puts the routers ip address as the source address (not the src address 
of the packet it is about to forward).  Is this correct behavior?

I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me to 
the internet.  mali.cio.us wants to port scan my computer and sends its 
first packet towards Gateway.  Gateway sends out an ARP with (gateMac, 
171.64.72.1, 0x00 0000 0000, 171.64.72.24), not (gateMac, 171.64.72.1, 0x00 
0000 0000, 171.64.72.24).

Additionally, I believe (and I could be wrong on this side) that when a host 
wants to send a packet out into the internet, it will ARP the IP of the 
router interface on that link.  Therefore, ARPs received by the router will 
contain the IP of the router interface on that link.  IOW, we will not need 
to accept an arbitrary dst IP address and respond with our hardware address. 
Is this correct behavior?

I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me to 
the internet.  I want to send a message to www.ilikesalami.com (121.5.7.59). 
I look at my own routing table and see that those packets should go through 
Gateway, so I send out an ARP with (myMac, 171.64.72.1, 0x00 0000 0000, 
121.5.7.59), not (myMac, 171.64.72.24, 0x00 0000 0000, 121.5.7.59).

This is how I understand it.  Some of the posts on the newsgroup have made 
me wonder.  (The end result of how I understand it is that worrying about 
asymmetric reverse paths is kindof silly.)

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 2 Feb 2007 15:46:58 -0800
Lines: 16
Distribution: su
Message-ID: <eq0ig5$rv2$1@news.Stanford.EDU>
References: <eq0icb$rqi$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170459974 28642 127.0.0.1 (2 Feb 2007 23:46:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11387

>
> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me 
> to the internet.  mali.cio.us wants to port scan my computer and sends its 
> first packet towards Gateway.  Gateway sends out an ARP with (gateMac, 
> 171.64.72.1, 0x00 0000 0000, 171.64.72.24), not (gateMac, 171.64.72.1, 
> 0x00 0000 0000, 171.64.72.24).

That should be:

> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me 
> to the internet.  mali.cio.us (109.54.23.13) wants to port scan my 
> computer and sends its first packet towards Gateway.  Gateway sends out an 
> ARP with (gateMac, 171.64.72.1, 0x00 0000 0000, 171.64.72.24), not 
> (gateMac, 109.54.23.13, 0x00 0000 0000, 171.64.72.24).


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 16:47:00 -0800
Lines: 82
Distribution: su
Message-ID: <eq0m1p$1g5$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU> <epv2u7$bs9$1@news.Stanford.EDU> <epv3l8$c7q$1@news.Stanford.EDU> <C1E8BAF0.808C%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170463609 1541 128.12.194.72 (3 Feb 2007 00:46:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1E8BAF0.808C%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11388

Um, no,

I compute the checksum for:

verifying the checksum of IP packets that I receive
(off by ntohs(0x0001))

re-computing the checksum of the IP packets after I decrement the TTL 
(off by ntohs(0x0001))

computing the checksum of the ICMP packets that I send
(off by ntohs(0x0002)!)

I'm not even verifying the checksums of the ICMP packets that I receive 
yet. I'm pretty sure I'd get those wrong as well.

I don't understand the off-by-1 problem though. Is the sum supposed to 
start at 1, or what?

-Yangfan

Justin Pettit wrote:
> Are you asking about the IP checksum from the original packet within the
> ICMP payload?  If that is the case, then you shouldn't recompute the
> checksum, just copy the original IP header and the first 64-bits of the
> original IP payload into the new ICMP payload.
> 
> --Justin
> 
> 
> On 2/2/07 2:26 AM, in article epv3l8$c7q$1@news.Stanford.EDU, "Yangfan Wang"
> <yfw@stanford.edu> wrote:
> 
> 
>>I ask because my checkum is always 1 too large, which means that it was
>>1 too small before I took the 1's complement.
>>
>>Erm. Off-by-1 bug. Help?
>>
>>Header checksum: 0x3e39 [incorrect, should be 0x3d39]
>>computed sum=1d41 != actual sum=1d40
>>
>>-Yangfan
>>
>>Yangfan Wang wrote:
>>
>>>Also, the checksum is computed and verified *before* the TTL is
>>>decremented, right?
>>>
>>>-Yangfan
>>>
>>>David Erickson wrote:
>>>
>>>
>>>>Yangfan Wang wrote:
>>>>
>>>>
>>>>>Okay, a few questions on computing checksum, since I'm not doing them
>>>>>correctly... :p
>>>>>
>>>>>1. An IP checksum computes the sum over the IP header only, but an
>>>>>ICMP checksum computes it over both the ICMP header and its entire
>>>>>body (the rest of the IP packet's data portion), right?
>>>>
>>>>
>>>>
>>>>The ICMP checksum is over the ICMP header information and the ICMP
>>>>packet's body, however be careful what you put in the ICMP packet's body.
>>>>
>>>>
>>>>>2. Does the cheskum algorithm treat 8-bit fields differently? For
>>>>>example, if it sees two consecutive 8-bit fields, will it add them to
>>>>>the sum separately or as one 16-bit field?
>>>>
>>>>
>>>>
>>>>It treats them as a single 16 bit field.
>>>>
>>>>-David
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 02 Feb 2007 16:53:40 -0800
Lines: 52
Distribution: su
Message-ID: <eq0me9$1r9$1@news.Stanford.EDU>
References: <eq0icb$rqi$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170464009 1897 128.12.194.72 (3 Feb 2007 00:53:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq0icb$rqi$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11389

I have a question that is related to Randy's question, although I 
suspect that it's just a re-phrasing of it:

Will my router ever need to *forward* an ARP packet? Either request or 
reply?

In other words, does the ARP cache keep track of the MAC addresses of 
the IPs of the interfaces on the other side of its links, or does it 
keep track of the proper MAC address for all IPs that it handles?

The latter doesn't make much sense to me, since even if a router knows 
the MAC address of some destination IP, it's useless if there is no 
direct Ethernet link between the two. It seems to me that a router would 
only care about the MAC addresses of the interfaces it has a direct link to.

-Yangfan

Randy Jennings wrote:
> There have been quite a bit of questions about ARP requests originated by 
> our router.  When a router sends an ARP request, the traffic I have sniffed 
> all puts the routers ip address as the source address (not the src address 
> of the packet it is about to forward).  Is this correct behavior?
> 
> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me to 
> the internet.  mali.cio.us wants to port scan my computer and sends its 
> first packet towards Gateway.  Gateway sends out an ARP with (gateMac, 
> 171.64.72.1, 0x00 0000 0000, 171.64.72.24), not (gateMac, 171.64.72.1, 0x00 
> 0000 0000, 171.64.72.24).
> 
> Additionally, I believe (and I could be wrong on this side) that when a host 
> wants to send a packet out into the internet, it will ARP the IP of the 
> router interface on that link.  Therefore, ARPs received by the router will 
> contain the IP of the router interface on that link.  IOW, we will not need 
> to accept an arbitrary dst IP address and respond with our hardware address. 
> Is this correct behavior?
> 
> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me to 
> the internet.  I want to send a message to www.ilikesalami.com (121.5.7.59). 
> I look at my own routing table and see that those packets should go through 
> Gateway, so I send out an ARP with (myMac, 171.64.72.1, 0x00 0000 0000, 
> 121.5.7.59), not (myMac, 171.64.72.24, 0x00 0000 0000, 121.5.7.59).
> 
> This is how I understand it.  Some of the posts on the newsgroup have made 
> me wonder.  (The end result of how I understand it is that worrying about 
> asymmetric reverse paths is kindof silly.)
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: tcpdump
Date: Fri, 02 Feb 2007 17:30:20 -0800
Lines: 21
Distribution: su
Message-ID: <C1E925AC.80B5%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0702021539370.6697-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170466224 3827 127.0.0.1 (3 Feb 2007 01:30:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: tcpdump
Thread-Index: AcdHMt3kHIOCnLMmEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11390

Did you specify the complete path like in question 3 of the FAQ?

    /usr/class/cs244a/bin/tcpdump

--Justin


On 2/2/07 3:40 PM, in article
Pine.LNX.4.44.0702021539370.6697-100000@myth20.Stanford.EDU, "Seung Hoon
Choi" <shchoi@stanford.edu> wrote:

> Hi,
> 
> I don't seem to have tcpdump on myth. Is this expected?
> 
> Thanks,
> -Seung
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 02 Feb 2007 17:33:25 -0800
Lines: 19
Distribution: su
Message-ID: <C1E92665.80B7%jpettit@stanford.edu>
References: <eq0icb$rqi$1@news.Stanford.EDU> <eq0me9$1r9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170466408 3916 127.0.0.1 (3 Feb 2007 01:33:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp src ip address from router
Thread-Index: AcdHM0woiny/+rMmEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11391

> Will my router ever need to *forward* an ARP packet? Either request or
> reply?

No.

> In other words, does the ARP cache keep track of the MAC addresses of
> the IPs of the interfaces on the other side of its links, or does it
> keep track of the proper MAC address for all IPs that it handles?
> 
> The latter doesn't make much sense to me, since even if a router knows
> the MAC address of some destination IP, it's useless if there is no
> direct Ethernet link between the two. It seems to me that a router would
> only care about the MAC addresses of the interfaces it has a direct link to.

This is correct; your router only cares about the MAC addresses of the
interfaces to which it has a direct link.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 02 Feb 2007 17:41:47 -0800
Lines: 94
Distribution: su
Message-ID: <C1E9285B.80B9%jpettit@stanford.edu>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU> <epv2u7$bs9$1@news.Stanford.EDU> <epv3l8$c7q$1@news.Stanford.EDU> <C1E8BAF0.808C%jpettit@stanford.edu> <eq0m1p$1g5$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170466910 4294 127.0.0.1 (3 Feb 2007 01:41:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Questions on computing checksum.
Thread-Index: AcdHNHdftboY7rMnEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11392

I don't know what to tell you then.  Make sure that you start off with the
checksum field set to zero and take a look at Figure 28.15 in Stevens to
make sure that you're doing the calculation properly.

--Justin


On 2/2/07 4:47 PM, in article eq0m1p$1g5$1@news.Stanford.EDU, "Yangfan Wang"
<yfw@stanford.edu> wrote:

> Um, no,
> 
> I compute the checksum for:
> 
> verifying the checksum of IP packets that I receive
> (off by ntohs(0x0001))
> 
> re-computing the checksum of the IP packets after I decrement the TTL
> (off by ntohs(0x0001))
> 
> computing the checksum of the ICMP packets that I send
> (off by ntohs(0x0002)!)
> 
> I'm not even verifying the checksums of the ICMP packets that I receive
> yet. I'm pretty sure I'd get those wrong as well.
> 
> I don't understand the off-by-1 problem though. Is the sum supposed to
> start at 1, or what?
> 
> -Yangfan
> 
> Justin Pettit wrote:
>> Are you asking about the IP checksum from the original packet within the
>> ICMP payload?  If that is the case, then you shouldn't recompute the
>> checksum, just copy the original IP header and the first 64-bits of the
>> original IP payload into the new ICMP payload.
>> 
>> --Justin
>> 
>> 
>> On 2/2/07 2:26 AM, in article epv3l8$c7q$1@news.Stanford.EDU, "Yangfan Wang"
>> <yfw@stanford.edu> wrote:
>> 
>> 
>>> I ask because my checkum is always 1 too large, which means that it was
>>> 1 too small before I took the 1's complement.
>>> 
>>> Erm. Off-by-1 bug. Help?
>>> 
>>> Header checksum: 0x3e39 [incorrect, should be 0x3d39]
>>> computed sum=1d41 != actual sum=1d40
>>> 
>>> -Yangfan
>>> 
>>> Yangfan Wang wrote:
>>> 
>>>> Also, the checksum is computed and verified *before* the TTL is
>>>> decremented, right?
>>>> 
>>>> -Yangfan
>>>> 
>>>> David Erickson wrote:
>>>> 
>>>> 
>>>>> Yangfan Wang wrote:
>>>>> 
>>>>> 
>>>>>> Okay, a few questions on computing checksum, since I'm not doing them
>>>>>> correctly... :p
>>>>>> 
>>>>>> 1. An IP checksum computes the sum over the IP header only, but an
>>>>>> ICMP checksum computes it over both the ICMP header and its entire
>>>>>> body (the rest of the IP packet's data portion), right?
>>>>> 
>>>>> 
>>>>> 
>>>>> The ICMP checksum is over the ICMP header information and the ICMP
>>>>> packet's body, however be careful what you put in the ICMP packet's body.
>>>>> 
>>>>> 
>>>>>> 2. Does the cheskum algorithm treat 8-bit fields differently? For
>>>>>> example, if it sees two consecutive 8-bit fields, will it add them to
>>>>>> the sum separately or as one 16-bit field?
>>>>> 
>>>>> 
>>>>> 
>>>>> It treats them as a single 16 bit field.
>>>>> 
>>>>> -David
>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 02 Feb 2007 19:03:06 -0800
Lines: 88
Distribution: su
Message-ID: <C1E93B6A.80C0%jpettit@stanford.edu>
References: <eq0icb$rqi$1@news.Stanford.EDU> <eq0ig5$rv2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170471789 8481 127.0.0.1 (3 Feb 2007 03:03:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp src ip address from router
Thread-Index: AcdHP9N8EchhB7MzEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11393

> There have been quite a bit of questions about ARP requests originated by
> our router.  When a router sends an ARP request, the traffic I have sniffed
> all puts the routers ip address as the source address (not the src address
> of the packet it is about to forward).  Is this correct behavior?
 
Yes, it is.

> Additionally, I believe (and I could be wrong on this side) that when a host
> wants to send a packet out into the internet, it will ARP the IP of the
> router interface on that link.  Therefore, ARPs received by the router will
> contain the IP of the router interface on that link.  IOW, we will not need
> to accept an arbitrary dst IP address and respond with our hardware address.
> Is this correct behavior?

Yes, this is also correct.
 
> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me to
> the internet.  I want to send a message to www.ilikesalami.com (121.5.7.59).
> I look at my own routing table and see that those packets should go through
> Gateway, so I send out an ARP with (myMac, 171.64.72.1, 0x00 0000 0000,
> 121.5.7.59), not (myMac, 171.64.72.24, 0x00 0000 0000, 121.5.7.59).

Using your convention, I think you mean the host would send: (myMac,
171.64.72.24, 0x00 0000 0000, 171.64.72.1), right?  The gateway would then
send an ARP request to whatever it's next hop is.
 
> This is how I understand it.  Some of the posts on the newsgroup have made
> me wonder.  (The end result of how I understand it is that worrying about
> asymmetric reverse paths is kindof silly.)

All of your assumptions here are correct.  The ARP thread did get confusing,
and I didn't do a good job of clearing things up.  The issue of asynchronous
routes was about not consulting the routing table and assuming the ARP cache
had all the information you need.

I'll try to come up with a concrete example.  Let's say that you subscribe
to a satellite ISP.  You get your download traffic from the satellite and
you send your upstream traffic through a modem, since you don't have a
satellite uplink at your house.

Let's say ilikesalami.com wants to connect to a host sitting behind your
router.  The setup looks like this:

                ilikesalami.com (121.5.7.59, 00:59)
                              |
                              |
                           Internet
                              |
           +------------------+-------------------+
           |                                      |
 eth0(171.64.73.2, 02:00)             eth0(171.64.73.3, 03:00)
          R2                                     R3
 eth1(171.64.72.2, 02:01)             eth1(171.64.72.3, 03:01)
           |                                      |
           +------------------+-------------------+
                              |
                    eth0(171.64.72.1, 01:00)
                              R1
                    eth1(171.64.71.1, 01:01)
                              |
                              |
                   User (171.64.71.24, 00:24)

I've simplified things a lot here.  And those colon separated numbers are
the MAC addresses that have been abbreviated from 6 octets to 2.

Your software is running at R1 and has the following routing table:

    0.0.0.0           171.64.72.3    0.0.0.0               eth0
    171.64.71.0  171.64.71.1     255.255.255.0   eth1

Let's say that you always put the source MAC addresses from ARP requests and
IP packets in your ARP table.  It will look like the following:

    171.64.72.2    02:01     eth0    // From the ARP request to get R1's MAC
    121.5.7.59      02:01     eth0    // From receiving the IP packet

Now, your host decides to send a response back to ilikesalami.com.  Your
router *should* consult its routing table and see that the packet should be
sent through R3 at 171.64.72.3.  However, if you try and short-cut it by
consulting the ARP cache, then you will improperly send it to R2 due to the
171.64.72.2 entry.

Hopefully that clears things up.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 2 Feb 2007 19:38:09 -0800
Lines: 16
Distribution: su
Message-ID: <eq101l$9i8$1@news.Stanford.EDU>
References: <eq0icb$rqi$1@news.Stanford.EDU> <eq0me9$1r9$1@news.Stanford.EDU> <C1E92665.80B7%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170473845 9800 127.0.0.1 (3 Feb 2007 03:37:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11394

>> Will my router ever need to *forward* an ARP packet? Either request or
>> reply?
>
> No.
>
An interesting corollary to that is when you receive an ARP request packet 
(for the IP of interface 3) (on interface 2).  That should be a bug in 
someone else's code, but answering that ARP would be incorrect because you 
would effectively be "forwarding" the ARP.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Questions on computing checksum.
Date: Fri, 2 Feb 2007 19:40:11 -0800
Lines: 88
Distribution: su
Message-ID: <eq105f$9kv$1@news.Stanford.EDU>
References: <eps190$rq$1@news.Stanford.EDU> <epsjsr$mpg$1@news.Stanford.EDU> <epv2u7$bs9$1@news.Stanford.EDU> <epv3l8$c7q$1@news.Stanford.EDU> <C1E8BAF0.808C%jpettit@stanford.edu> <eq0m1p$1g5$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170473967 9887 127.0.0.1 (3 Feb 2007 03:39:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11395

Well, what do you do when the error is deterministic :-)?

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eq0m1p$1g5$1@news.Stanford.EDU...
> Um, no,
>
> I compute the checksum for:
>
> verifying the checksum of IP packets that I receive
> (off by ntohs(0x0001))
>
> re-computing the checksum of the IP packets after I decrement the TTL (off 
> by ntohs(0x0001))
>
> computing the checksum of the ICMP packets that I send
> (off by ntohs(0x0002)!)
>
> I'm not even verifying the checksums of the ICMP packets that I receive 
> yet. I'm pretty sure I'd get those wrong as well.
>
> I don't understand the off-by-1 problem though. Is the sum supposed to 
> start at 1, or what?
>
> -Yangfan
>
> Justin Pettit wrote:
>> Are you asking about the IP checksum from the original packet within the
>> ICMP payload?  If that is the case, then you shouldn't recompute the
>> checksum, just copy the original IP header and the first 64-bits of the
>> original IP payload into the new ICMP payload.
>>
>> --Justin
>>
>>
>> On 2/2/07 2:26 AM, in article epv3l8$c7q$1@news.Stanford.EDU, "Yangfan 
>> Wang"
>> <yfw@stanford.edu> wrote:
>>
>>
>>>I ask because my checkum is always 1 too large, which means that it was
>>>1 too small before I took the 1's complement.
>>>
>>>Erm. Off-by-1 bug. Help?
>>>
>>>Header checksum: 0x3e39 [incorrect, should be 0x3d39]
>>>computed sum=1d41 != actual sum=1d40
>>>
>>>-Yangfan
>>>
>>>Yangfan Wang wrote:
>>>
>>>>Also, the checksum is computed and verified *before* the TTL is
>>>>decremented, right?
>>>>
>>>>-Yangfan
>>>>
>>>>David Erickson wrote:
>>>>
>>>>
>>>>>Yangfan Wang wrote:
>>>>>
>>>>>
>>>>>>Okay, a few questions on computing checksum, since I'm not doing them
>>>>>>correctly... :p
>>>>>>
>>>>>>1. An IP checksum computes the sum over the IP header only, but an
>>>>>>ICMP checksum computes it over both the ICMP header and its entire
>>>>>>body (the rest of the IP packet's data portion), right?
>>>>>
>>>>>
>>>>>
>>>>>The ICMP checksum is over the ICMP header information and the ICMP
>>>>>packet's body, however be careful what you put in the ICMP packet's 
>>>>>body.
>>>>>
>>>>>
>>>>>>2. Does the cheskum algorithm treat 8-bit fields differently? For
>>>>>>example, if it sees two consecutive 8-bit fields, will it add them to
>>>>>>the sum separately or as one 16-bit field?
>>>>>
>>>>>
>>>>>
>>>>>It treats them as a single 16 bit field.
>>>>>
>>>>>-David
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp src ip address from router
Date: Fri, 2 Feb 2007 19:44:37 -0800
Lines: 23
Distribution: su
Message-ID: <eq10dp$9rh$1@news.Stanford.EDU>
References: <eq0icb$rqi$1@news.Stanford.EDU> <eq0ig5$rv2$1@news.Stanford.EDU> <C1E93B6A.80C0%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1170474233 10097 127.0.0.1 (3 Feb 2007 03:43:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11396

>> I.e. I am a host (171.64.72.24) with Gateway (171.64.72.1) connecting me 
>> to
>> the internet.  I want to send a message to www.ilikesalami.com 
>> (121.5.7.59).
>> I look at my own routing table and see that those packets should go 
>> through
>> Gateway, so I send out an ARP with (myMac, 171.64.72.1, 0x00 0000 0000,
>> 121.5.7.59), not (myMac, 171.64.72.24, 0x00 0000 0000, 121.5.7.59).
>
> Using your convention, I think you mean the host would send: (myMac,
> 171.64.72.24, 0x00 0000 0000, 171.64.72.1), right?  The gateway would then
> send an ARP request to whatever it's next hop is.
Yes, my bad.  Cutting and pasting constants is often a bad idea.

> Hopefully that clears things up.
Good example.  Yes, I am back on solid ground.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing of reply packets
Date: Fri, 02 Feb 2007 21:04:12 -0800
Lines: 183
Distribution: su
Message-ID: <C1E957CC.80CD%jpettit@stanford.edu>
References: <epuocq$se3$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170479055 13364 127.0.0.1 (3 Feb 2007 05:04:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Routing of reply packets
Thread-Index: AcdHUL5b/Nb9+7NDEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11397

The packets shouldn't be routed through a different path.  As Paul discussed
in today's review section, you may want to play with Clack:

    http://www.clackrouter.net/

You can tell it to load your topology and see how it routes the traffic.
Your router should behave in essentially the same manner.

--Justin


On 2/1/07 11:14 PM, in article epuocq$se3$1@news.Stanford.EDU, "Riju
Kallivalappil" <riju@stanford.edu> wrote:

> When I connect to one of the application servers in my topology through my
> router, are the packets returned by the application server routed through a
> different path? I don't see any of the packets from the application servers
> going through my code. But, I can access the website on the application
> server without a problem.
> 
> The tcpdump output is given below
> 
> 
> reading from file tcpdump.pcap, link-type EN10MB (Ethernet)
> 22:51:22.320859 00:e0:81:04:26:d9 (oui Unknown) > Broadcast, ethertype ARP
> (0x0806), length 60: arp who-has aradia-router-3.Stanford.EDU tell
> vns-firewall.Stanford.EDU
>         0x0000:  0001 0800 0604 0001 00e0 8104 26d9 ac18
>         0x0010:  4a11 0000 0000 0000 c0a8 813a 0000 0000
>         0x0020:  0000 0000 0000 0000 0000 0000 0000
> 22:51:22.320994 70:00:00:d8:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui
> Unknown), ethertype ARP (0x0806), length 42: arp reply
> aradia-router-3.Stanford.EDU is-at 70:00:00:d8:00:01 (oui Unknown)
>         0x0000:  0001 0800 0604 0002 7000 00d8 0001 c0a8
>         0x0010:  813a 00e0 8104 26d9 ac18 4a11
> 22:51:22.322648 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29414,
> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: S, cksum 0x586e (correct),
> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280412369
> 0,nop,wscale 2>
>         0x0000:  4510 003c 72e6 4000 3c06 cea7 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>         0x0020:  a002 16d0 586e 0000 0204 05b4 0402 080a
>         0x0030:  ff21 e8d1 0000 0000 0103 0302
> 22:51:22.322699 70:00:00:d8:00:06 (oui Unknown) > Broadcast, ethertype ARP
> (0x0806), length 42: arp who-has aseems-router-3.Stanford.EDU tell
> ftp-arethusa.Stanford.EDU
>         0x0000:  0001 0800 0604 0001 7000 00d8 0006 c0a8
>         0x0010:  813d 0000 0000 0000 c0a8 813e
> 22:51:22.324343 00:04:75:7b:e9:22 (oui Unknown) > 70:00:00:d8:00:06 (oui
> Unknown), ethertype ARP (0x0806), length 60: arp reply
> aseems-router-3.Stanford.EDU is-at 00:04:75:7b:e9:22 (oui Unknown)
>         0x0000:  0001 0800 0604 0002 0004 757b e922 c0a8
>         0x0010:  813e 7000 00d8 0006 c0a8 813d 0000 0000
>         0x0020:  0000 0000 0000 0000 0000 0000 0000
> 22:51:22.324376 70:00:00:d8:00:06 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 74: IP3 truncated-ip - 62267 bytes
> missing! (tos 0x59,ECT(1), id 14425, offset 39864, flags [+, DF, rsvd],
> proto: Options (0), length: 62327, options ( EOL (0) len 1 ), bad cksum 20
> (->3783)!) 112.0.0.216 > 0.2.0.0: ip
>         0x0000:  3859 f377 3859 f377 0000 0020 7000 00d8
>         0x0010:  0002 0000 0000 0000 0000 0000 0000 0000
>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0040
>         0x0030:  c0a8 813b 0000 0000 0000 0000
> 22:51:25.314742 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29415,
> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
> 0,nop,wscale 2>
>         0x0000:  4510 003c 72e7 4000 3c06 cea6 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>         0x0030:  ff21 ebbf 0000 0000 0103 0302
> 22:51:25.314881 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  59, id 29415,
> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
> 0,nop,wscale 2>
>         0x0000:  4510 003c 72e7 4000 3b06 cfa6 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>         0x0030:  ff21 ebbf 0000 0000 0103 0302
> 22:51:25.317031 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29416,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct),
> 3079051832:3079051832(0) ack 64737525 win 1460 <nop,nop,timestamp 4280413119
> 789674283>
>         0x0000:  4510 0034 72e8 4000 3c06 cead ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>         0x0030:  2f11 792b
> 22:51:25.317105 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29416,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct), 0:0(0) ack 1
> win 1460 <nop,nop,timestamp 4280413119 789674283>
>         0x0000:  4510 0034 72e8 4000 3b06 cfad ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>         0x0030:  2f11 792b
> 22:51:30.998908 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  60, id 29417,
> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>         0x0000:  4510 0044 72e9 4000 3c06 ce9c ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>         0x0040:  2e30 0d0a
> 22:51:30.999020 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  59, id 29417,
> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>         0x0000:  4510 0044 72e9 4000 3b06 cf9c ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>         0x0040:  2e30 0d0a
> 22:51:31.980478 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  60, id 29418,
> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>         0x0000:  4510 0036 72ea 4000 3c06 cea9 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>         0x0030:  2f11 7b63 0d0a
> 22:51:31.980600 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  59, id 29418,
> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>         0x0000:  4510 0036 72ea 4000 3b06 cfa9 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>         0x0030:  2f11 7b63 0d0a
> 22:51:31.983665 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29419,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>         0x0000:  4510 0034 72eb 4000 3c06 ceaa ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>         0x0030:  2f11 7bc6
> 22:51:31.983724 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29419,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>         0x0000:  4510 0034 72eb 4000 3b06 cfaa ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>         0x0030:  2f11 7bc6
> 22:51:31.985257 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29420,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>         0x0000:  4510 0034 72ec 4000 3c06 cea9 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>         0x0030:  2f11 7bc6
> 22:51:31.985292 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29420,
> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>         0x0000:  4510 0034 72ec 4000 3b06 cfa9 ab40 0ff7
>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>         0x0030:  2f11 7bc6
> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP reply assumption
Date: Fri, 02 Feb 2007 21:11:05 -0800
Lines: 15
Distribution: su
Message-ID: <C1E95969.80D1%jpettit@stanford.edu>
References: <eppgd1$7pa$1@news.Stanford.EDU> <eppo80$gsd$1@news.Stanford.EDU> <epqvhv$nk0$1@news.Stanford.EDU> <epr74p$3so$1@news.Stanford.EDU> <eprca6$7t7$1@news.Stanford.EDU> <eprtu9$qan$2@news.Stanford.EDU> <eps0fa$6e$1@news.Stanford.EDU> <C1E82AD6.8072%jpettit@stanford.edu> <epvn5p$1n2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170479469 13712 127.0.0.1 (3 Feb 2007 05:11:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ICMP reply assumption
Thread-Index: AcdHUbSG8yhtELNEEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11398

>> With all of that said, you can feel free to accept unsolicited ARP replies
>> (it seems most operating systems do) and cache the source MAC addresses of
>> ARP requests.  It will just make me sad inside when I grade it.  ;)
>
> Interesting.  I will adjust my code; I don't want you to be sad
> inside...  Especially while grading my assignment.  :)

I appreciate your concern.  :)  Honestly, everyone can implement their code
in either manner.  If you don't accept unsolicited ARP replies, then you
should list it as one of your additions in the README.  Very few people
attempted to go above and beyond the basics in PA1, so I'd encourage
everyone to add some neat stuff this time around!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: testing for errors
Date: Fri, 02 Feb 2007 21:13:11 -0800
Lines: 8
Distribution: su
Message-ID: <C1E959E7.80D4%jpettit@stanford.edu>
References: <epv4ui$d2t$1@news.Stanford.EDU> <epvcui$mha$1@news.Stanford.EDU> <eq09s5$jn2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170479594 13779 127.0.0.1 (3 Feb 2007 05:13:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: testing for errors
Thread-Index: AcdHUf+gPfICcLNFEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11399

> Google HPing... I'm not sure if we need root access to use it but it's
> great for sending arbitrary packets.

Hping is a great tool, but you will need root access to generate arbitrary
packets.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: testing for errors
Date: Fri, 02 Feb 2007 22:49:37 -0800
Lines: 29
Distribution: su
Message-ID: <C1E97081.80DA%jpettit@stanford.edu>
References: <epv4ui$d2t$1@news.Stanford.EDU> <epvcui$mha$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170485381 17684 127.0.0.1 (3 Feb 2007 06:49:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: testing for errors
Thread-Index: AcdHX3hatqmPUrNSEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11400

Since it is specifically mentioned in the assignment, it is probably best to
limit your discussions on this subject.

--Justin


On 2/2/07 5:05 AM, in article epvcui$mha$1@news.Stanford.EDU, "Yangfan Wang"
<yfw@stanford.edu> wrote:

> I have an idea, and I want to tell it to you. (Because I'm a nice guy,
> and I'd like to verify whether it will work or not.)
> 
> However, the TAs have specificially said that this cache testing problem
> is a part of the project. And I want to a TA to confirm that this would
> be acceptable academic collaboration.
> 
> -Yangfan
> 
> Jad Naous wrote:
>> Hi,
>> 
>> Is there a way to stop arp responses from being sent back from the
>> servers? If not, does anyone know how we can test whether our routers
>> are working correctly when no arp response is coming back?
>> 
>> Thanks,
>> Jad


.

Path: shelby.stanford.edu!not-for-mail
From: Jitendra Nath Pandey <jnpandey@gmail.com>
Newsgroups: su.class.cs244a
Subject: Re: Cache timeout strategy
Date: Fri, 02 Feb 2007 23:01:35 -0800
Lines: 43
Distribution: su
Message-ID: <eq1c0c$hdp$1@news.Stanford.EDU>
References: <eporg2$lr0$1@news.Stanford.EDU> <epp93p$2cg$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170486092 17849 127.0.0.1 (3 Feb 2007 07:01:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
In-Reply-To: <epp93p$2cg$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11401

How about this approach.
    When an arp entry is created, also store the time at which it was 
created. When cache-lookup module finds that entry it compares it with 
the current time and uses only if it is within the timeout period. I 
think this way we can enforce it in a single thread.

regards
jitendra




Randy Jennings wrote:
> There is another strategy.  When the timeout thread goes back to sleep, it 
> can adjust the sleep time based on the request that is the closest to timing 
> out.  (I think this adjustable timeout is common practice on select loops 
> with timeouts.)
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Matt Page" <mpage@stanford.edu> wrote in message 
> news:eporg2$lr0$1@news.Stanford.EDU...
>> Is it better to have a single thread that checks the arp cache every 15 
>> seconds
>> and times out entries or to spawn a new thread any time an entry is added 
>> that
>> sleeps for 15 seconds and then removes it from the cache?
>>
>> A single thread wouldn't be able to *strictly* enforce the 15 second 
>> timeout
>> policy as an entry added right after the timeout thread ran would stay in 
>> the
>> cache for close to twice the timeout period.
>>
>> How strictly must we enforce the timeout period?
>>
>> Thanks,
>> Matt
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cache timeout strategy
Date: Fri, 02 Feb 2007 23:16:49 -0800
Lines: 58
Distribution: su
Message-ID: <C1E976E1.80E2%jpettit@stanford.edu>
References: <eporg2$lr0$1@news.Stanford.EDU> <epp93p$2cg$1@news.Stanford.EDU> <eq1c0c$hdp$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170487013 18743 127.0.0.1 (3 Feb 2007 07:16:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Cache timeout strategy
Thread-Index: AcdHY0UZg6N4L7NWEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11402

That's a decent strategy for expiring entries in the ARP cache.  However,
you still need to handle sending ICMP host unreachable messages when you
don't get ARP replies.  Keep in mind that you could receive a single IP
packet with a destination that is down.  You need to send five ARP requests,
and if you're not receiving any new packets, you need another way to wake
yourself up to send them.

--Justin


On 2/2/07 11:01 PM, in article eq1c0c$hdp$1@news.Stanford.EDU, "Jitendra
Nath Pandey" <jnpandey@gmail.com> wrote:

> How about this approach.
>     When an arp entry is created, also store the time at which it was
> created. When cache-lookup module finds that entry it compares it with
> the current time and uses only if it is within the timeout period. I
> think this way we can enforce it in a single thread.
> 
> regards
> jitendra
> 
> 
> 
> 
> Randy Jennings wrote:
>> There is another strategy.  When the timeout thread goes back to sleep, it
>> can adjust the sleep time based on the request that is the closest to timing
>> out.  (I think this adjustable timeout is common practice on select loops
>> with timeouts.)
>> 
>> Sincerely,
>> Randy Jennings
>> 
>> The squirrels are your friends!
>> "Matt Page" <mpage@stanford.edu> wrote in message
>> news:eporg2$lr0$1@news.Stanford.EDU...
>>> Is it better to have a single thread that checks the arp cache every 15
>>> seconds
>>> and times out entries or to spawn a new thread any time an entry is added
>>> that
>>> sleeps for 15 seconds and then removes it from the cache?
>>> 
>>> A single thread wouldn't be able to *strictly* enforce the 15 second
>>> timeout
>>> policy as an entry added right after the timeout thread ran would stay in
>>> the
>>> cache for close to twice the timeout period.
>>> 
>>> How strictly must we enforce the timeout period?
>>> 
>>> Thanks,
>>> Matt
>>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing of reply packets
Date: Fri, 02 Feb 2007 23:51:11 -0800
Lines: 192
Distribution: su
Message-ID: <eq1ess$koq$1@news.Stanford.EDU>
References: <epuocq$se3$1@news.Stanford.EDU> <C1E957CC.80CD%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170489052 21274 127.0.0.1 (3 Feb 2007 07:50:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <C1E957CC.80CD%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11403

I'm having the same issue.  Even when I watch in Clack, packets are 
being sent through my router _to_ the application server but not _from_ 
the application server back to the client; however, the client is 
receiving packets.  Are the application servers configured to send 
traffic back on a different route or something?

Greg

Justin Pettit wrote:
> The packets shouldn't be routed through a different path.  As Paul discussed
> in today's review section, you may want to play with Clack:
> 
>     http://www.clackrouter.net/
> 
> You can tell it to load your topology and see how it routes the traffic.
> Your router should behave in essentially the same manner.
> 
> --Justin
> 
> 
> On 2/1/07 11:14 PM, in article epuocq$se3$1@news.Stanford.EDU, "Riju
> Kallivalappil" <riju@stanford.edu> wrote:
> 
>> When I connect to one of the application servers in my topology through my
>> router, are the packets returned by the application server routed through a
>> different path? I don't see any of the packets from the application servers
>> going through my code. But, I can access the website on the application
>> server without a problem.
>>
>> The tcpdump output is given below
>>
>>
>> reading from file tcpdump.pcap, link-type EN10MB (Ethernet)
>> 22:51:22.320859 00:e0:81:04:26:d9 (oui Unknown) > Broadcast, ethertype ARP
>> (0x0806), length 60: arp who-has aradia-router-3.Stanford.EDU tell
>> vns-firewall.Stanford.EDU
>>         0x0000:  0001 0800 0604 0001 00e0 8104 26d9 ac18
>>         0x0010:  4a11 0000 0000 0000 c0a8 813a 0000 0000
>>         0x0020:  0000 0000 0000 0000 0000 0000 0000
>> 22:51:22.320994 70:00:00:d8:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui
>> Unknown), ethertype ARP (0x0806), length 42: arp reply
>> aradia-router-3.Stanford.EDU is-at 70:00:00:d8:00:01 (oui Unknown)
>>         0x0000:  0001 0800 0604 0002 7000 00d8 0001 c0a8
>>         0x0010:  813a 00e0 8104 26d9 ac18 4a11
>> 22:51:22.322648 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29414,
>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x586e (correct),
>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280412369
>> 0,nop,wscale 2>
>>         0x0000:  4510 003c 72e6 4000 3c06 cea7 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>         0x0020:  a002 16d0 586e 0000 0204 05b4 0402 080a
>>         0x0030:  ff21 e8d1 0000 0000 0103 0302
>> 22:51:22.322699 70:00:00:d8:00:06 (oui Unknown) > Broadcast, ethertype ARP
>> (0x0806), length 42: arp who-has aseems-router-3.Stanford.EDU tell
>> ftp-arethusa.Stanford.EDU
>>         0x0000:  0001 0800 0604 0001 7000 00d8 0006 c0a8
>>         0x0010:  813d 0000 0000 0000 c0a8 813e
>> 22:51:22.324343 00:04:75:7b:e9:22 (oui Unknown) > 70:00:00:d8:00:06 (oui
>> Unknown), ethertype ARP (0x0806), length 60: arp reply
>> aseems-router-3.Stanford.EDU is-at 00:04:75:7b:e9:22 (oui Unknown)
>>         0x0000:  0001 0800 0604 0002 0004 757b e922 c0a8
>>         0x0010:  813e 7000 00d8 0006 c0a8 813d 0000 0000
>>         0x0020:  0000 0000 0000 0000 0000 0000 0000
>> 22:51:22.324376 70:00:00:d8:00:06 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 74: IP3 truncated-ip - 62267 bytes
>> missing! (tos 0x59,ECT(1), id 14425, offset 39864, flags [+, DF, rsvd],
>> proto: Options (0), length: 62327, options ( EOL (0) len 1 ), bad cksum 20
>> (->3783)!) 112.0.0.216 > 0.2.0.0: ip
>>         0x0000:  3859 f377 3859 f377 0000 0020 7000 00d8
>>         0x0010:  0002 0000 0000 0000 0000 0000 0000 0000
>>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0040
>>         0x0030:  c0a8 813b 0000 0000 0000 0000
>> 22:51:25.314742 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29415,
>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
>> 0,nop,wscale 2>
>>         0x0000:  4510 003c 72e7 4000 3c06 cea6 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>>         0x0030:  ff21 ebbf 0000 0000 0103 0302
>> 22:51:25.314881 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  59, id 29415,
>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
>> 0,nop,wscale 2>
>>         0x0000:  4510 003c 72e7 4000 3b06 cfa6 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>>         0x0030:  ff21 ebbf 0000 0000 0103 0302
>> 22:51:25.317031 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29416,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct),
>> 3079051832:3079051832(0) ack 64737525 win 1460 <nop,nop,timestamp 4280413119
>> 789674283>
>>         0x0000:  4510 0034 72e8 4000 3c06 cead ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>>         0x0030:  2f11 792b
>> 22:51:25.317105 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29416,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct), 0:0(0) ack 1
>> win 1460 <nop,nop,timestamp 4280413119 789674283>
>>         0x0000:  4510 0034 72e8 4000 3b06 cfad ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>>         0x0030:  2f11 792b
>> 22:51:30.998908 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  60, id 29417,
>> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
>> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>>         0x0000:  4510 0044 72e9 4000 3c06 ce9c ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>>         0x0040:  2e30 0d0a
>> 22:51:30.999020 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  59, id 29417,
>> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
>> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>>         0x0000:  4510 0044 72e9 4000 3b06 cf9c ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>>         0x0040:  2e30 0d0a
>> 22:51:31.980478 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  60, id 29418,
>> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
>> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>>         0x0000:  4510 0036 72ea 4000 3c06 cea9 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>>         0x0030:  2f11 7b63 0d0a
>> 22:51:31.980600 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  59, id 29418,
>> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
>> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>>         0x0000:  4510 0036 72ea 4000 3b06 cfa9 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>>         0x0030:  2f11 7b63 0d0a
>> 22:51:31.983665 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29419,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
>> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>         0x0000:  4510 0034 72eb 4000 3c06 ceaa ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>>         0x0030:  2f11 7bc6
>> 22:51:31.983724 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29419,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
>> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>         0x0000:  4510 0034 72eb 4000 3b06 cfaa ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>>         0x0030:  2f11 7bc6
>> 22:51:31.985257 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29420,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
>> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>         0x0000:  4510 0034 72ec 4000 3c06 cea9 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>>         0x0030:  2f11 7bc6
>> 22:51:31.985292 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29420,
>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
>> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>         0x0000:  4510 0034 72ec 4000 3b06 cfa9 ab40 0ff7
>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>>         0x0030:  2f11 7bc6
>>
>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: VNS server "reservehost failed" error
Date: Sat, 3 Feb 2007 01:57:18 -0800
Lines: 43
Distribution: su
Message-ID: <eq1m9v$sme$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170496639 29390 127.0.0.1 (3 Feb 2007 09:57:19 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11404

Any idea why I'm getting the following error? I don't see anyone else using 
this topology.

>> ./sr -t 216 -s vns-1.stanford.edu -l tcpdump.pcap
Loading routing table
---------------------------------------------
Destination     Gateway         Mask    Iface
192.168.129.60          192.168.129.60  255.255.255.255 eth1
192.168.129.62          192.168.129.62  255.255.255.255 eth2
0.0.0.0         172.24.74.17    0.0.0.0 eth0
---------------------------------------------
Client riju connecting to Server vns-1.stanford.edu:12345
Requesting topology 216
VNS server closed session.
Reason: reservehost failed
 `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
 Make sure you are using the right topology
      ./sr -t <topoid>

 You can also check that another router isn't already
 on your topology at: http://vns-1.stanford.edu/summary
 `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~

Followig are the log messages from http://vns-1.stanford.edu/log

INFO: Sat Feb  3 01:16:23 2007  selectserver: new connection
INFO: Sat Feb  3 01:16:23 2007  INFO: Sat Feb  3 01:16:23 2007  remote ip = 
171.64.15.226
INFO: Sat Feb  3 01:16:23 2007  Number of connected clients = 5
INFO: Sat Feb  3 01:16:23 2007  OPEN VNSCommand received from client
INFO: Sat Feb  3 01:16:23 2007  VNSCommand says UID = riju and host = vrhost 
and topology = 216
INFO: Sat Feb  3 01:16:23 2007  ReserveHost is being called. Trying..
 ERR: Sat Feb  3 01:16:23 2007  ReserveHost failed for user riju on topology 
216
Shutting socket number 27 which connects to host with IP 171.64.15.226
INFO: Sat Feb  3 01:16:23 2007  Shutting down GRACEFULLY router with socket 
= 27
and which is connected to 171.64.15.226
the message being sent is reservehost failed
INFO: Sat Feb  3 01:16:23 2007  Router client successfully shut down 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: VNS server "reservehost failed" error
Date: Sat, 3 Feb 2007 02:18:39 -0800
Lines: 48
Distribution: su
Message-ID: <eq1ni3$98$1@news.Stanford.EDU>
References: <eq1m9v$sme$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170497923 296 127.0.0.1 (3 Feb 2007 10:18:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11405

Never mind... It's working now

"Riju Kallivalappil" <riju@stanford.edu> wrote in message 
news:eq1m9v$sme$1@news.Stanford.EDU...
> Any idea why I'm getting the following error? I don't see anyone else 
> using this topology.
>
>>> ./sr -t 216 -s vns-1.stanford.edu -l tcpdump.pcap
> Loading routing table
> ---------------------------------------------
> Destination     Gateway         Mask    Iface
> 192.168.129.60          192.168.129.60  255.255.255.255 eth1
> 192.168.129.62          192.168.129.62  255.255.255.255 eth2
> 0.0.0.0         172.24.74.17    0.0.0.0 eth0
> ---------------------------------------------
> Client riju connecting to Server vns-1.stanford.edu:12345
> Requesting topology 216
> VNS server closed session.
> Reason: reservehost failed
> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
> Make sure you are using the right topology
>      ./sr -t <topoid>
>
> You can also check that another router isn't already
> on your topology at: http://vns-1.stanford.edu/summary
> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
>
> Followig are the log messages from http://vns-1.stanford.edu/log
>
> INFO: Sat Feb  3 01:16:23 2007  selectserver: new connection
> INFO: Sat Feb  3 01:16:23 2007  INFO: Sat Feb  3 01:16:23 2007  remote ip 
> = 171.64.15.226
> INFO: Sat Feb  3 01:16:23 2007  Number of connected clients = 5
> INFO: Sat Feb  3 01:16:23 2007  OPEN VNSCommand received from client
> INFO: Sat Feb  3 01:16:23 2007  VNSCommand says UID = riju and host = 
> vrhost and topology = 216
> INFO: Sat Feb  3 01:16:23 2007  ReserveHost is being called. Trying..
> ERR: Sat Feb  3 01:16:23 2007  ReserveHost failed for user riju on 
> topology 216
> Shutting socket number 27 which connects to host with IP 171.64.15.226
> INFO: Sat Feb  3 01:16:23 2007  Shutting down GRACEFULLY router with 
> socket = 27
> and which is connected to 171.64.15.226
> the message being sent is reservehost failed
> INFO: Sat Feb  3 01:16:23 2007  Router client successfully shut down
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: VNS server "reservehost failed" error
Date: Sat, 03 Feb 2007 02:45:29 -0800
Lines: 58
Distribution: su
Message-ID: <eq1p3u$14e$1@news.Stanford.EDU>
References: <eq1m9v$sme$1@news.Stanford.EDU> <eq1ni3$98$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170499518 1166 128.12.194.72 (3 Feb 2007 10:45:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq1ni3$98$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11406

For future reference, that's the error I see when I leave my router code 
running in the background and then try to run it again.

-Yangfan

Riju Kallivalappil wrote:
> Never mind... It's working now
> 
> "Riju Kallivalappil" <riju@stanford.edu> wrote in message 
> news:eq1m9v$sme$1@news.Stanford.EDU...
> 
>>Any idea why I'm getting the following error? I don't see anyone else 
>>using this topology.
>>
>>
>>>>./sr -t 216 -s vns-1.stanford.edu -l tcpdump.pcap
>>
>>Loading routing table
>>---------------------------------------------
>>Destination     Gateway         Mask    Iface
>>192.168.129.60          192.168.129.60  255.255.255.255 eth1
>>192.168.129.62          192.168.129.62  255.255.255.255 eth2
>>0.0.0.0         172.24.74.17    0.0.0.0 eth0
>>---------------------------------------------
>>Client riju connecting to Server vns-1.stanford.edu:12345
>>Requesting topology 216
>>VNS server closed session.
>>Reason: reservehost failed
>>`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
>>Make sure you are using the right topology
>>     ./sr -t <topoid>
>>
>>You can also check that another router isn't already
>>on your topology at: http://vns-1.stanford.edu/summary
>>`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
>>
>>Followig are the log messages from http://vns-1.stanford.edu/log
>>
>>INFO: Sat Feb  3 01:16:23 2007  selectserver: new connection
>>INFO: Sat Feb  3 01:16:23 2007  INFO: Sat Feb  3 01:16:23 2007  remote ip 
>>= 171.64.15.226
>>INFO: Sat Feb  3 01:16:23 2007  Number of connected clients = 5
>>INFO: Sat Feb  3 01:16:23 2007  OPEN VNSCommand received from client
>>INFO: Sat Feb  3 01:16:23 2007  VNSCommand says UID = riju and host = 
>>vrhost and topology = 216
>>INFO: Sat Feb  3 01:16:23 2007  ReserveHost is being called. Trying..
>>ERR: Sat Feb  3 01:16:23 2007  ReserveHost failed for user riju on 
>>topology 216
>>Shutting socket number 27 which connects to host with IP 171.64.15.226
>>INFO: Sat Feb  3 01:16:23 2007  Shutting down GRACEFULLY router with 
>>socket = 27
>>and which is connected to 171.64.15.226
>>the message being sent is reservehost failed
>>INFO: Sat Feb  3 01:16:23 2007  Router client successfully shut down
>>
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ICMP Net unreachable
Date: Sat, 3 Feb 2007 09:57:23 -0800
Lines: 38
Distribution: su
Message-ID: <eq2ip3$n91$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170525795 23841 127.0.0.1 (3 Feb 2007 18:03:15 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11407

From the FAQ:
//-----------------------------------(Man, it would be nice to do that in 
the code!)
What types of ICMP messages do I have to generate

You should support the following:

* Host unreachable (if no host replies to arp requests on the local 
networks)
* Port unreachable (if router receives a TCP or UDP packet addressed to one 
of its interfaces.
* Timeout (TTL of the arriving packet is one or zero)
* ICMP Echo reply (on receipt of an ICMP echo request to one of the router's 
interfaces)

All other ICMP message that you receive you can ignore, however you should 
forward any icmp message that is not for the virtual router itself.
//-----------------------------------

If we are going to send an ICMP message if the destination network is not in 
our routing table, I would think we should send
* Net unreachable
However, that is not listed above.  Are we supposed to send an ICMP message 
if the destination is not in our routing table?  Or should we lie and say
* Host unreachable
?

I guess it is not listed in required functionality.

Then, is it okay if I do it?  (Yes, I know I was up in arms about the 
protocol unreachable.  That would also be easy to do.)

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing of reply packets
Date: Sat, 03 Feb 2007 11:30:15 -0800
Lines: 216
Distribution: su
Message-ID: <C1EA22C7.80FD%jpettit@stanford.edu>
References: <epuocq$se3$1@news.Stanford.EDU> <C1E957CC.80CD%jpettit@stanford.edu> <eq1ess$koq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170531019 28280 127.0.0.1 (3 Feb 2007 19:30:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Routing of reply packets
Thread-Index: AcdHybq4+SLcgbO8EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11408

I spoke with Clay, and he said that there may be a problem with backroutes
not getting installed correctly on the application servers when the
topologies were put in place.  He said that if there is a problem, he should
have it fixed by this afternoon.  Here's what he had to say on the issue:

------------------
All that's happening is that the application servers are
routing reply packets directly through the gateway instead of sending
them through the virtual router because something about the policy
route is broken.  It shouldn't really effect anyone's ability to get
things done- if they're doing it correctly going from the outside
world to the application servers, the reverse should be no problem.
------------------

Sorry about any inconvenience this caused!

--Justin


On 2/2/07 11:51 PM, in article eq1ess$koq$1@news.Stanford.EDU, "Greg Nelson"
<grourk@stanford.edu> wrote:

> I'm having the same issue.  Even when I watch in Clack, packets are
> being sent through my router _to_ the application server but not _from_
> the application server back to the client; however, the client is
> receiving packets.  Are the application servers configured to send
> traffic back on a different route or something?
> 
> Greg
> 
> Justin Pettit wrote:
>> The packets shouldn't be routed through a different path.  As Paul discussed
>> in today's review section, you may want to play with Clack:
>> 
>>     http://www.clackrouter.net/
>> 
>> You can tell it to load your topology and see how it routes the traffic.
>> Your router should behave in essentially the same manner.
>> 
>> --Justin
>> 
>> 
>> On 2/1/07 11:14 PM, in article epuocq$se3$1@news.Stanford.EDU, "Riju
>> Kallivalappil" <riju@stanford.edu> wrote:
>> 
>>> When I connect to one of the application servers in my topology through my
>>> router, are the packets returned by the application server routed through a
>>> different path? I don't see any of the packets from the application servers
>>> going through my code. But, I can access the website on the application
>>> server without a problem.
>>> 
>>> The tcpdump output is given below
>>> 
>>> 
>>> reading from file tcpdump.pcap, link-type EN10MB (Ethernet)
>>> 22:51:22.320859 00:e0:81:04:26:d9 (oui Unknown) > Broadcast, ethertype ARP
>>> (0x0806), length 60: arp who-has aradia-router-3.Stanford.EDU tell
>>> vns-firewall.Stanford.EDU
>>>         0x0000:  0001 0800 0604 0001 00e0 8104 26d9 ac18
>>>         0x0010:  4a11 0000 0000 0000 c0a8 813a 0000 0000
>>>         0x0020:  0000 0000 0000 0000 0000 0000 0000
>>> 22:51:22.320994 70:00:00:d8:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui
>>> Unknown), ethertype ARP (0x0806), length 42: arp reply
>>> aradia-router-3.Stanford.EDU is-at 70:00:00:d8:00:01 (oui Unknown)
>>>         0x0000:  0001 0800 0604 0002 7000 00d8 0001 c0a8
>>>         0x0010:  813a 00e0 8104 26d9 ac18 4a11
>>> 22:51:22.322648 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29414,
>>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x586e (correct),
>>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280412369
>>> 0,nop,wscale 2>
>>>         0x0000:  4510 003c 72e6 4000 3c06 cea7 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>>         0x0020:  a002 16d0 586e 0000 0204 05b4 0402 080a
>>>         0x0030:  ff21 e8d1 0000 0000 0103 0302
>>> 22:51:22.322699 70:00:00:d8:00:06 (oui Unknown) > Broadcast, ethertype ARP
>>> (0x0806), length 42: arp who-has aseems-router-3.Stanford.EDU tell
>>> ftp-arethusa.Stanford.EDU
>>>         0x0000:  0001 0800 0604 0001 7000 00d8 0006 c0a8
>>>         0x0010:  813d 0000 0000 0000 c0a8 813e
>>> 22:51:22.324343 00:04:75:7b:e9:22 (oui Unknown) > 70:00:00:d8:00:06 (oui
>>> Unknown), ethertype ARP (0x0806), length 60: arp reply
>>> aseems-router-3.Stanford.EDU is-at 00:04:75:7b:e9:22 (oui Unknown)
>>>         0x0000:  0001 0800 0604 0002 0004 757b e922 c0a8
>>>         0x0010:  813e 7000 00d8 0006 c0a8 813d 0000 0000
>>>         0x0020:  0000 0000 0000 0000 0000 0000 0000
>>> 22:51:22.324376 70:00:00:d8:00:06 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 74: IP3 truncated-ip - 62267 bytes
>>> missing! (tos 0x59,ECT(1), id 14425, offset 39864, flags [+, DF, rsvd],
>>> proto: Options (0), length: 62327, options ( EOL (0) len 1 ), bad cksum 20
>>> (->3783)!) 112.0.0.216 > 0.2.0.0: ip
>>>         0x0000:  3859 f377 3859 f377 0000 0020 7000 00d8
>>>         0x0010:  0002 0000 0000 0000 0000 0000 0000 0000
>>>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0040
>>>         0x0030:  c0a8 813b 0000 0000 0000 0000
>>> 22:51:25.314742 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  60, id 29415,
>>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
>>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
>>> 0,nop,wscale 2>
>>>         0x0000:  4510 003c 72e7 4000 3c06 cea6 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>>>         0x0030:  ff21 ebbf 0000 0000 0103 0302
>>> 22:51:25.314881 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl  59, id 29415,
>>> offset 0, flags [DF], proto: TCP (6), length: 60) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: S, cksum 0x5580 (correct),
>>> 3079051831:3079051831(0) win 5840 <mss 1460,sackOK,timestamp 4280413119
>>> 0,nop,wscale 2>
>>>         0x0000:  4510 003c 72e7 4000 3b06 cfa6 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a37 0000 0000
>>>         0x0020:  a002 16d0 5580 0000 0204 05b4 0402 080a
>>>         0x0030:  ff21 ebbf 0000 0000 0103 0302
>>> 22:51:25.317031 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29416,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct),
>>> 3079051832:3079051832(0) ack 64737525 win 1460 <nop,nop,timestamp 4280413119
>>> 789674283>
>>>         0x0000:  4510 0034 72e8 4000 3c06 cead ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>>>         0x0030:  2f11 792b
>>> 22:51:25.317105 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29416,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x1846 (correct), 0:0(0) ack 1
>>> win 1460 <nop,nop,timestamp 4280413119 789674283>
>>>         0x0000:  4510 0034 72e8 4000 3b06 cfad ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>>         0x0020:  8010 05b4 1846 0000 0101 080a ff21 ebbf
>>>         0x0030:  2f11 792b
>>> 22:51:30.998908 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  60, id 29417,
>>> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
>>> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>>>         0x0000:  4510 0044 72e9 4000 3c06 ce9c ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>>>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>>>         0x0040:  2e30 0d0a
>>> 22:51:30.999020 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 82: (tos 0x10, ttl  59, id 29417,
>>> offset 0, flags [DF], proto: TCP (6), length: 68) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x410b (correct), 0:16(16) ack
>>> 1 win 1460 <nop,nop,timestamp 4280414540 789674283>
>>>         0x0000:  4510 0044 72e9 4000 3b06 cf9c ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a38 03db d0f5
>>>         0x0020:  8018 05b4 410b 0000 0101 080a ff21 f14c
>>>         0x0030:  2f11 792b 4745 5420 2f20 4854 5450 2f31
>>>         0x0040:  2e30 0d0a
>>> 22:51:31.980478 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  60, id 29418,
>>> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
>>> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>>>         0x0000:  4510 0036 72ea 4000 3c06 cea9 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>>>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>>>         0x0030:  2f11 7b63 0d0a
>>> 22:51:31.980600 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl  59, id 29418,
>>> offset 0, flags [DF], proto: TCP (6), length: 54) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: P, cksum 0x0268 (correct), 16:18(2) ack
>>> 1 win 1460 <nop,nop,timestamp 4280414785 789674851>
>>>         0x0000:  4510 0036 72ea 4000 3b06 cfa9 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a48 03db d0f5
>>>         0x0020:  8018 05b4 0268 0000 0101 080a ff21 f241
>>>         0x0030:  2f11 7b63 0d0a
>>> 22:51:31.983665 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29419,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
>>> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>>         0x0000:  4510 0034 72eb 4000 3c06 ceaa ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>>>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>>>         0x0030:  2f11 7bc6
>>> 22:51:31.983724 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29419,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: ., cksum 0x0b62 (correct), 18:18(0) ack
>>> 633 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>>         0x0000:  4510 0034 72eb 4000 3b06 cfaa ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36d
>>>         0x0020:  8010 06f0 0b62 0000 0101 080a ff21 f242
>>>         0x0030:  2f11 7bc6
>>> 22:51:31.985257 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:d8:00:01 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  60, id 29420,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
>>> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>>         0x0000:  4510 0034 72ec 4000 3c06 cea9 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>>>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>>>         0x0030:  2f11 7bc6
>>> 22:51:31.985292 70:00:00:d8:00:01 (oui Unknown) > 00:04:75:7b:e9:22 (oui
>>> Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x10, ttl  59, id 29420,
>>> offset 0, flags [DF], proto: TCP (6), length: 52) vine10.Stanford.EDU.41382
>>>> aseems-router-3.Stanford.EDU.www: F, cksum 0x0b60 (correct), 18:18(0) ack
>>> 634 win 1776 <nop,nop,timestamp 4280414786 789674950>
>>>         0x0000:  4510 0034 72ec 4000 3b06 cfa9 ab40 0ff7
>>>         0x0010:  c0a8 813e a1a6 0050 b786 9a4a 03db d36e
>>>         0x0020:  8011 06f0 0b60 0000 0101 080a ff21 f242
>>>         0x0030:  2f11 7bc6
>>> 
>>> 
>>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Matt Page" <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ARP Queue timeouts
Date: Sat, 3 Feb 2007 12:40:30 -0800
Lines: 17
Distribution: su
Message-ID: <eq2rvu$1a6$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
X-Trace: news.Stanford.EDU 1170535230 1350 128.12.104.45 (3 Feb 2007 20:40:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11409

Regarding how many packets we should send before we send a "host unreachable 
message,"

What if we have two packets arriving roughly 2 seconds apart destined for 
the same unreachable host?
The first packet will spawn 5 ARP requests, while, according to the 
documentation, the second packet
will spawn an additional 2 ARP requests. (They both generate 5 ARP requests 
with the latter 3 of the first request overlapping with the first 3 of the 
second request.) This will generate 2 host unreachable messages. Is this the 
correct
behavior?

Thanks,
Matt 


.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Make error
Date: Sat, 3 Feb 2007 20:50:29 +0000 (UTC)
Lines: 7
Distribution: su
Message-ID: <eq2sil$1he$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine3.stanford.edu
X-Trace: news.Stanford.EDU 1170535829 1582 171.64.15.68 (3 Feb 2007 20:50:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:11410


Hi,
  I was running the code on elaine and it worked fine. However when I try running make on myth I get the error:
make: *** No rule to make target `/usr/include/sys/int_types.h', needed by `sr_router.o'.  Stop.

What could be wrong?

.

Path: shelby.stanford.edu!myth26.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [PA2] Req 7 clarification?
Date: Sat, 3 Feb 2007 12:57:43 -0800
Lines: 19
Distribution: su
Message-ID: <Pine.LNX.4.44.0702031251520.19595-100000@myth26.Stanford.EDU>
NNTP-Posting-Host: myth26.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170536265 2051 171.64.15.41 (3 Feb 2007 20:57:45 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11411

Hi, I am a little confused about requirement 7 in "Required Functionality"
that says:

The router queues all packets waiting for outstanding ARP replies. If a
host does not respond to 5 ARP requests, the queued packet is dropped and
an ICMP host unreachable message is sent back to the source of the queued
packet.

Is it saying say A is my router, and B is say Application 1, C is
someone who tries to send a packet to B, and that my router A
needs to implement a queue that queues ARP requests packets from C (that
are
supposed to go to B), and now I will try to send ARP request to B 5 times,
if after 5 times, in which each I waited 15 seconds, and there is still no
SINGLE ARP reply from B, then after this 75 seconds, I shall send an ICMP
unreachable back to the C?

If the TA can clarify, that will be great. Thanks.

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: interface netmask
Date: Sat, 3 Feb 2007 14:24:07 -0800
Lines: 11
Distribution: su
Message-ID: <eq320p$64f$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170541401 6287 127.0.0.1 (3 Feb 2007 22:23:21 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11412

Erm... Is there any way to get the netmask on the sr_if?  I would like to 
know if someone sent me a valid ARP.  Seems like that is a standard thing 
for an interface to know...

Sincerely,
Randy Jennings

The squirrels are your friends!



.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PA2
Date: Sun, 4 Feb 2007 01:44:32 +0000 (UTC)
Lines: 6
Distribution: su
Message-ID: <eq3dq0$eup$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170553472 15321 171.64.15.42 (4 Feb 2007 01:44:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11413

Hi,

Is there any prize this time for PA2 who submits first?

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Brief Downtime
Date: Sat, 03 Feb 2007 18:01:02 -0800
Lines: 9
Distribution: su
Message-ID: <eq3f21$fkn$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170554754 16023 171.64.74.54 (4 Feb 2007 02:05:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11414

Hi folks-

Your topologies may be intermittently unavailable for the next 45-60 
minutes while I fix the backrouting issue that was reported earlier 
(reply packets from the application servers were being routed directly 
to the gateway instead of going back through the router).  I'll post 
another update once I've run the fix and finished testing.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on echo replies.
Date: Sat, 03 Feb 2007 18:22:07 -0800
Lines: 30
Distribution: su
Message-ID: <eq3g06$g92$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170555718 16674 128.12.194.72 (4 Feb 2007 02:21:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11415

My echo replies are not being recognized by the ping program. Could the 
TAs see what's wrong? Are they too short or something?

The request:

18:15:14.726539 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:e5:00:01 (oui 
Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  62, id 0, 
offset 0, flags [DF], proto: ICMP (1), length: 84) myth29.Stanford.EDU > 
ftp-kash.Stanford.EDU: ICMP echo request, id 64534, seq 0, length 64
         0x0000:  7000 00e5 0001 00e0 8104 26d9 0800 4500
         0x0010:  0054 0000 4000 3e01 4019 ab40 0f2c c0a8
         0x0020:  817b 0800 6951 fc16 0000 b241 c545 250d
         0x0030:  0b00 0809 0a0b 0c0d 0e0f 1011 1213 1415
         0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
         0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
         0x0060:  3637

And the reply:

18:15:14.726576 70:00:00:e5:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui 
Unknown), ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl  65, id 0, 
offset 0, flags [DF], proto: ICMP (1), length: 56) ftp-kash.Stanford.EDU 
 > myth29.Stanford.EDU: ICMP echo reply, id 0, seq 0, length 36
         0x0000:  00e0 8104 26d9 7000 00e5 0001 0800 4500
         0x0010:  0038 0000 4000 4101 3d35 c0a8 817b ab40
         0x0020:  0f2c 0000 9297 0000 0000 4500 0054 0000
         0x0030:  4000 3e01 4019 ab40 0f2c c0a8 817b 0800
         0x0040:  6951 fc16 0000

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on TTL.
Date: Sat, 03 Feb 2007 18:38:30 -0800
Lines: 3
Distribution: su
Message-ID: <eq3gus$h2b$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170556700 17483 128.12.194.72 (4 Feb 2007 02:38:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11416

If the TTL of the incoming packet is 1, should I drop it?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Brief Downtime
Date: Sat, 03 Feb 2007 19:41:53 -0800
Lines: 13
Distribution: su
Message-ID: <eq3kv5$jlc$1@news.Stanford.EDU>
References: <eq3f21$fkn$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170560807 20140 171.64.74.54 (4 Feb 2007 03:46:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eq3f21$fkn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11417

Topologies will continue to be out for another 20 minutes or so.

Clay
Clay Collier wrote:
> Hi folks-
> 
> Your topologies may be intermittently unavailable for the next 45-60 
> minutes while I fix the backrouting issue that was reported earlier 
> (reply packets from the application servers were being routed directly 
> to the gateway instead of going back through the router).  I'll post 
> another update once I've run the fix and finished testing.
> 
> Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on echo replies.
Date: Sat, 3 Feb 2007 20:10:43 -0800
Lines: 42
Distribution: su
Message-ID: <eq3mao$khu$1@news.Stanford.EDU>
References: <eq3g06$g92$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170562200 21054 127.0.0.1 (4 Feb 2007 04:10:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11418

You are garbling the data at the end.  An echo response needs to return the 
exact same data (everything after checksum) of the echo request.  (Hence the 
name echo.)

Sincerely,
Randy Jennings

The squirrels are your friends!
"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eq3g06$g92$1@news.Stanford.EDU...
> My echo replies are not being recognized by the ping program. Could the 
> TAs see what's wrong? Are they too short or something?
>
> The request:
>
> 18:15:14.726539 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:e5:00:01 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  62, id 0, 
> offset 0, flags [DF], proto: ICMP (1), length: 84) myth29.Stanford.EDU > 
> ftp-kash.Stanford.EDU: ICMP echo request, id 64534, seq 0, length 64
>         0x0000:  7000 00e5 0001 00e0 8104 26d9 0800 4500
>         0x0010:  0054 0000 4000 3e01 4019 ab40 0f2c c0a8
>         0x0020:  817b 0800 6951 fc16 0000 b241 c545 250d
>         0x0030:  0b00 0809 0a0b 0c0d 0e0f 1011 1213 1415
>         0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
>         0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
>         0x0060:  3637
>
> And the reply:
>
> 18:15:14.726576 70:00:00:e5:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui 
> Unknown), ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl  65, id 0, 
> offset 0, flags [DF], proto: ICMP (1), length: 56) ftp-kash.Stanford.EDU
> > myth29.Stanford.EDU: ICMP echo reply, id 0, seq 0, length 36
>         0x0000:  00e0 8104 26d9 7000 00e5 0001 0800 4500
>         0x0010:  0038 0000 4000 4101 3d35 c0a8 817b ab40
>         0x0020:  0f2c 0000 9297 0000 0000 4500 0054 0000
>         0x0030:  4000 3e01 4019 ab40 0f2c c0a8 817b 0800
>         0x0040:  6951 fc16 0000
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Brief Downtime
Date: Sat, 03 Feb 2007 21:51:47 -0800
Lines: 23
Distribution: su
Message-ID: <C1EAB473.8111%jpettit@stanford.edu>
References: <eq3f21$fkn$1@news.Stanford.EDU> <eq3kv5$jlc$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170568308 24780 127.0.0.1 (4 Feb 2007 05:51:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Brief Downtime
Thread-Index: AcdIII58zTx0x7QTEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11419

Thanks, Clay!  I really appreciate you taking care of this.

--Justin


On 2/3/07 7:41 PM, in article eq3kv5$jlc$1@news.Stanford.EDU, "Clay Collier"
<ccollier@stanford.edu> wrote:

> Topologies will continue to be out for another 20 minutes or so.
> 
> Clay
> Clay Collier wrote:
>> Hi folks-
>> 
>> Your topologies may be intermittently unavailable for the next 45-60
>> minutes while I fix the backrouting issue that was reported earlier
>> (reply packets from the application servers were being routed directly
>> to the gateway instead of going back through the router).  I'll post
>> another update once I've run the fix and finished testing.
>> 
>> Clay


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Brief Downtime
Date: Sat, 03 Feb 2007 21:50:33 -0800
Lines: 5
Distribution: su
Message-ID: <eq3sge$o7h$1@news.Stanford.EDU>
References: <eq3f21$fkn$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170568528 24817 171.64.74.54 (4 Feb 2007 05:55:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eq3f21$fkn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11420

Topologies should be back up.  I will probably need to take things down 
for a little bit to finalize the routing fix, but I'll try and schedule 
that for later tonight when people are off the system.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on echo replies.
Date: Sat, 03 Feb 2007 22:11:08 -0800
Lines: 56
Distribution: su
Message-ID: <eq3tdv$oub$1@news.Stanford.EDU>
References: <eq3g06$g92$1@news.Stanford.EDU> <eq3mao$khu$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170569472 25547 128.12.194.72 (4 Feb 2007 06:11:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq3mao$khu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11421

Ah I see. In other words, it doesn't follow the normal rules of an ICMP 
packet. Of course. How obvious. >_<

*smacks head against wall*

Thank you Randy.

-Yangfan

Randy Jennings wrote:
> You are garbling the data at the end.  An echo response needs to return the 
> exact same data (everything after checksum) of the echo request.  (Hence the 
> name echo.)
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:eq3g06$g92$1@news.Stanford.EDU...
> 
>>My echo replies are not being recognized by the ping program. Could the 
>>TAs see what's wrong? Are they too short or something?
>>
>>The request:
>>
>>18:15:14.726539 00:e0:81:04:26:d9 (oui Unknown) > 70:00:00:e5:00:01 (oui 
>>Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  62, id 0, 
>>offset 0, flags [DF], proto: ICMP (1), length: 84) myth29.Stanford.EDU > 
>>ftp-kash.Stanford.EDU: ICMP echo request, id 64534, seq 0, length 64
>>        0x0000:  7000 00e5 0001 00e0 8104 26d9 0800 4500
>>        0x0010:  0054 0000 4000 3e01 4019 ab40 0f2c c0a8
>>        0x0020:  817b 0800 6951 fc16 0000 b241 c545 250d
>>        0x0030:  0b00 0809 0a0b 0c0d 0e0f 1011 1213 1415
>>        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
>>        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
>>        0x0060:  3637
>>
>>And the reply:
>>
>>18:15:14.726576 70:00:00:e5:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui 
>>Unknown), ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl  65, id 0, 
>>offset 0, flags [DF], proto: ICMP (1), length: 56) ftp-kash.Stanford.EDU
>>
>>>myth29.Stanford.EDU: ICMP echo reply, id 0, seq 0, length 36
>>
>>        0x0000:  00e0 8104 26d9 7000 00e5 0001 0800 4500
>>        0x0010:  0038 0000 4000 4101 3d35 c0a8 817b ab40
>>        0x0020:  0f2c 0000 9297 0000 0000 4500 0054 0000
>>        0x0030:  4000 3e01 4019 ab40 0f2c c0a8 817b 0800
>>        0x0040:  6951 fc16 0000
>>
>>-Yangfan 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing of reply packets
Date: Sun, 04 Feb 2007 02:16:09 -0800
Lines: 3
Distribution: su
Message-ID: <eq4c2g$8mc$1@news.Stanford.EDU>
References: <epuocq$se3$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170584464 8908 171.64.74.54 (4 Feb 2007 10:21:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <epuocq$se3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11422

Reply packet routing should now be fixed for all of the topologies.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Assignment Submission
Date: Sun, 04 Feb 2007 02:25:52 -0800
Lines: 21
Distribution: su
Message-ID: <eq4ckq$9ag$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170585050 9552 171.64.74.54 (4 Feb 2007 10:30:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11423

Just a heads up to everyone- as was mentioned in section earlier, we had 
a few problems last time with folks submitting their programming 
assignments using the wrong format, or missing parts of the submission 
instructions.

Just to reiterate:

1) Send us a gzipped tar file.
2) Said gzipped tar file should contain all your source code and the 
assignment README.
3) Please don't include object files (.o's, a.out, binaries) in your tar 
file.
4) The Makefile includes a target ('make dist' for this assignment) to 
create a properly formatted file.  You will need to add your README and 
any new source files you create to the appropriate place in the Makefile.

The submit script will be checking to make sure that your submitted file 
appears to be in the correct format from now on- make sure you're not 
scrambling to figure out how to submit at 4:58 on Friday!

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on TTL.
Date: Sun, 4 Feb 2007 15:23:41 -0800
Lines: 14
Distribution: su
Message-ID: <eq5pu3$ed1$1@news.Stanford.EDU>
References: <eq3gus$h2b$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170631427 14753 128.12.81.44 (4 Feb 2007 23:23:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11424

Hi Yangfan,

The FAQ says to generate an ICMP timeout if the TTL of the arriving packet 
is one or zero.

David Gobaud

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eq3gus$h2b$1@news.Stanford.EDU...
> If the TTL of the incoming packet is 1, should I drop it?
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem Set 1 Solutions Posted
Date: Sun, 04 Feb 2007 15:38:27 -0800
Lines: 9
Distribution: su
Message-ID: <C1EBAE73.8129%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170632311 15951 127.0.0.1 (4 Feb 2007 23:38:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Problem Set 1 Solutions Posted
Thread-Index: AcdItZF1z78avLSoEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11425

The solutions to the first problem set have been put up on the timetable
page.  Here's a direct link if you need it:

http://www.stanford.edu/class/cs244a/problem_set/problem_set1_win07_soln.pdf

We should provide a speedier turn around next time.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Global variables
Date: Sun, 04 Feb 2007 18:45:12 -0800
Lines: 4
Distribution: su
Message-ID: <eq65nc$n38$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170643501 23656 127.0.0.1 (5 Feb 2007 02:45:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11426

Is the use of global variables allowed?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Implementation of timeouts
Date: Sun, 04 Feb 2007 19:55:01 -0800
Lines: 10
Distribution: su
Message-ID: <eq69q9$ppv$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170647689 26431 127.0.0.1 (5 Feb 2007 03:54:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11427

Hi,

I would like to implement the cache timeouts using 
signals/alarm-handlers. So for that I wanted to know whether I can
maintain a global pointer to the sr_instance passed to us?
Just want to make sure that using global variables is fine as in PA1 it
was explicitly mentioned otherwise.

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: README format
Date: Sun, 4 Feb 2007 23:38:31 -0700
Lines: 7
Distribution: su
Message-ID: <eq6jd8$319$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170657512 3113 127.0.0.1 (5 Feb 2007 06:38:32 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11428

A picture is worth 1,000 words.  For the README, is it okay to submit a pdf 
file (containing diagrams as well as explanation) instead of a text file?

Thanks,
Kevin 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ICMP Packet forwarding errors
Date: Mon, 5 Feb 2007 00:21:40 -0800
Lines: 24
Distribution: su
Message-ID: <eq6pel$b18$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170663701 11304 127.0.0.1 (5 Feb 2007 08:21:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11429

Should we send an ICMP error to the sender if we fail to forward an *ICMP* 
packet because of the usual ARP failure?

For example, consider the following scenarios:

Host A talks to Host B through routers R1 and R2. We are R1 in this case.

A <---> R1 <----> R2 <----> B

Scenario 1:
-----------
Host A sends an IP packet to B. R2 fails to forward it to B and responds 
with an ICMP error message.
R1 receives this ICMP packet, but fails to forward this to A, because of 
(say) ARP lookup failures. Should R1 respond to R2 with another ICMP error 
message? I'd guess no.

Scenario 2:
-----------
Host A sends an ICMP ping request to B. R1 fails to forward this to R2 
because of (say) ARP lookup failures. Should R1 respond to A with an ICMP 
error message in this case? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Net unreachable
Date: Mon, 05 Feb 2007 02:10:48 -0800
Lines: 44
Distribution: su
Message-ID: <eq6vrc$eq6$1@news.Stanford.EDU>
References: <eq2ip3$n91$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670252 15174 128.12.133.106 (5 Feb 2007 10:10:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq2ip3$n91$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11430

Please send an ICMP Message if you can't find a match in the routing 
table. Which ICMP Message is up to you. You can justify your decision in 
the README.


Randy Jennings wrote:
> From the FAQ:
> //-----------------------------------(Man, it would be nice to do that in 
> the code!)
> What types of ICMP messages do I have to generate
> 
> You should support the following:
> 
> * Host unreachable (if no host replies to arp requests on the local 
> networks)
> * Port unreachable (if router receives a TCP or UDP packet addressed to one 
> of its interfaces.
> * Timeout (TTL of the arriving packet is one or zero)
> * ICMP Echo reply (on receipt of an ICMP echo request to one of the router's 
> interfaces)
> 
> All other ICMP message that you receive you can ignore, however you should 
> forward any icmp message that is not for the virtual router itself.
> //-----------------------------------
> 
> If we are going to send an ICMP message if the destination network is not in 
> our routing table, I would think we should send
> * Net unreachable
> However, that is not listed above.  Are we supposed to send an ICMP message 
> if the destination is not in our routing table?  Or should we lie and say
> * Host unreachable
> ?
> 
> I guess it is not listed in required functionality.
> 
> Then, is it okay if I do it?  (Yes, I know I was up in arms about the 
> protocol unreachable.  That would also be easy to do.)
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Mon, 05 Feb 2007 02:11:51 -0800
Lines: 21
Distribution: su
Message-ID: <eq6vtc$eq6$2@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670316 15174 128.12.133.106 (5 Feb 2007 10:11:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq2rvu$1a6$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11431

Yes, each packet should be acknowledged (since they might be form 
different hosts or different programs, etc).

Matt Page wrote:
> Regarding how many packets we should send before we send a "host unreachable 
> message,"
> 
> What if we have two packets arriving roughly 2 seconds apart destined for 
> the same unreachable host?
> The first packet will spawn 5 ARP requests, while, according to the 
> documentation, the second packet
> will spawn an additional 2 ARP requests. (They both generate 5 ARP requests 
> with the latter 3 of the first request overlapping with the first 3 of the 
> second request.) This will generate 2 host unreachable messages. Is this the 
> correct
> behavior?
> 
> Thanks,
> Matt 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Make error
Date: Mon, 05 Feb 2007 02:14:29 -0800
Lines: 9
Distribution: su
Message-ID: <eq7029$eq6$3@news.Stanford.EDU>
References: <eq2sil$1he$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670474 15174 128.12.133.106 (5 Feb 2007 10:14:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq2sil$1he$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11432

Try a "make clean-deps" then "make include"

Dina Thomas wrote:
> Hi,
>   I was running the code on elaine and it worked fine. However when I try running make on myth I get the error:
> make: *** No rule to make target `/usr/include/sys/int_types.h', needed by `sr_router.o'.  Stop.
> 
> What could be wrong?
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] Req 7 clarification?
Date: Mon, 05 Feb 2007 02:17:33 -0800
Lines: 25
Distribution: su
Message-ID: <eq7082$eq6$4@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702031251520.19595-100000@myth26.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670658 15174 128.12.133.106 (5 Feb 2007 10:17:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0702031251520.19595-100000@myth26.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11433

You might not want to wait 15 seconds between ARP requests then. I think 
you are confused about the 15 second part. We want you to forget things 
from your ARP table 15 seconds after they were discovered. We DIDN'T 
mean "send ARP requests every 15 seconds".

Ryan Chen wrote:
> Hi, I am a little confused about requirement 7 in "Required Functionality"
> that says:
> 
> The router queues all packets waiting for outstanding ARP replies. If a
> host does not respond to 5 ARP requests, the queued packet is dropped and
> an ICMP host unreachable message is sent back to the source of the queued
> packet.
> 
> Is it saying say A is my router, and B is say Application 1, C is
> someone who tries to send a packet to B, and that my router A
> needs to implement a queue that queues ARP requests packets from C (that
> are
> supposed to go to B), and now I will try to send ARP request to B 5 times,
> if after 5 times, in which each I waited 15 seconds, and there is still no
> SINGLE ARP reply from B, then after this 75 seconds, I shall send an ICMP
> unreachable back to the C?
> 
> If the TA can clarify, that will be great. Thanks.
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: interface netmask
Date: Mon, 05 Feb 2007 02:18:30 -0800
Lines: 14
Distribution: su
Message-ID: <eq709q$eq6$5@news.Stanford.EDU>
References: <eq320p$64f$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670714 15174 128.12.133.106 (5 Feb 2007 10:18:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq320p$64f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11434

Check the struct associated with the information you want.

Randy Jennings wrote:
> Erm... Is there any way to get the netmask on the sr_if?  I would like to 
> know if someone sent me a valid ARP.  Seems like that is a standard thing 
> for an interface to know...
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA2
Date: Mon, 05 Feb 2007 02:18:50 -0800
Lines: 9
Distribution: su
Message-ID: <eq70af$eq6$6@news.Stanford.EDU>
References: <eq3dq0$eup$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670735 15174 128.12.133.106 (5 Feb 2007 10:18:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq3dq0$eup$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11435

Yes, the person who submits first AND gets 100%.

Dinesh Gupta wrote:
> Hi,
> 
> Is there any prize this time for PA2 who submits first?
> 
> Thanks,
> Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Global variables
Date: Mon, 05 Feb 2007 02:20:20 -0800
Lines: 9
Distribution: su
Message-ID: <eq70d9$eq6$7@news.Stanford.EDU>
References: <eq65nc$n38$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170670825 15174 128.12.133.106 (5 Feb 2007 10:20:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq65nc$n38$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11436

Of course everything is allowed, but please follow good programming 
practices. If there is a great reason to have the global, by all means 
put it in, but if it is a hack, you might want to rethink your design.

Neelima Balakrishnan wrote:
> Is the use of global variables allowed?
> 
> Thanks
> Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: README format
Date: Mon, 05 Feb 2007 02:24:48 -0800
Lines: 17
Distribution: su
Message-ID: <eq70lm$fi2$1@news.Stanford.EDU>
References: <eq6jd8$319$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170671094 15938 128.12.133.106 (5 Feb 2007 10:24:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq6jd8$319$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11437

We would prefer a text format since most of us are doing this over a SSH 
shell using a text editor. Please remember that the README is for tough 
design decisions. Last assignment, most people were just explaining the 
basics of how a proxy worked. We know that you know the basics since you 
actually got the proxy to work. The README is for nuances and 
intricacies that you discovered. We all know you had to use the "read()" 
system call to get data from the socket, but the details of your corner 
case handling for the parse function might be interesting.

Kevin Hart wrote:
> A picture is worth 1,000 words.  For the README, is it okay to submit a pdf 
> file (containing diagrams as well as explanation) instead of a text file?
> 
> Thanks,
> Kevin 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Raymond Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Modifying struct sr_instance?
Date: Mon, 05 Feb 2007 03:06:04 -0800
Lines: 8
Distribution: su
Message-ID: <eq732s$hfd$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170673564 17901 127.0.0.1 (5 Feb 2007 11:06:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11438

I think this was answered somewhere earlier, but I forgot where, so I'll 
ask it again:

Are we allowed to modify (specifically: add to) members of the struct 
sr_instance in router.h?

TIA,
Raymond
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Making the threads share memory...
Date: Mon, 05 Feb 2007 03:15:50 -0800
Lines: 12
Distribution: su
Message-ID: <eq73l5$hrp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170674149 18297 128.12.194.72 (5 Feb 2007 11:15:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11439

Okay, even though the pointers are telling me that they point to the 
same address, starting new threads with fork() seems to copy all the 
memory pages as a side effect, if I'm reading the man page correctly. 
This obviously make it impossible for the threads to share data.

Can someone teach me the proper way to use clone()? The man page on 
clone only served to confuse and scare me. :p

Or could the TAs point out a way to share memory among threads generated 
with fork()?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Mon, 05 Feb 2007 03:20:19 -0800
Lines: 16
Distribution: su
Message-ID: <eq73tj$hrp$2@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170674419 18297 128.12.194.72 (5 Feb 2007 11:20:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq73l5$hrp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11440

Yangfan Wang wrote:
> Okay, even though the pointers are telling me that they point to the 
> same address, starting new threads with fork() seems to copy all the 
> memory pages as a side effect, if I'm reading the man page correctly. 
> This obviously make it impossible for the threads to share data.
> 
> Can someone teach me the proper way to use clone()? The man page on 
> clone only served to confuse and scare me. :p
> 
> Or could the TAs point out a way to share memory among threads generated 
> with fork()?
> 

To be more specific, I need the threads to share heap space.

-Yangfan
.

Path: shelby.stanford.edu!myth21.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] Req 7 clarification?
Date: Mon, 5 Feb 2007 10:36:01 -0800
Lines: 32
Distribution: su
Message-ID: <Pine.LNX.4.44.0702051035150.570-100000@myth21.Stanford.EDU>
References: <Pine.LNX.4.44.0702031251520.19595-100000@myth26.Stanford.EDU>
 <eq7082$eq6$4@news.Stanford.EDU>
NNTP-Posting-Host: myth21.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170700563 10101 171.64.15.37 (5 Feb 2007 18:36:03 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <eq7082$eq6$4@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11441

So can you elaborate on the meaning of "5 ARP requests"? What does this
"5" mean?

On Mon, 5 Feb 2007, Paul Tarjan (TA) wrote:

> You might not want to wait 15 seconds between ARP requests then. I think
> you are confused about the 15 second part. We want you to forget things
> from your ARP table 15 seconds after they were discovered. We DIDN'T
> mean "send ARP requests every 15 seconds".
>
> Ryan Chen wrote:
> > Hi, I am a little confused about requirement 7 in "Required Functionality"
> > that says:
> >
> > The router queues all packets waiting for outstanding ARP replies. If a
> > host does not respond to 5 ARP requests, the queued packet is dropped and
> > an ICMP host unreachable message is sent back to the source of the queued
> > packet.
> >
> > Is it saying say A is my router, and B is say Application 1, C is
> > someone who tries to send a packet to B, and that my router A
> > needs to implement a queue that queues ARP requests packets from C (that
> > are
> > supposed to go to B), and now I will try to send ARP request to B 5 times,
> > if after 5 times, in which each I waited 15 seconds, and there is still no
> > SINGLE ARP reply from B, then after this 75 seconds, I shall send an ICMP
> > unreachable back to the C?
> >
> > If the TA can clarify, that will be great. Thanks.
> >
>

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Mon, 5 Feb 2007 10:37:37 -0800
Lines: 22
Distribution: su
Message-ID: <eq7thi$9te$1@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU> <eq73tj$hrp$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170700658 10158 127.0.0.1 (5 Feb 2007 18:37:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11442

Use pthread_create(). fork() creates a new process.

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eq73tj$hrp$2@news.Stanford.EDU...
> Yangfan Wang wrote:
>> Okay, even though the pointers are telling me that they point to the same 
>> address, starting new threads with fork() seems to copy all the memory 
>> pages as a side effect, if I'm reading the man page correctly. This 
>> obviously make it impossible for the threads to share data.
>>
>> Can someone teach me the proper way to use clone()? The man page on clone 
>> only served to confuse and scare me. :p
>>
>> Or could the TAs point out a way to share memory among threads generated 
>> with fork()?
>>
>
> To be more specific, I need the threads to share heap space.
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Modifying struct sr_instance?
Date: Mon, 05 Feb 2007 11:01:51 -0800
Lines: 14
Distribution: su
Message-ID: <eq7uuv$b0c$1@news.Stanford.EDU>
References: <eq732s$hfd$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170702111 11276 127.0.0.1 (5 Feb 2007 19:01:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq732s$hfd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11443

Raymond Thang wrote:
> I think this was answered somewhere earlier, but I forgot where, so I'll 
> ask it again:
> 
> Are we allowed to modify (specifically: add to) members of the struct 
> sr_instance in router.h?
> 
> TIA,
> Raymond

Please see the faq:
http://www.stanford.edu/class/cs244a/2006/homeworks/hw2/faq.html#files_mod

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Packet forwarding errors
Date: Mon, 05 Feb 2007 11:04:57 -0800
Lines: 31
Distribution: su
Message-ID: <eq7v4p$b0c$2@news.Stanford.EDU>
References: <eq6pel$b18$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170702297 11276 127.0.0.1 (5 Feb 2007 19:04:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq6pel$b18$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11444

Riju Kallivalappil wrote:
> Should we send an ICMP error to the sender if we fail to forward an *ICMP* 
> packet because of the usual ARP failure?
> 
> For example, consider the following scenarios:
> 
> Host A talks to Host B through routers R1 and R2. We are R1 in this case.
> 
> A <---> R1 <----> R2 <----> B
> 
> Scenario 1:
> -----------
> Host A sends an IP packet to B. R2 fails to forward it to B and responds 
> with an ICMP error message.
> R1 receives this ICMP packet, but fails to forward this to A, because of 
> (say) ARP lookup failures. Should R1 respond to R2 with another ICMP error 
> message? I'd guess no.
> 
> Scenario 2:
> -----------
> Host A sends an ICMP ping request to B. R1 fails to forward this to R2 
> because of (say) ARP lookup failures. Should R1 respond to A with an ICMP 
> error message in this case? 
> 
> 

You treat ICMP just like any other IP packet unless it is destined for 
one of your interfaces, ie an echo request, so if you cannot route it 
then yes you send an error to the sender.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Packet forwarding errors
Date: Mon, 5 Feb 2007 11:17:46 -0800
Lines: 38
Distribution: su
Message-ID: <eq7vss$bld$1@news.Stanford.EDU>
References: <eq6pel$b18$1@news.Stanford.EDU> <eq7v4p$b0c$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170703069 11949 127.0.0.1 (5 Feb 2007 19:17:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11445

Can you please tell me what the first bullet in Section 4.3.2.7 of RFC 1812 
means?
http://rfc.net/rfc1812.html#s4.3.2.7


"David Erickson" <derickso@stanford.edu> wrote in message 
news:eq7v4p$b0c$2@news.Stanford.EDU...
> Riju Kallivalappil wrote:
>> Should we send an ICMP error to the sender if we fail to forward an 
>> *ICMP* packet because of the usual ARP failure?
>>
>> For example, consider the following scenarios:
>>
>> Host A talks to Host B through routers R1 and R2. We are R1 in this case.
>>
>> A <---> R1 <----> R2 <----> B
>>
>> Scenario 1:
>> -----------
>> Host A sends an IP packet to B. R2 fails to forward it to B and responds 
>> with an ICMP error message.
>> R1 receives this ICMP packet, but fails to forward this to A, because of 
>> (say) ARP lookup failures. Should R1 respond to R2 with another ICMP 
>> error message? I'd guess no.
>>
>> Scenario 2:
>> -----------
>> Host A sends an ICMP ping request to B. R1 fails to forward this to R2 
>> because of (say) ARP lookup failures. Should R1 respond to A with an ICMP 
>> error message in this case?
>
> You treat ICMP just like any other IP packet unless it is destined for one 
> of your interfaces, ie an echo request, so if you cannot route it then yes 
> you send an error to the sender.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Memory Allocation Contract
Date: Mon, 5 Feb 2007 11:23:47 -0800
Lines: 35
Distribution: su
Message-ID: <eq808a$bup$1@news.Stanford.EDU>
References: <paun-F4A62F.13515927012007@nntp.stanford.edu> <C1E10D73.7CA9%jpettit@stanford.edu>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170703434 12249 128.12.81.44 (5 Feb 2007 19:23:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11446

Hey Justin,

sr_handlepacket has the packet parameter labeled lent but the comment above 
says do not delete it. Is the "lent" comment wrong? Seems to be the same in 
sr_arp_req_not_for_us which has lent data that it does not free but then in 
sr_send_packet for example buf is "borrowed" and not freed.

Thank you,
David Gobaud

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1E10D73.7CA9%jpettit@stanford.edu...
> These terms are from the perspective of you as the borrower or lender of a
> memory block.  So, for something borrowed, they are responsible.  For
> something lent, you are.
>
> --Justin
>
>
> On 1/27/07 1:51 PM, in article 
> paun-F4A62F.13515927012007@nntp.stanford.edu,
> "Filip Paun" <paun@stanford.edu> wrote:
>
>>    My question deals with the comments:
>>       /* borrowed */
>>       /* lent */
>> found next to several parameters.
>>
>>    For each one, who is responsible for freeing the memory allocated for
>> that parameter?
>>    Thank you.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Modifying struct sr_instance?
Date: Mon, 05 Feb 2007 11:39:56 -0800
Lines: 20
Distribution: su
Message-ID: <eq8154$cj5$1@news.Stanford.EDU>
References: <eq732s$hfd$1@news.Stanford.EDU> <eq7uuv$b0c$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170704357 12901 127.0.0.1 (5 Feb 2007 19:39:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <eq7uuv$b0c$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11447

struct sr_instance is actually in sr_router.h, and the faq says we can 
modify this file, so I assume the answer is yes.

Greg

David Erickson wrote:
> Raymond Thang wrote:
>> I think this was answered somewhere earlier, but I forgot where, so 
>> I'll ask it again:
>>
>> Are we allowed to modify (specifically: add to) members of the struct 
>> sr_instance in router.h?
>>
>> TIA,
>> Raymond
> 
> Please see the faq:
> http://www.stanford.edu/class/cs244a/2006/homeworks/hw2/faq.html#files_mod
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Using CLACK
Date: Mon, 05 Feb 2007 12:31:09 -0800
Lines: 36
Distribution: su
Message-ID: <pan.2007.02.05.20.31.04.367382@cs.stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170707010 15071 128.12.186.133 (5 Feb 2007 20:23:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11448

Hi,

I think I am using CLACK incorrectly:

I load up the applet and allow it to connect to the default topology 3. I
then ssh into a vine machine and run 'traceroute 171.67.71.25'. However,
the output is always:

vine3:~> traceroute 171.67.71.25
traceroute to 171.67.71.25 (171.67.71.25): 1-30 hops, 38 byte packets
 1  171.64.12.3 (171.64.12.3)  0.447 ms  0.374 ms  0.318 ms
 2  bbra-rtr.Stanford.EDU (172.20.4.1)  1.23 ms  0.774 ms  0.843 ms
 3  Gates-rtr.Stanford.EDU (171.64.1.44)  0.458 ms  0.488 ms  0.487 ms
 4  vns-firewall.Stanford.EDU (172.24.74.11)  0.327 ms (ttl=61!)  0.336 ms (ttl=61!)  0.311 ms (ttl=61!)
 5  *  *  *
 6  *  *  *
 7  *  *  *
 8  *  *  *
 9  *  *  *
10  *  *  *
11  *  *  *
12  *  *  *
13  *  *  *
14  *  *  *
15  *  *  *
16
(interrupt)

What am I doing wrong?

Also, I have noticed that in the CLACK flow diagram - the UDP box isn't
connected to the ICMP Port Unreach box when is says in the FAQ that we
should be generating ICMP Port Unreachable messages if we receive a TCP or
UDP packet addressed to one of our interfaces...

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Net unreachable
Date: Mon, 5 Feb 2007 16:17:40 -0800
Lines: 56
Distribution: su
Message-ID: <eq8hdk$ptf$1@news.Stanford.EDU>
References: <eq2ip3$n91$1@news.Stanford.EDU> <eq6vrc$eq6$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170721012 26543 127.0.0.1 (6 Feb 2007 00:16:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11449

I certainly can.  However, it is not listed in the requirements section.  I 
suggestion you check it.

Sincerely,
Randy Jennings

The squirrels are your friends!

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eq6vrc$eq6$1@news.Stanford.EDU...
> Please send an ICMP Message if you can't find a match in the routing 
> table. Which ICMP Message is up to you. You can justify your decision in 
> the README.
>
>
> Randy Jennings wrote:
>> From the FAQ:
>> //-----------------------------------(Man, it would be nice to do that in 
>> the code!)
>> What types of ICMP messages do I have to generate
>>
>> You should support the following:
>>
>> * Host unreachable (if no host replies to arp requests on the local 
>> networks)
>> * Port unreachable (if router receives a TCP or UDP packet addressed to 
>> one of its interfaces.
>> * Timeout (TTL of the arriving packet is one or zero)
>> * ICMP Echo reply (on receipt of an ICMP echo request to one of the 
>> router's interfaces)
>>
>> All other ICMP message that you receive you can ignore, however you 
>> should forward any icmp message that is not for the virtual router 
>> itself.
>> //-----------------------------------
>>
>> If we are going to send an ICMP message if the destination network is not 
>> in our routing table, I would think we should send
>> * Net unreachable
>> However, that is not listed above.  Are we supposed to send an ICMP 
>> message if the destination is not in our routing table?  Or should we lie 
>> and say
>> * Host unreachable
>> ?
>>
>> I guess it is not listed in required functionality.
>>
>> Then, is it okay if I do it?  (Yes, I know I was up in arms about the 
>> protocol unreachable.  That would also be easy to do.)
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: interface netmask
Date: Mon, 5 Feb 2007 16:21:14 -0800
Lines: 33
Distribution: su
Message-ID: <eq8hkb$q4d$1@news.Stanford.EDU>
References: <eq320p$64f$1@news.Stanford.EDU> <eq709q$eq6$5@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170721227 26765 127.0.0.1 (6 Feb 2007 00:20:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11450

Your comment makes no sense.  If you mean sr_if, here it is as I d/l it:

struct sr_if
{
    char name[sr_IFACE_NAMELEN];
    unsigned char addr[6];
    uint32_t ip;
    uint32_t speed;
    struct sr_if* next;
};

Would you care to elaborate on your response, or reconsider it?

Sincerely,
Randy Jennings

The squirrels are your friends!
"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eq709q$eq6$5@news.Stanford.EDU...
> Check the struct associated with the information you want.
>
> Randy Jennings wrote:
>> Erm... Is there any way to get the netmask on the sr_if?  I would like to 
>> know if someone sent me a valid ARP.  Seems like that is a standard thing 
>> for an interface to know...
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Packet forwarding errors
Date: Mon, 5 Feb 2007 16:30:50 -0800
Lines: 18
Distribution: su
Message-ID: <eq8i6b$qhg$1@news.Stanford.EDU>
References: <eq6pel$b18$1@news.Stanford.EDU> <eq7v4p$b0c$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170721803 27184 127.0.0.1 (6 Feb 2007 00:30:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11451

> You treat ICMP just like any other IP packet unless it is destined for one 
> of your interfaces, ie an echo request, so if you cannot route it then yes 
> you send an error to the sender.
This counsel is contrary to the ICMP explanation in rfc1122, which spells 
out when an ICMP packet should have an ICMP error message sent back to it. 
Most of those conditions apply to all packets (and in line with what you are 
saying), but one is specific to ICMP packets.

The reasons given in rfc 1122 make sense.  However, I know that we are often 
implementing simplified versions of the spec.  Is this such a place where 
simplifications are required?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP Packet forwarding errors
Date: Mon, 05 Feb 2007 17:13:08 -0800
Lines: 9
Distribution: su
Message-ID: <eq8kmt$sd1$1@news.Stanford.EDU>
References: <eq6pel$b18$1@news.Stanford.EDU> <eq7v4p$b0c$2@news.Stanford.EDU> <eq7vss$bld$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170724381 29089 127.0.0.1 (6 Feb 2007 01:13:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq7vss$bld$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11452

Riju Kallivalappil wrote:
> Can you please tell me what the first bullet in Section 4.3.2.7 of RFC 1812 
> means?
> http://rfc.net/rfc1812.html#s4.3.2.7

Thanks for the pointer, I hadn't read the rfc lately.  When in doubt, 
examine the rfc!

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Using CLACK
Date: Mon, 05 Feb 2007 17:21:30 -0800
Lines: 44
Distribution: su
Message-ID: <eq8l6i$sq6$1@news.Stanford.EDU>
References: <pan.2007.02.05.20.31.04.367382@cs.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170724882 29510 127.0.0.1 (6 Feb 2007 01:21:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <pan.2007.02.05.20.31.04.367382@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11453

Paolo wrote:
> Hi,
> 
> I think I am using CLACK incorrectly:
> 
> I load up the applet and allow it to connect to the default topology 3. I
> then ssh into a vine machine and run 'traceroute 171.67.71.25'. However,
> the output is always:
> 
> vine3:~> traceroute 171.67.71.25
> traceroute to 171.67.71.25 (171.67.71.25): 1-30 hops, 38 byte packets
>  1  171.64.12.3 (171.64.12.3)  0.447 ms  0.374 ms  0.318 ms
>  2  bbra-rtr.Stanford.EDU (172.20.4.1)  1.23 ms  0.774 ms  0.843 ms
>  3  Gates-rtr.Stanford.EDU (171.64.1.44)  0.458 ms  0.488 ms  0.487 ms
>  4  vns-firewall.Stanford.EDU (172.24.74.11)  0.327 ms (ttl=61!)  0.336 ms (ttl=61!)  0.311 ms (ttl=61!)
>  5  *  *  *
>  6  *  *  *
>  7  *  *  *
>  8  *  *  *
>  9  *  *  *
> 10  *  *  *
> 11  *  *  *
> 12  *  *  *
> 13  *  *  *
> 14  *  *  *
> 15  *  *  *
> 16
> (interrupt)
> 
> What am I doing wrong?
> 
> Also, I have noticed that in the CLACK flow diagram - the UDP box isn't
> connected to the ICMP Port Unreach box when is says in the FAQ that we
> should be generating ICMP Port Unreachable messages if we receive a TCP or
> UDP packet addressed to one of our interfaces...
> 
> Thanks.

There does appear to be a bug in clack's default setup.  If you right 
click the udp and drag a connection to ICMP portunreach box, then 
release the right mouse button, select source port: packets to 
unreachable ports, it will solve the problem.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: interface netmask
Date: Tue, 6 Feb 2007 01:58:08 +0000 (UTC)
Lines: 52
Distribution: su
Message-ID: <eq8nbg$100$1@news.Stanford.EDU>
References: <eq320p$64f$1@news.Stanford.EDU> <eq709q$eq6$5@news.Stanford.EDU> <eq8hkb$q4d$1@news.Stanford.EDU>
NNTP-Posting-Host: myth27.stanford.edu
X-Trace: news.Stanford.EDU 1170727088 1024 171.64.15.42 (6 Feb 2007 01:58:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11454

Hi Randy,

net mask is in sr_rt structure :
struct sr_rt
{
    struct in_addr dest;
    struct in_addr gw;
    struct in_addr mask;
    char   interface[sr_IFACE_NAMELEN];
    struct sr_rt* next;
};

Given an interface you can get the subnet mask from the routing table. 
(Packet is coming on this subnet)

Thanks,
Dinesh 

Randy Jennings <randyj@stanford.edu> wrote:
> Your comment makes no sense.  If you mean sr_if, here it is as I d/l it:

> struct sr_if
> {
>     char name[sr_IFACE_NAMELEN];
>     unsigned char addr[6];
>     uint32_t ip;
>     uint32_t speed;
>     struct sr_if* next;
> };

> Would you care to elaborate on your response, or reconsider it?

> Sincerely,
> Randy Jennings

> The squirrels are your friends!
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:eq709q$eq6$5@news.Stanford.EDU...
> > Check the struct associated with the information you want.
> >
> > Randy Jennings wrote:
> >> Erm... Is there any way to get the netmask on the sr_if?  I would like to 
> >> know if someone sent me a valid ARP.  Seems like that is a standard thing 
> >> for an interface to know...
> >>
> >> Sincerely,
> >> Randy Jennings
> >>
> >> The squirrels are your friends!
> >>
> >> 

.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: IP identification field generation
Date: Mon, 5 Feb 2007 19:58:18 -0800
Lines: 15
Distribution: su
Message-ID: <eq8ud1$5pq$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170734305 5946 128.12.81.44 (6 Feb 2007 03:58:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11455

Hi,

When we generate new IP headers for the ICMP messages how should we handle 
the identification field? I'm finding conflicting information in previous 
years newsgroups 
http://www.stanford.edu/class/cs244a/news/news2002.html#3462 and 
http://www.stanford.edu/class/cs244a/news/news2006.html#9948 one says to set 
it to any arbitrary value but the other says don't just set it to 0 because 
it could in theory be fragmented along the path so even though we don't have 
to deal with fragmentation routers in the path may.

Thank you,
David Gobaud


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: IP identification field generation
Date: Mon, 05 Feb 2007 20:13:59 -0800
Lines: 22
Distribution: su
Message-ID: <eq8v9v$6df$1@news.Stanford.EDU>
References: <eq8ud1$5pq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170735231 6575 127.0.0.1 (6 Feb 2007 04:13:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eq8ud1$5pq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11456

David Gobaud wrote:
> Hi,
> 
> When we generate new IP headers for the ICMP messages how should we handle 
> the identification field? I'm finding conflicting information in previous 
> years newsgroups 
> http://www.stanford.edu/class/cs244a/news/news2002.html#3462 and 
> http://www.stanford.edu/class/cs244a/news/news2006.html#9948 one says to set 
> it to any arbitrary value but the other says don't just set it to 0 because 
> it could in theory be fragmented along the path so even though we don't have 
> to deal with fragmentation routers in the path may.
> 
> Thank you,
> David Gobaud
> 
> 

Check out page 329 of the textbook for details on fragmentation and 
setting the id number of the packets, but yes I would agree you should 
set the id number.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: interface netmask
Date: Mon, 5 Feb 2007 20:17:53 -0800
Lines: 75
Distribution: su
Message-ID: <eq8vg2$6j1$1@news.Stanford.EDU>
References: <eq320p$64f$1@news.Stanford.EDU> <eq709q$eq6$5@news.Stanford.EDU> <eq8hkb$q4d$1@news.Stanford.EDU> <eq8nbg$100$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170735426 6753 127.0.0.1 (6 Feb 2007 04:17:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11457

Yes, it is good that there is a mask in the routing table entry. 
Unfortunately, that is not sufficient.

An entry in the routing table does not (necessarily) reflect the subnet mask 
of that interface.  For instance, in the routing table that was sent to us 
automatically, there are no subnet entries (for _any_ of the interfaces). 
There are only two specific routes and one default route.

The routing table can be different due to route aggregation as well.

IOW, the routing table should not be used to find the subnet of the 
interface.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
news:eq8nbg$100$1@news.Stanford.EDU...
> Hi Randy,
>
> net mask is in sr_rt structure :
> struct sr_rt
> {
>    struct in_addr dest;
>    struct in_addr gw;
>    struct in_addr mask;
>    char   interface[sr_IFACE_NAMELEN];
>    struct sr_rt* next;
> };
>
> Given an interface you can get the subnet mask from the routing table.
> (Packet is coming on this subnet)
>
> Thanks,
> Dinesh
>
> Randy Jennings <randyj@stanford.edu> wrote:
>> Your comment makes no sense.  If you mean sr_if, here it is as I d/l it:
>
>> struct sr_if
>> {
>>     char name[sr_IFACE_NAMELEN];
>>     unsigned char addr[6];
>>     uint32_t ip;
>>     uint32_t speed;
>>     struct sr_if* next;
>> };
>
>> Would you care to elaborate on your response, or reconsider it?
>
>> Sincerely,
>> Randy Jennings
>
>> The squirrels are your friends!
>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message
>> news:eq709q$eq6$5@news.Stanford.EDU...
>> > Check the struct associated with the information you want.
>> >
>> > Randy Jennings wrote:
>> >> Erm... Is there any way to get the netmask on the sr_if?  I would like 
>> >> to
>> >> know if someone sent me a valid ARP.  Seems like that is a standard 
>> >> thing
>> >> for an interface to know...
>> >>
>> >> Sincerely,
>> >> Randy Jennings
>> >>
>> >> The squirrels are your friends!
>> >>
>> >>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: clock_gettime and CLOCK_REALTIME
Date: Mon, 05 Feb 2007 22:14:27 -0800
Lines: 14
Distribution: su
Message-ID: <eq96ao$b65$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170742424 11461 127.0.0.1 (6 Feb 2007 06:13:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
Xref: shelby.stanford.edu su.class.cs244a:11458

I want to use pthread_cond_timedwait which takes a struct timespec that 
specifies the absolute time to wait until before it times out and 
returns.  To populate the timespec, I need to call a function 
clock_gettime and pass it the constant CLOCK_REALTIME.

Anyway, when I compile I get a warning of an undefined reference to 
clock_gettime and an error that CLOCK_REALTIME is undefined...  The man 
pages indicate that these are defined in time.h, but I'm including that 
header file and still getting this error.  When I hard code 
CLOCK_REALTIME as zero, then I still get the warning that clock_gettime 
is undefined, but everything compiles and links fine and runs as it's 
supposed to.

Anyone have any ideas?
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime and CLOCK_REALTIME
Date: Mon, 5 Feb 2007 22:39:55 -0800
Lines: 25
Distribution: su
Message-ID: <eq97qd$cck$1@news.Stanford.EDU>
References: <eq96ao$b65$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170743949 12692 127.0.0.1 (6 Feb 2007 06:39:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11459

It is probably not available with -ansi set.  Also note the availability 
section on the man page.  Search for sleep on the newsgroup, and you will 
find other ways of approaching it.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:eq96ao$b65$1@news.Stanford.EDU...
>I want to use pthread_cond_timedwait which takes a struct timespec that 
>specifies the absolute time to wait until before it times out and returns. 
>To populate the timespec, I need to call a function clock_gettime and pass 
>it the constant CLOCK_REALTIME.
>
> Anyway, when I compile I get a warning of an undefined reference to 
> clock_gettime and an error that CLOCK_REALTIME is undefined...  The man 
> pages indicate that these are defined in time.h, but I'm including that 
> header file and still getting this error.  When I hard code CLOCK_REALTIME 
> as zero, then I still get the warning that clock_gettime is undefined, but 
> everything compiles and links fine and runs as it's supposed to.
>
> Anyone have any ideas? 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime and CLOCK_REALTIME
Date: Mon, 05 Feb 2007 23:04:26 -0800
Lines: 34
Distribution: su
Message-ID: <eq998e$dfc$1@news.Stanford.EDU>
References: <eq96ao$b65$1@news.Stanford.EDU> <eq97qd$cck$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170745423 13804 127.0.0.1 (6 Feb 2007 07:03:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
In-Reply-To: <eq97qd$cck$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11460

Well, you're right that compiling without -ansi fixes it.  However, we 
were encouraged to use pthreads.  It seems silly to me that we should 
avoid pthread_cond_timedwait when it is available on the myths.  Can one 
of the TAs confirm that we will be docked points if we use 
pthread_cond_timedwait?

Greg

Randy Jennings wrote:
> It is probably not available with -ansi set.  Also note the availability 
> section on the man page.  Search for sleep on the newsgroup, and you will 
> find other ways of approaching it.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Greg Nelson" <grourk@stanford.edu> wrote in message 
> news:eq96ao$b65$1@news.Stanford.EDU...
>> I want to use pthread_cond_timedwait which takes a struct timespec that 
>> specifies the absolute time to wait until before it times out and returns. 
>> To populate the timespec, I need to call a function clock_gettime and pass 
>> it the constant CLOCK_REALTIME.
>>
>> Anyway, when I compile I get a warning of an undefined reference to 
>> clock_gettime and an error that CLOCK_REALTIME is undefined...  The man 
>> pages indicate that these are defined in time.h, but I'm including that 
>> header file and still getting this error.  When I hard code CLOCK_REALTIME 
>> as zero, then I still get the warning that clock_gettime is undefined, but 
>> everything compiles and links fine and runs as it's supposed to.
>>
>> Anyone have any ideas? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Tue, 06 Feb 2007 00:52:04 -0800
Lines: 34
Distribution: su
Message-ID: <eq9fjk$lq7$1@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU> <eq73tj$hrp$2@news.Stanford.EDU> <eq7thi$9te$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170751924 22343 128.12.194.72 (6 Feb 2007 08:52:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq7thi$9te$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11461

pthread_create() can only handle thread functions that take a single 
argument though. I can work around that, but the end result will look 
ugly and be *painful* to grade.

Surely there is a solution that involves less pain? :)

-Yangfan

Riju Kallivalappil wrote:
> Use pthread_create(). fork() creates a new process.
> 
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:eq73tj$hrp$2@news.Stanford.EDU...
> 
>>Yangfan Wang wrote:
>>
>>>Okay, even though the pointers are telling me that they point to the same 
>>>address, starting new threads with fork() seems to copy all the memory 
>>>pages as a side effect, if I'm reading the man page correctly. This 
>>>obviously make it impossible for the threads to share data.
>>>
>>>Can someone teach me the proper way to use clone()? The man page on clone 
>>>only served to confuse and scare me. :p
>>>
>>>Or could the TAs point out a way to share memory among threads generated 
>>>with fork()?
>>>
>>
>>To be more specific, I need the threads to share heap space.
>>
>>-Yangfan 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 6 Feb 2007 00:53:05 -0800
Lines: 29
Distribution: su
Message-ID: <eq9flo$lr6$1@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170751992 22374 128.12.81.44 (6 Feb 2007 08:53:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11462

Should the first host unreachable message be sent at t=5 after 5 ARP 
requests and then the second one is sent at t=7 after 7th request?

Thank you,
David Gobaud

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eq6vtc$eq6$2@news.Stanford.EDU...
> Yes, each packet should be acknowledged (since they might be form 
> different hosts or different programs, etc).
>
> Matt Page wrote:
>> Regarding how many packets we should send before we send a "host 
>> unreachable message,"
>>
>> What if we have two packets arriving roughly 2 seconds apart destined for 
>> the same unreachable host?
>> The first packet will spawn 5 ARP requests, while, according to the 
>> documentation, the second packet
>> will spawn an additional 2 ARP requests. (They both generate 5 ARP 
>> requests with the latter 3 of the first request overlapping with the 
>> first 3 of the second request.) This will generate 2 host unreachable 
>> messages. Is this the correct
>> behavior?
>>
>> Thanks,
>> Matt 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Tue, 06 Feb 2007 02:26:07 -0800
Lines: 33
Distribution: su
Message-ID: <eq9l3u$qfn$1@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU> <eq73tj$hrp$2@news.Stanford.EDU> <eq7thi$9te$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170757566 27127 128.12.194.72 (6 Feb 2007 10:26:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eq7thi$9te$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11463

Also, what do I have to include to get pthread_create() to link? The 
compiler can't find it right now. I've already included pthread.h. :(

Strangely enough, pthread_mutex_lock works just fine.

-Yangfan

Riju Kallivalappil wrote:
> Use pthread_create(). fork() creates a new process.
> 
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:eq73tj$hrp$2@news.Stanford.EDU...
> 
>>Yangfan Wang wrote:
>>
>>>Okay, even though the pointers are telling me that they point to the same 
>>>address, starting new threads with fork() seems to copy all the memory 
>>>pages as a side effect, if I'm reading the man page correctly. This 
>>>obviously make it impossible for the threads to share data.
>>>
>>>Can someone teach me the proper way to use clone()? The man page on clone 
>>>only served to confuse and scare me. :p
>>>
>>>Or could the TAs point out a way to share memory among threads generated 
>>>with fork()?
>>>
>>
>>To be more specific, I need the threads to share heap space.
>>
>>-Yangfan 
> 
> 
> 
.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: routing table file
Date: Tue, 6 Feb 2007 04:39:34 -0800
Lines: 10
Distribution: su
Message-ID: <Pine.LNX.4.44.0702060438560.6566-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170765576 4416 171.64.15.38 (6 Feb 2007 12:39:36 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11464

My rtable file is one-liner:

0.0.0.0 172.24.74.17 0.0.0.0 eth0


Should there be more entries?

Thanks,
-Seung

.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: packet addressed to the router
Date: Tue, 6 Feb 2007 07:34:20 -0800
Lines: 8
Distribution: su
Message-ID: <Pine.LNX.4.44.0702060733540.11347-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170776061 12939 171.64.15.38 (6 Feb 2007 15:34:21 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11465



What kind of packets can be addressed to the router?

Thanks,
-Seung


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Tue, 6 Feb 2007 08:51:49 -0800
Lines: 49
Distribution: su
Message-ID: <eqablp$g8a$1@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU> <eq73tj$hrp$2@news.Stanford.EDU> <eq7thi$9te$1@news.Stanford.EDU> <eq9fjk$lq7$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170780665 16650 127.0.0.1 (6 Feb 2007 16:51:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11466

Nope.  Get used to it.  You cast the struct you are passing to a void*. 
This is C not C++ (and you have to do basically the same thing in C++, but 
you can hide it better).

As to the linking problem, what machines are you using?  The Solaris boxes 
may need a library (I cannot remember if it is -lpthread or -lthread), but 
Linux and Cygwin both link it in with libc (e.g. automatically).

Sincerely,
Randy Jennings

The squirrels are your friends!

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eq9fjk$lq7$1@news.Stanford.EDU...
> pthread_create() can only handle thread functions that take a single 
> argument though. I can work around that, but the end result will look ugly 
> and be *painful* to grade.
>
> Surely there is a solution that involves less pain? :)
>
> -Yangfan
>
> Riju Kallivalappil wrote:
>> Use pthread_create(). fork() creates a new process.
>>
>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>> news:eq73tj$hrp$2@news.Stanford.EDU...
>>
>>>Yangfan Wang wrote:
>>>
>>>>Okay, even though the pointers are telling me that they point to the 
>>>>same address, starting new threads with fork() seems to copy all the 
>>>>memory pages as a side effect, if I'm reading the man page correctly. 
>>>>This obviously make it impossible for the threads to share data.
>>>>
>>>>Can someone teach me the proper way to use clone()? The man page on 
>>>>clone only served to confuse and scare me. :p
>>>>
>>>>Or could the TAs point out a way to share memory among threads generated 
>>>>with fork()?
>>>>
>>>
>>>To be more specific, I need the threads to share heap space.
>>>
>>>-Yangfan
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: routing table file
Date: Tue, 6 Feb 2007 08:54:19 -0800
Lines: 22
Distribution: su
Message-ID: <eqabqe$gb8$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702060438560.6566-100000@myth20.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170780814 16744 127.0.0.1 (6 Feb 2007 16:53:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11467

Yes.  I was puzzled at first, too.  See the email attachment from the VNS 
Topology Bot (you will probably want to rename it).

Sincerely,
Randy Jennings

The squirrels are your friends!

"Seung Hoon Choi" <shchoi@stanford.edu> wrote in message 
news:Pine.LNX.4.44.0702060438560.6566-100000@myth20.Stanford.EDU...
> My rtable file is one-liner:
>
> 0.0.0.0 172.24.74.17 0.0.0.0 eth0
>
>
> Should there be more entries?
>
> Thanks,
> -Seung
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 6 Feb 2007 11:44:37 -0800
Lines: 29
Distribution: su
Message-ID: <eqalrc$pt8$1@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170791085 26536 128.12.81.44 (6 Feb 2007 19:44:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11468

Should the first host unreachable message be sent at t=5 after 5 ARP
requests and then the second one is sent at t=7 after 7th request?

Thank you,
David Gobaud

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eq6vtc$eq6$2@news.Stanford.EDU...
> Yes, each packet should be acknowledged (since they might be form 
> different hosts or different programs, etc).
>
> Matt Page wrote:
>> Regarding how many packets we should send before we send a "host 
>> unreachable message,"
>>
>> What if we have two packets arriving roughly 2 seconds apart destined for 
>> the same unreachable host?
>> The first packet will spawn 5 ARP requests, while, according to the 
>> documentation, the second packet
>> will spawn an additional 2 ARP requests. (They both generate 5 ARP 
>> requests with the latter 3 of the first request overlapping with the 
>> first 3 of the second request.) This will generate 2 host unreachable 
>> messages. Is this the correct
>> behavior?
>>
>> Thanks,
>> Matt 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet addressed to the router
Date: Tue, 06 Feb 2007 11:53:27 -0800
Lines: 15
Distribution: su
Message-ID: <eqamlq$qhn$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702060733540.11347-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170791930 27191 171.64.74.54 (6 Feb 2007 19:58:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.44.0702060733540.11347-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11469

Take a look at the FAQ 
(http://www.stanford.edu/class/cs244a/2006/homeworks/hw2/faq.html)- it 
covers pretty much everything you need to handle, particularly around 
questions 7-14

Clay

Seung Hoon Choi wrote:
> 
> What kind of packets can be addressed to the router?
> 
> Thanks,
> -Seung
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: routing table file
Date: Tue, 06 Feb 2007 11:56:21 -0800
Lines: 17
Distribution: su
Message-ID: <eqamr8$qhn$2@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702060438560.6566-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170792104 27191 171.64.74.54 (6 Feb 2007 20:01:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.44.0702060438560.6566-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11470

Try running sr with the -r option, and passing it the location of your 
rtable file- as Randy mentioned, it was attached to the email you 
received with your initial topology assignment.

Clay

Seung Hoon Choi wrote:
> My rtable file is one-liner:
> 
> 0.0.0.0 172.24.74.17 0.0.0.0 eth0
> 
> 
> Should there be more entries?
> 
> Thanks,
> -Seung
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: define __USE_UNIX98 and cleanup code
Date: Tue, 6 Feb 2007 12:06:40 -0800
Lines: 11
Distribution: su
Message-ID: <eqan4o$qu4$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170792408 27588 128.12.81.44 (6 Feb 2007 20:06:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11471

Hi,

Is it ok to define __USE_UNIX98 for recursive mutex support in pthreads?

What about cleanup code? Something like sr_destroy to complement our init 
code in sr_init or should we not worry about it?

Thank you,
David Gobaud 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Implementation of timeouts
Date: Tue, 06 Feb 2007 12:05:35 -0800
Lines: 22
Distribution: su
Message-ID: <eqanci$r79$1@news.Stanford.EDU>
References: <eq69q9$ppv$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170792659 27881 171.64.74.54 (6 Feb 2007 20:10:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eq69q9$ppv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11472

For something like a callback function that runs as a signal handler, 
there are sometimes very few other options than to use a global 
variable.  As long as you describe why its use is necessary in your 
README and use it in a well-defined manner - e.g. nothing touches it 
except the signal handler- than it is acceptable to use global variables 
in certain circumstances.  Just don't use them as a convenience in order 
to avoid having to pass parameters to ordinary functions.

Clay


Neelima Balakrishnan wrote:
> Hi,
> 
> I would like to implement the cache timeouts using 
> signals/alarm-handlers. So for that I wanted to know whether I can
> maintain a global pointer to the sr_instance passed to us?
> Just want to make sure that using global variables is fine as in PA1 it
> was explicitly mentioned otherwise.
> 
> Thanks
> Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: define __USE_UNIX98 and cleanup code
Date: Tue, 06 Feb 2007 12:50:34 -0800
Lines: 20
Distribution: su
Message-ID: <eqaq0u$v$1@news.Stanford.EDU>
References: <eqan4o$qu4$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170795358 31 171.64.74.54 (6 Feb 2007 20:55:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqan4o$qu4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11473

The better way to turn on Unix98 features is to set -D_XOPEN_SOURCE=500 
in your Makefile.  __USE_UNIX98 is an internal flag for features.h- it 
shouldn't be set directly.  As long as your code still compiles cleanly 
from your Makefile with -ansi -Wall when you set these flags, using them 
is acceptable.

Clay

David Gobaud wrote:
> Hi,
> 
> Is it ok to define __USE_UNIX98 for recursive mutex support in pthreads?
> 
> What about cleanup code? Something like sr_destroy to complement our init 
> code in sr_init or should we not worry about it?
> 
> Thank you,
> David Gobaud 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: define __USE_UNIX98 and cleanup code
Date: Tue, 06 Feb 2007 12:51:22 -0800
Lines: 9
Distribution: su
Message-ID: <eqaq2d$v$2@news.Stanford.EDU>
References: <eqan4o$qu4$1@news.Stanford.EDU> <eqaq0u$v$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170795405 31 171.64.74.54 (6 Feb 2007 20:56:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqaq0u$v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11474

Clay Collier wrote:
> As long as your code still compiles cleanly 

on the myth machines, I should have inserted here

> from your Makefile with -ansi -Wall when you set these flags, using them 
> is acceptable.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] Req 7 clarification?
Date: Tue, 06 Feb 2007 13:00:59 -0800
Lines: 47
Distribution: su
Message-ID: <eqaqke$g0$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702031251520.19595-100000@myth26.Stanford.EDU> <eq7082$eq6$4@news.Stanford.EDU> <Pine.LNX.4.44.0702051035150.570-100000@myth21.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170795983 512 171.64.74.54 (6 Feb 2007 21:06:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.44.0702051035150.570-100000@myth21.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11475

If, after sending 5 ARP requests, you receive no reply you should send 
an ICMP Host Unreachable error message to the initial sender.  So you 
send an ARP request, wait a short period for a reply, and continue doing 
this until you either 1) receive an ARP reply or 2) send 5 requests with 
no response.

The cache requirement (expire the cache after about 15 seconds) is 
entirely independent- this means that once you get an ARP reply for a 
specific IP, you should save that reply and keep it around for ~15 
seconds.  Any packets destined for that IP during this 15 second period 
are sent using the MAC address in the ARP cache.  After 15 seconds, the 
next time you get a packet for that IP, you go through the ARP 
request/reply sequence again for that IP.

Clay
Ryan Chen wrote:
> So can you elaborate on the meaning of "5 ARP requests"? What does this
> "5" mean?
> 
> On Mon, 5 Feb 2007, Paul Tarjan (TA) wrote:
> 
>> You might not want to wait 15 seconds between ARP requests then. I think
>> you are confused about the 15 second part. We want you to forget things
>> from your ARP table 15 seconds after they were discovered. We DIDN'T
>> mean "send ARP requests every 15 seconds".
>>
>> Ryan Chen wrote:
>>> Hi, I am a little confused about requirement 7 in "Required Functionality"
>>> that says:
>>>
>>> The router queues all packets waiting for outstanding ARP replies. If a
>>> host does not respond to 5 ARP requests, the queued packet is dropped and
>>> an ICMP host unreachable message is sent back to the source of the queued
>>> packet.
>>>
>>> Is it saying say A is my router, and B is say Application 1, C is
>>> someone who tries to send a packet to B, and that my router A
>>> needs to implement a queue that queues ARP requests packets from C (that
>>> are
>>> supposed to go to B), and now I will try to send ARP request to B 5 times,
>>> if after 5 times, in which each I waited 15 seconds, and there is still no
>>> SINGLE ARP reply from B, then after this 75 seconds, I shall send an ICMP
>>> unreachable back to the C?
>>>
>>> If the TA can clarify, that will be great. Thanks.
>>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Logging in reference implementation
Date: Tue, 6 Feb 2007 14:10:46 -0700
Lines: 8
Distribution: su
Message-ID: <eqaqso$uo$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170796248 984 127.0.0.1 (6 Feb 2007 21:10:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11476

Is logging disabled on the reference router running on topology 2?  I don't 
think it sends the correct ICMP message when it gets a TCP/UDP packet 
addressed to one of its interfaces, but it's hard to verify that without a 
log.

--Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 06 Feb 2007 13:06:19 -0800
Lines: 34
Distribution: su
Message-ID: <eqaque$104$1@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU> <eqalrc$pt8$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170796303 1028 171.64.74.54 (6 Feb 2007 21:11:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqalrc$pt8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11477

That's probably the better way to do it, yes.

Clay

David Gobaud wrote:
> Should the first host unreachable message be sent at t=5 after 5 ARP
> requests and then the second one is sent at t=7 after 7th request?
> 
> Thank you,
> David Gobaud
> 
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:eq6vtc$eq6$2@news.Stanford.EDU...
>> Yes, each packet should be acknowledged (since they might be form 
>> different hosts or different programs, etc).
>>
>> Matt Page wrote:
>>> Regarding how many packets we should send before we send a "host 
>>> unreachable message,"
>>>
>>> What if we have two packets arriving roughly 2 seconds apart destined for 
>>> the same unreachable host?
>>> The first packet will spawn 5 ARP requests, while, according to the 
>>> documentation, the second packet
>>> will spawn an additional 2 ARP requests. (They both generate 5 ARP 
>>> requests with the latter 3 of the first request overlapping with the 
>>> first 3 of the second request.) This will generate 2 host unreachable 
>>> messages. Is this the correct
>>> behavior?
>>>
>>> Thanks,
>>> Matt 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Logging in reference implementation
Date: Tue, 6 Feb 2007 14:25:47 -0700
Lines: 15
Distribution: su
Message-ID: <eqarou$1kk$1@news.Stanford.EDU>
References: <eqaqso$uo$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170797150 1684 127.0.0.1 (6 Feb 2007 21:25:50 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11478

Now I can't seem to get a log with my topology either.  What changed?  Is 
the vns system acting up?

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:eqaqso$uo$1@news.Stanford.EDU...
> Is logging disabled on the reference router running on topology 2?  I 
> don't think it sends the correct ICMP message when it gets a TCP/UDP 
> packet addressed to one of its interfaces, but it's hard to verify that 
> without a log.
>
> --Kevin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 6 Feb 2007 14:33:40 -0700
Lines: 49
Distribution: su
Message-ID: <eqas7o$22e$1@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU> <eqalrc$pt8$1@news.Stanford.EDU> <eqaque$104$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170797624 2126 127.0.0.1 (6 Feb 2007 21:33:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11479

Wait a minute.  Based on our requirements handout, it should be a valid 
design choice to have only one arp transaction pending at a time per 
interface.  In such a design, later-arriving packets will not be "needlessly 
dropped" as long as there is a queue in the router somewhere to hold them. 
They can have their turn at an arp transaction when the previous arp 
transaction has completed with a timeout.  In this scenario, the host 
unreachable messages could be sent at around t=5 and t=10 (assuming the 
simulus packets arrive back to back).  This would be correct behavior as 
well.  Right?

Thanks,
Kevin

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eqaque$104$1@news.Stanford.EDU...
> That's probably the better way to do it, yes.
>
> Clay
>
> David Gobaud wrote:
>> Should the first host unreachable message be sent at t=5 after 5 ARP
>> requests and then the second one is sent at t=7 after 7th request?
>>
>> Thank you,
>> David Gobaud
>>
>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
>> news:eq6vtc$eq6$2@news.Stanford.EDU...
>>> Yes, each packet should be acknowledged (since they might be form 
>>> different hosts or different programs, etc).
>>>
>>> Matt Page wrote:
>>>> Regarding how many packets we should send before we send a "host 
>>>> unreachable message,"
>>>>
>>>> What if we have two packets arriving roughly 2 seconds apart destined 
>>>> for the same unreachable host?
>>>> The first packet will spawn 5 ARP requests, while, according to the 
>>>> documentation, the second packet
>>>> will spawn an additional 2 ARP requests. (They both generate 5 ARP 
>>>> requests with the latter 3 of the first request overlapping with the 
>>>> first 3 of the second request.) This will generate 2 host unreachable 
>>>> messages. Is this the correct
>>>> behavior?
>>>>
>>>> Thanks,
>>>> Matt
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Memory Allocation Contract
Date: Tue, 06 Feb 2007 16:01:56 -0800
Lines: 57
Distribution: su
Message-ID: <C1EE56F4.81F4%jpettit@stanford.edu>
References: <paun-F4A62F.13515927012007@nntp.stanford.edu> <C1E10D73.7CA9%jpettit@stanford.edu> <eq808a$bup$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170806518 8939 127.0.0.1 (7 Feb 2007 00:01:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Memory Allocation Contract
Thread-Index: AcdKSy4cbI/rlrY+EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11480

You are correct that it is wrong.  I spoke with one of the initial authors
of VNS and he was saying that these terms are mostly historical.  There was
a time when there existed a third category called "given".  The important
distinction there was that the callee was responsible for freeing the
memory. 

You should be able to determine by the parameters of functions whether you
are supplying the arguments or whether they are being supplied to you.  If
the argument is labeled "borrowed" or "lent", then only free the memory if
you are the one that initially allocated it.

I'll see about getting the comments cleaned up for future classes.  If
anyone is still confused, feel free to post it to the newsgroup.

--Justin


On 2/5/07 11:23 AM, in article eq808a$bup$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> Hey Justin,
> 
> sr_handlepacket has the packet parameter labeled lent but the comment above
> says do not delete it. Is the "lent" comment wrong? Seems to be the same in
> sr_arp_req_not_for_us which has lent data that it does not free but then in
> sr_send_packet for example buf is "borrowed" and not freed.
> 
> Thank you,
> David Gobaud
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1E10D73.7CA9%jpettit@stanford.edu...
>> These terms are from the perspective of you as the borrower or lender of a
>> memory block.  So, for something borrowed, they are responsible.  For
>> something lent, you are.
>> 
>> --Justin
>> 
>> 
>> On 1/27/07 1:51 PM, in article
>> paun-F4A62F.13515927012007@nntp.stanford.edu,
>> "Filip Paun" <paun@stanford.edu> wrote:
>> 
>>>    My question deals with the comments:
>>>       /* borrowed */
>>>       /* lent */
>>> found next to several parameters.
>>> 
>>>    For each one, who is responsible for freeing the memory allocated for
>>> that parameter?
>>>    Thank you.
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: stub code
Date: Wed, 7 Feb 2007 00:03:23 +0000 (UTC)
Organization: Your Company
Lines: 29
Distribution: su
Message-ID: <Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170806603 8641 128.12.22.217 (7 Feb 2007 00:03:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11481

when i run the stub code, this is all i get...


elaine27:~/cs244a/proj2/stub> ./sr -t 170 -s vns-1.stanford.edu
Loading routing table
---------------------------------------------
Destination     Gateway         Mask    Iface
0.0.0.0         172.24.74.17    0.0.0.0 eth0
---------------------------------------------
Client chunkaiw connecting to Server vns-1.stanford.edu:12345
Requesting topology 170
Router interfaces:
eth0    HWaddr70:00:00:aa:00:01
        inet addr 192.168.128.84
eth1    HWaddr70:00:00:aa:00:02
        inet addr 192.168.128.85
eth2    HWaddr70:00:00:aa:00:06
        inet addr 192.168.128.87
 <-- Ready to process packets --> 
*** -> Received packet of length 60 
*** -> Received packet of length 60 
*** -> Received packet of length 60 



is this right? I didn't even type "ping"...



.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ARP cache implementation
Date: Tue, 6 Feb 2007 16:25:36 -0800
Lines: 10
Distribution: su
Message-ID: <Pine.LNX.4.44.0702061623480.27048-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170807937 10114 171.64.15.38 (7 Feb 2007 00:25:37 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11482


According to FAQ #17, it seems that we can have some fixed sized table of
(say 100) ARP entries to implement cache. If this is correct behavior,
what if there are more than 100 different ARP requests to be made under 15
seconds? What should one do?


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stub code
Date: Tue, 6 Feb 2007 16:27:13 -0800
Lines: 38
Distribution: su
Message-ID: <eqb6d9$9tn$1@news.Stanford.EDU>
References: <Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170808041 10167 128.12.81.44 (7 Feb 2007 00:27:21 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11483

Looks ok. Someone else must be sending data to your router. Also, don't 
forget to use the rtable file sent to you in your topology email.

David Gobaud

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103...
> when i run the stub code, this is all i get...
>
>
> elaine27:~/cs244a/proj2/stub> ./sr -t 170 -s vns-1.stanford.edu
> Loading routing table
> ---------------------------------------------
> Destination     Gateway         Mask    Iface
> 0.0.0.0         172.24.74.17    0.0.0.0 eth0
> ---------------------------------------------
> Client chunkaiw connecting to Server vns-1.stanford.edu:12345
> Requesting topology 170
> Router interfaces:
> eth0    HWaddr70:00:00:aa:00:01
>        inet addr 192.168.128.84
> eth1    HWaddr70:00:00:aa:00:02
>        inet addr 192.168.128.85
> eth2    HWaddr70:00:00:aa:00:06
>        inet addr 192.168.128.87
> <-- Ready to process packets -->
> *** -> Received packet of length 60
> *** -> Received packet of length 60
> *** -> Received packet of length 60
>
>
>
> is this right? I didn't even type "ping"...
>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: lent/borrow
Date: Wed, 7 Feb 2007 00:50:44 +0000 (UTC)
Organization: Your Company
Lines: 9
Distribution: su
Message-ID: <Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170809444 8641 128.12.22.217 (7 Feb 2007 00:50:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11484

so im still a little confused,  for example

void sr_handlepacket(struct sr_instance* sr, 
        uint8_t * packet/* lent */,
        unsigned int len,
        char* interface/* lent */)


we are incharge of freeing sr right?
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: lent/borrow
Date: Tue, 6 Feb 2007 16:52:09 -0800
Lines: 19
Distribution: su
Message-ID: <eqb7s1$b9h$1@news.Stanford.EDU>
References: <Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170809538 11569 128.12.81.44 (7 Feb 2007 00:52:18 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11485

see thread "Memory Allocation Contract" below

short answer is the lent/borrowed stuff is wrong so ignore it.

David Gobaud

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103...
> so im still a little confused,  for example
>
> void sr_handlepacket(struct sr_instance* sr,
>        uint8_t * packet/* lent */,
>        unsigned int len,
>        char* interface/* lent */)
>
>
> we are incharge of freeing sr right? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 6 Feb 2007 16:57:42 -0800
Lines: 16
Distribution: su
Message-ID: <eqb84n$bep$1@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU> <eqalrc$pt8$1@news.Stanford.EDU> <eqaque$104$1@news.Stanford.EDU> <eqas7o$22e$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170809815 11737 127.0.0.1 (7 Feb 2007 00:56:55 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11486

I talked to David Erickson before class.  He said that when the first packet 
with the address (say 192.168.0.1) expires its 5/15 seconds (depending on 
who you talk to), you can drop all packets to 192.168.0.1 that arrived in 
the meantime.  When the next one arrives, you start up the ARP process 
again.

This makes sense, it is the behavior I saw on the vns firewall (when I 
arranged for the situation to happen), and it is required if you want 
traceroute to terminate before it hits 30 hops.

HTH,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: lent/borrow
Date: Tue, 6 Feb 2007 17:01:53 -0800
Lines: 22
Distribution: su
Message-ID: <eqb8ch$bpf$1@news.Stanford.EDU>
References: <Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1170810065 12079 127.0.0.1 (7 Feb 2007 01:01:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11487

I would not recommend freeing any sr's (or interfaces for that matter) in 
your code.  Yes, we are lending sr to the function below in that we are 
giving sr to it to play around with.  When that function comes back, it does 
not retain any hooks to sr (and if it does, I don't care).

Sincerely,
Randy Jennings

The squirrels are your friends!
"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103...
> so im still a little confused,  for example
>
> void sr_handlepacket(struct sr_instance* sr,
>        uint8_t * packet/* lent */,
>        unsigned int len,
>        char* interface/* lent */)
>
>
> we are incharge of freeing sr right? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: output from sr
Date: Tue, 6 Feb 2007 17:03:56 -0800
Lines: 9
Distribution: su
Message-ID: <eqb8gd$brr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170810189 12155 127.0.0.1 (7 Feb 2007 01:03:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11488

I know I need to turn off the printf in sr_handlepacket.  Do I need to turn 
off the output in the rest of the sr code?  Please say, "no."

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP cache implementation
Date: Tue, 06 Feb 2007 17:14:44 -0800
Lines: 29
Distribution: su
Message-ID: <eqb9ga$co9$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702061623480.27048-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170811212 13065 171.64.74.54 (7 Feb 2007 01:20:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Pine.LNX.4.44.0702061623480.27048-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11489

Make sure you're not confusing the ARP cache (which records a mapping of 
IPs to MAC addressses) with your list of outstanding ARP requests (which 
records ARP requests that you haven't heard back from yet).

You would only need an ARP cache of > 100 if you needed to keep the MAC 
addresses for more than 100 hosts collision domains that the router can 
see- something that we won't be doing to test your router.

How you scale and store your list of outstanding ARP requests, on the 
other hand, is up to you.  You could have a large number of outstanding 
requests at the same time if you receive a lot of traffic that is 
ultimately going to result in ICMP Host Unreachable messages; on the 
other hand, since the ICMP message is sent back within 5-7 seconds of 
the first ARP (see the FAQ), these messages don't live very long.  Your 
strategy for keeping track of outstanding ARP requests appropriately is 
the sort of thing you should describe in your README file.

Clay

Seung Hoon Choi wrote:
> According to FAQ #17, it seems that we can have some fixed sized table of
> (say 100) ARP entries to implement cache. If this is correct behavior,
> what if there are more than 100 different ARP requests to be made under 15
> seconds? What should one do?
> 
> 
> Thanks,
> -Seung
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: output from sr
Date: Tue, 06 Feb 2007 17:17:41 -0800
Lines: 19
Distribution: su
Message-ID: <eqb9lr$cjf$1@news.Stanford.EDU>
References: <eqb8gd$brr$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170811389 12911 171.64.74.54 (7 Feb 2007 01:23:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqb8gd$brr$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11490

No.  The initialization message that the stub code sends (the routing 
table and topology description) can stay.  Just get rid of the 'Received 
packet of length XX' message and don't include any additional output in 
the code that you submit (you're free to make an optional debugging 
preprocessor flags/macro to help you out, just make sure that they are 
turned off by default).

Clay

Randy Jennings wrote:
> I know I need to turn off the printf in sr_handlepacket.  Do I need to turn 
> off the output in the rest of the sr code?  Please say, "no."
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP Queue timeouts
Date: Tue, 06 Feb 2007 17:20:45 -0800
Lines: 52
Distribution: su
Message-ID: <eqb9ri$cjf$2@news.Stanford.EDU>
References: <eq2rvu$1a6$1@news.Stanford.EDU> <eq6vtc$eq6$2@news.Stanford.EDU> <eqalrc$pt8$1@news.Stanford.EDU> <eqaque$104$1@news.Stanford.EDU> <eqas7o$22e$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170811573 12911 171.64.74.54 (7 Feb 2007 01:26:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqas7o$22e$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11491

Yes- that's also perfectly fine choice.

Clay
Kevin Hart wrote:
> Wait a minute.  Based on our requirements handout, it should be a valid 
> design choice to have only one arp transaction pending at a time per 
> interface.  In such a design, later-arriving packets will not be "needlessly 
> dropped" as long as there is a queue in the router somewhere to hold them. 
> They can have their turn at an arp transaction when the previous arp 
> transaction has completed with a timeout.  In this scenario, the host 
> unreachable messages could be sent at around t=5 and t=10 (assuming the 
> simulus packets arrive back to back).  This would be correct behavior as 
> well.  Right?
> 
> Thanks,
> Kevin
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eqaque$104$1@news.Stanford.EDU...
>> That's probably the better way to do it, yes.
>>
>> Clay
>>
>> David Gobaud wrote:
>>> Should the first host unreachable message be sent at t=5 after 5 ARP
>>> requests and then the second one is sent at t=7 after 7th request?
>>>
>>> Thank you,
>>> David Gobaud
>>>
>>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
>>> news:eq6vtc$eq6$2@news.Stanford.EDU...
>>>> Yes, each packet should be acknowledged (since they might be form 
>>>> different hosts or different programs, etc).
>>>>
>>>> Matt Page wrote:
>>>>> Regarding how many packets we should send before we send a "host 
>>>>> unreachable message,"
>>>>>
>>>>> What if we have two packets arriving roughly 2 seconds apart destined 
>>>>> for the same unreachable host?
>>>>> The first packet will spawn 5 ARP requests, while, according to the 
>>>>> documentation, the second packet
>>>>> will spawn an additional 2 ARP requests. (They both generate 5 ARP 
>>>>> requests with the latter 3 of the first request overlapping with the 
>>>>> first 3 of the second request.) This will generate 2 host unreachable 
>>>>> messages. Is this the correct
>>>>> behavior?
>>>>>
>>>>> Thanks,
>>>>> Matt
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stub code
Date: Tue, 06 Feb 2007 17:26:34 -0800
Lines: 47
Distribution: su
Message-ID: <eqba6k$dcq$1@news.Stanford.EDU>
References: <Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103> <eqb6d9$9tn$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170811924 13722 171.64.74.54 (7 Feb 2007 01:32:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqb6d9$9tn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11492

Yup- it's entirely possible that someone might send packets to one of 
the IPs on your topology.  It's likely that it's just someone who typoed 
an IP address, but it could be on purpose.  No extra credit for crashing 
your classmates' routers, however.

Clay


David Gobaud wrote:
> Looks ok. Someone else must be sending data to your router. Also, don't 
> forget to use the rtable file sent to you in your topology email.
> 
> David Gobaud
> 
> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
> news:Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103...
>> when i run the stub code, this is all i get...
>>
>>
>> elaine27:~/cs244a/proj2/stub> ./sr -t 170 -s vns-1.stanford.edu
>> Loading routing table
>> ---------------------------------------------
>> Destination     Gateway         Mask    Iface
>> 0.0.0.0         172.24.74.17    0.0.0.0 eth0
>> ---------------------------------------------
>> Client chunkaiw connecting to Server vns-1.stanford.edu:12345
>> Requesting topology 170
>> Router interfaces:
>> eth0    HWaddr70:00:00:aa:00:01
>>        inet addr 192.168.128.84
>> eth1    HWaddr70:00:00:aa:00:02
>>        inet addr 192.168.128.85
>> eth2    HWaddr70:00:00:aa:00:06
>>        inet addr 192.168.128.87
>> <-- Ready to process packets -->
>> *** -> Received packet of length 60
>> *** -> Received packet of length 60
>> *** -> Received packet of length 60
>>
>>
>>
>> is this right? I didn't even type "ping"...
>>
>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: lent/borrow
Date: Tue, 06 Feb 2007 17:34:19 -0800
Lines: 21
Distribution: su
Message-ID: <eqbal1$dcq$2@news.Stanford.EDU>
References: <Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170812387 13722 171.64.74.54 (7 Feb 2007 01:39:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98CFAB5D42713chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11493

Nope- the comment means that the sr structure is lent to you, but 
doesn't belong to you- it's the responsibility of the code that calls 
sr_handlepacket to free the memory in those structures.

The 'borrowed' notation in sr_send_packet means that the function is 
'borrowing' the memory from the caller- the memory is not freed by 
sr_send_packet, but is still the responsibility of whoever owned it before.

Clay


Chun Kai Wang wrote:
> so im still a little confused,  for example
> 
> void sr_handlepacket(struct sr_instance* sr, 
>         uint8_t * packet/* lent */,
>         unsigned int len,
>         char* interface/* lent */)
> 
> 
> we are incharge of freeing sr right?
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: arp packet
Date: Wed, 7 Feb 2007 02:11:17 +0000 (UTC)
Organization: Your Company
Lines: 2
Distribution: su
Message-ID: <Xns98CFB90595373chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170814277 15966 128.12.22.217 (7 Feb 2007 02:11:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11494

i'm really confused... how do i distinguish between an arp packet and an IP 
packet? if i detect a version of 0, then i assume it's an arp packet???
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ANSI Requirement Update
Date: Tue, 06 Feb 2007 18:34:08 -0800
Lines: 8
Distribution: su
Message-ID: <C1EE7AA0.8217%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170815656 16883 127.0.0.1 (7 Feb 2007 02:34:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ANSI Requirement Update
Thread-Index: AcdKYHE1r/u4ZrZTEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11495

I spoke with the other TAs, and we're lifting the "-ansi" requirement.  It
seems like it has outlived its usefulness.  We'd like to see everything be
C99-compliant, but we won't go out of our way enforcing it.  Please don't do
anything too weird.  You still need to follow the other coding guidelines
and make everything compile cleanly with "-Wall".

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: define __USE_UNIX98 and cleanup code
Date: Tue, 6 Feb 2007 21:15:01 -0700
Lines: 22
Distribution: su
Message-ID: <eqbjo9$kot$1@news.Stanford.EDU>
References: <eqan4o$qu4$1@news.Stanford.EDU> <eqaq0u$v$1@news.Stanford.EDU> <eqaq2d$v$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170821706 21277 127.0.0.1 (7 Feb 2007 04:15:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11496

Hi,

I didn't see an answer to the part about cleanup code.  I assume the router 
will always be terminated with ctrl-c.  Is it really worth spending time to 
make certain everything is freed before termination?  Or is it enough to 
just never *orphan* memory during normal operation?

Thanks

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eqaq2d$v$2@news.Stanford.EDU...
> Clay Collier wrote:
>> As long as your code still compiles cleanly
>
> on the myth machines, I should have inserted here
>
>> from your Makefile with -ansi -Wall when you set these flags, using them 
>> is acceptable.
>
> Clay 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: define __USE_UNIX98 and cleanup code
Date: Tue, 06 Feb 2007 21:36:36 -0800
Lines: 27
Distribution: su
Message-ID: <eqborf$ogl$1@news.Stanford.EDU>
References: <eqan4o$qu4$1@news.Stanford.EDU> <eqaq0u$v$1@news.Stanford.EDU> <eqaq2d$v$2@news.Stanford.EDU> <eqbjo9$kot$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170826929 25109 171.64.74.54 (7 Feb 2007 05:42:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqbjo9$kot$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11497

You're not required to register signal handlers to take care of final 
cleanup- as you said, just make sure you're leaking memory while the 
proxy runs.

Clay

Kevin Hart wrote:
> Hi,
> 
> I didn't see an answer to the part about cleanup code.  I assume the router 
> will always be terminated with ctrl-c.  Is it really worth spending time to 
> make certain everything is freed before termination?  Or is it enough to 
> just never *orphan* memory during normal operation?
> 
> Thanks
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eqaq2d$v$2@news.Stanford.EDU...
>> Clay Collier wrote:
>>> As long as your code still compiles cleanly
>> on the myth machines, I should have inserted here
>>
>>> from your Makefile with -ansi -Wall when you set these flags, using them 
>>> is acceptable.
>> Clay 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Broadcast packets
Date: Tue, 06 Feb 2007 21:44:55 -0800
Lines: 6
Distribution: su
Message-ID: <eqbp0q$oij$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170827098 25171 127.0.0.1 (7 Feb 2007 05:44:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11498

If we receive a packet with destination set to Broadcast address we are 
supposed to drop it. Is it mandatory that we do the same for subnet 
broadcast packets too?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: traceroute behavior
Date: Tue, 6 Feb 2007 22:04:20 -0800
Lines: 25
Distribution: su
Message-ID: <eqbq5p$pbh$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1170828281 25969 171.64.75.59 (7 Feb 2007 06:04:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11499


Hi,

I have the following IP addresses
192.168.128.139 (connected to the firewall)
192.168.128.140 (connected to the web server 192.168.128.141)
192.168.128.142 (connected to the web server 192.168.128.143)

Question: Which IP of my router should be returned when I traceroute 
192.168.128.140
from my computer? That is, what IP should be the source IP address of the 
ICMP
packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?

The former seems reasonable because the packet is actually going through the
interface of 192.168.128.139. However, it is also true that I am 
tracerouting
192.168.128.140, not 192.168.128.139.

Best,
Steven




.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp packet
Date: Tue, 06 Feb 2007 22:11:31 -0800
Lines: 8
Distribution: su
Message-ID: <eqbqsq$ppp$1@news.Stanford.EDU>
References: <Xns98CFB90595373chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170829021 26425 171.64.74.54 (7 Feb 2007 06:17:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98CFB90595373chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11500

You need to look at the packet's Ethernet header.  Take a look at the 
structures and constants in sr_protocol.h if you need a hint, or look at 
the Ethernet header format online at the Network Sorcery site.

Clay
Chun Kai Wang wrote:
> i'm really confused... how do i distinguish between an arp packet and an IP 
> packet? if i detect a version of 0, then i assume it's an arp packet???
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Logging in reference implementation
Date: Tue, 06 Feb 2007 22:22:49 -0800
Lines: 24
Distribution: su
Message-ID: <eqbri1$q71$1@news.Stanford.EDU>
References: <eqaqso$uo$1@news.Stanford.EDU> <eqarou$1kk$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170829699 26849 171.64.74.54 (7 Feb 2007 06:28:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqarou$1kk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11501

No, logging isn't turned on for the reference router.  What makes you 
think that the message that it returns is incorrect?

Are you still having trouble with your logging?  The logging facilities 
are part of the stub code.  Unless no packets are reaching your router, 
logging should still work.

Clay
Kevin Hart wrote:
> Now I can't seem to get a log with my topology either.  What changed?  Is 
> the vns system acting up?
> 
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:eqaqso$uo$1@news.Stanford.EDU...
>> Is logging disabled on the reference router running on topology 2?  I 
>> don't think it sends the correct ICMP message when it gets a TCP/UDP 
>> packet addressed to one of its interfaces, but it's hard to verify that 
>> without a log.
>>
>> --Kevin
>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: stub code
Date: Wed, 7 Feb 2007 06:30:22 +0000 (UTC)
Organization: Your Company
Lines: 20
Distribution: su
Message-ID: <Xns98CFE4F2E869Fchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170829822 26933 128.12.22.217 (7 Feb 2007 06:30:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11502

how come i don't get the packet length debug message? all i have is:


void sr_handlepacket(struct sr_instance* sr, 
        uint8_t * packet/* lent */,
        unsigned int len,
        char* interface/* lent */)
{
    /* REQUIRES */
    assert(sr);
    assert(packet);
    assert(interface);

	if(DEBUG_MODE) printf("*** -> Received packet of length %d \n",len);

	return;



i'm not getting any output even if i ping...
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Tue, 06 Feb 2007 22:25:39 -0800
Lines: 31
Distribution: su
Message-ID: <eqbrnb$q71$2@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170829869 26849 171.64.74.54 (7 Feb 2007 06:31:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqbq5p$pbh$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11503

Try tracerouting to one of the interfaces on the reference topology 
(topo 2- I posted the corrected IPs earlier to the newsgroup).  Also, 
take a look at question 28 on the FAQ- that will help explain why the 
router behaves as it does.

Clay
Euijong Whang wrote:
> Hi,
> 
> I have the following IP addresses
> 192.168.128.139 (connected to the firewall)
> 192.168.128.140 (connected to the web server 192.168.128.141)
> 192.168.128.142 (connected to the web server 192.168.128.143)
> 
> Question: Which IP of my router should be returned when I traceroute 
> 192.168.128.140
> from my computer? That is, what IP should be the source IP address of the 
> ICMP
> packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?
> 
> The former seems reasonable because the packet is actually going through the
> interface of 192.168.128.139. However, it is also true that I am 
> tracerouting
> 192.168.128.140, not 192.168.128.139.
> 
> Best,
> Steven
> 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stub code
Date: Tue, 06 Feb 2007 22:29:32 -0800
Lines: 26
Distribution: su
Message-ID: <eqbruj$q71$3@news.Stanford.EDU>
References: <Xns98CFE4F2E869Fchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170830102 26849 171.64.74.54 (7 Feb 2007 06:35:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98CFE4F2E869Fchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11504

What output do you get when you first start the router?  Also, what IP 
address are you pinging?

Clay

Chun Kai Wang wrote:
> how come i don't get the packet length debug message? all i have is:
> 
> 
> void sr_handlepacket(struct sr_instance* sr, 
>         uint8_t * packet/* lent */,
>         unsigned int len,
>         char* interface/* lent */)
> {
>     /* REQUIRES */
>     assert(sr);
>     assert(packet);
>     assert(interface);
> 
> 	if(DEBUG_MODE) printf("*** -> Received packet of length %d \n",len);
> 
> 	return;
> 
> 
> 
> i'm not getting any output even if i ping...
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Tue, 6 Feb 2007 22:40:18 -0800
Lines: 40
Distribution: su
Message-ID: <eqbs97$r0v$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1170830439 27679 171.64.75.59 (7 Feb 2007 06:40:39 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11505


OK, so the first case is correct.
Thanks,
Steven


"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eqbrnb$q71$2@news.Stanford.EDU...
> Try tracerouting to one of the interfaces on the reference topology (topo 
> 2- I posted the corrected IPs earlier to the newsgroup).  Also, take a 
> look at question 28 on the FAQ- that will help explain why the router 
> behaves as it does.
>
> Clay
> Euijong Whang wrote:
>> Hi,
>>
>> I have the following IP addresses
>> 192.168.128.139 (connected to the firewall)
>> 192.168.128.140 (connected to the web server 192.168.128.141)
>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>
>> Question: Which IP of my router should be returned when I traceroute 
>> 192.168.128.140
>> from my computer? That is, what IP should be the source IP address of the 
>> ICMP
>> packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?
>>
>> The former seems reasonable because the packet is actually going through 
>> the
>> interface of 192.168.128.139. However, it is also true that I am 
>> tracerouting
>> 192.168.128.140, not 192.168.128.139.
>>
>> Best,
>> Steven
>>
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Logging in reference implementation
Date: Tue, 6 Feb 2007 23:45:52 -0700
Lines: 37
Distribution: su
Message-ID: <eqbsj3$r7p$1@news.Stanford.EDU>
References: <eqaqso$uo$1@news.Stanford.EDU> <eqarou$1kk$1@news.Stanford.EDU> <eqbri1$q71$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170830755 27897 127.0.0.1 (7 Feb 2007 06:45:55 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11506

If I'm interpreting the requirements correctly, we're supposed to send 
"protocol unreachable" if a TCP or UDP packet is addressed to a router 
interface.  When you do that, and then telnet into one of your interfaces 
for, say, an HTTP session, the telnet message is "protocol not available." 
But in the reference implementation, the telnet message is "connection 
refused."  I think I'm sending the correct message b/c it's the one that's 
supposed to be sent when the designated transport protocol is not 
supported....  (?)

--Kevin

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eqbri1$q71$1@news.Stanford.EDU...
> No, logging isn't turned on for the reference router.  What makes you 
> think that the message that it returns is incorrect?
>
> Are you still having trouble with your logging?  The logging facilities 
> are part of the stub code.  Unless no packets are reaching your router, 
> logging should still work.
>
> Clay
> Kevin Hart wrote:
>> Now I can't seem to get a log with my topology either.  What changed?  Is 
>> the vns system acting up?
>>
>> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
>> news:eqaqso$uo$1@news.Stanford.EDU...
>>> Is logging disabled on the reference router running on topology 2?  I 
>>> don't think it sends the correct ICMP message when it gets a TCP/UDP 
>>> packet addressed to one of its interfaces, but it's hard to verify that 
>>> without a log.
>>>
>>> --Kevin
>>>
>>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Logging in reference implementation
Date: Tue, 6 Feb 2007 23:57:25 -0700
Lines: 48
Distribution: su
Message-ID: <eqbt8o$rp9$1@news.Stanford.EDU>
References: <eqaqso$uo$1@news.Stanford.EDU> <eqarou$1kk$1@news.Stanford.EDU> <eqbri1$q71$1@news.Stanford.EDU> <eqbsj3$r7p$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170831448 28457 127.0.0.1 (7 Feb 2007 06:57:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11507

It must be that the reference implementation sends "port unreachable" 
instead of "protocol unreachable."  Is port unreachable the one you want us 
to send in this instance?  Protocol unreachable would seem more appropriate, 
but I'm not going to lose sleep over it...

--Kevin

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:eqbsj3$r7p$1@news.Stanford.EDU...
> If I'm interpreting the requirements correctly, we're supposed to send 
> "protocol unreachable" if a TCP or UDP packet is addressed to a router 
> interface.  When you do that, and then telnet into one of your interfaces 
> for, say, an HTTP session, the telnet message is "protocol not available." 
> But in the reference implementation, the telnet message is "connection 
> refused."  I think I'm sending the correct message b/c it's the one that's 
> supposed to be sent when the designated transport protocol is not 
> supported....  (?)
>
> --Kevin
>
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eqbri1$q71$1@news.Stanford.EDU...
>> No, logging isn't turned on for the reference router.  What makes you 
>> think that the message that it returns is incorrect?
>>
>> Are you still having trouble with your logging?  The logging facilities 
>> are part of the stub code.  Unless no packets are reaching your router, 
>> logging should still work.
>>
>> Clay
>> Kevin Hart wrote:
>>> Now I can't seem to get a log with my topology either.  What changed? 
>>> Is the vns system acting up?
>>>
>>> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
>>> news:eqaqso$uo$1@news.Stanford.EDU...
>>>> Is logging disabled on the reference router running on topology 2?  I 
>>>> don't think it sends the correct ICMP message when it gets a TCP/UDP 
>>>> packet addressed to one of its interfaces, but it's hard to verify that 
>>>> without a log.
>>>>
>>>> --Kevin
>>>>
>>>>
>>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Logging in reference implementation
Date: Wed, 07 Feb 2007 00:03:37 -0800
Lines: 52
Distribution: su
Message-ID: <eqc1f4$57c$1@news.Stanford.EDU>
References: <eqaqso$uo$1@news.Stanford.EDU> <eqarou$1kk$1@news.Stanford.EDU> <eqbri1$q71$1@news.Stanford.EDU> <eqbsj3$r7p$1@news.Stanford.EDU> <eqbt8o$rp9$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170835750 5356 171.64.74.54 (7 Feb 2007 08:09:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqbt8o$rp9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11508

Per the FAQ, you should be sending 'port unreachable' rather than 
'protocol unreachable'.  This may seem a little odd in light of the RFC, 
but it will make more sense during assignment 4.

Clay
Kevin Hart wrote:
> It must be that the reference implementation sends "port unreachable" 
> instead of "protocol unreachable."  Is port unreachable the one you want us 
> to send in this instance?  Protocol unreachable would seem more appropriate, 
> but I'm not going to lose sleep over it...
> 
> --Kevin
> 
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:eqbsj3$r7p$1@news.Stanford.EDU...
>> If I'm interpreting the requirements correctly, we're supposed to send 
>> "protocol unreachable" if a TCP or UDP packet is addressed to a router 
>> interface.  When you do that, and then telnet into one of your interfaces 
>> for, say, an HTTP session, the telnet message is "protocol not available." 
>> But in the reference implementation, the telnet message is "connection 
>> refused."  I think I'm sending the correct message b/c it's the one that's 
>> supposed to be sent when the designated transport protocol is not 
>> supported....  (?)
>>
>> --Kevin
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:eqbri1$q71$1@news.Stanford.EDU...
>>> No, logging isn't turned on for the reference router.  What makes you 
>>> think that the message that it returns is incorrect?
>>>
>>> Are you still having trouble with your logging?  The logging facilities 
>>> are part of the stub code.  Unless no packets are reaching your router, 
>>> logging should still work.
>>>
>>> Clay
>>> Kevin Hart wrote:
>>>> Now I can't seem to get a log with my topology either.  What changed? 
>>>> Is the vns system acting up?
>>>>
>>>> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
>>>> news:eqaqso$uo$1@news.Stanford.EDU...
>>>>> Is logging disabled on the reference router running on topology 2?  I 
>>>>> don't think it sends the correct ICMP message when it gets a TCP/UDP 
>>>>> packet addressed to one of its interfaces, but it's hard to verify that 
>>>>> without a log.
>>>>>
>>>>> --Kevin
>>>>>
>>>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 00:22:48 -0800
Lines: 54
Distribution: su
Message-ID: <eqc291$67v$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170836577 6399 128.12.81.44 (7 Feb 2007 08:22:57 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11509

Hey,

I tested traceroute against topo 2

traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 ms 
(ttl=63!)  0.227 ms (ttl=63!)
 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>

I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 and 
..23 respectively.

I read the RFC and the FAQ and am still confused.

-- 
David Gobaud

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eqbrnb$q71$2@news.Stanford.EDU...
> Try tracerouting to one of the interfaces on the reference topology (topo 
> 2- I posted the corrected IPs earlier to the newsgroup).  Also, take a 
> look at question 28 on the FAQ- that will help explain why the router 
> behaves as it does.
>
> Clay
> Euijong Whang wrote:
>> Hi,
>>
>> I have the following IP addresses
>> 192.168.128.139 (connected to the firewall)
>> 192.168.128.140 (connected to the web server 192.168.128.141)
>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>
>> Question: Which IP of my router should be returned when I traceroute 
>> 192.168.128.140
>> from my computer? That is, what IP should be the source IP address of the 
>> ICMP
>> packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?
>>
>> The former seems reasonable because the packet is actually going through 
>> the
>> interface of 192.168.128.139. However, it is also true that I am 
>> tracerouting
>> 192.168.128.140, not 192.168.128.139.
>>
>> Best,
>> Steven
>>
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stub code
Date: Wed, 07 Feb 2007 01:43:26 -0800
Lines: 58
Distribution: su
Message-ID: <eqc6vt$9kh$1@news.Stanford.EDU>
References: <Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103> <eqb6d9$9tn$1@news.Stanford.EDU> <eqba6k$dcq$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170841405 9873 128.12.194.72 (7 Feb 2007 09:43:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eqba6k$dcq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11510

Clay, it's probably the firewall sending ARP packets to his router. Even 
if it has no packets to send, the firewall seems to get curious once in 
a while. :)

Just fyi.

-Yangfan

Clay Collier wrote:
> Yup- it's entirely possible that someone might send packets to one of 
> the IPs on your topology.  It's likely that it's just someone who typoed 
> an IP address, but it could be on purpose.  No extra credit for crashing 
> your classmates' routers, however.
> 
> Clay
> 
> 
> David Gobaud wrote:
> 
>> Looks ok. Someone else must be sending data to your router. Also, 
>> don't forget to use the rtable file sent to you in your topology email.
>>
>> David Gobaud
>>
>> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
>> news:Xns98CFA35671D11chunkaiwstanfordedu@171.64.14.103...
>>
>>> when i run the stub code, this is all i get...
>>>
>>>
>>> elaine27:~/cs244a/proj2/stub> ./sr -t 170 -s vns-1.stanford.edu
>>> Loading routing table
>>> ---------------------------------------------
>>> Destination     Gateway         Mask    Iface
>>> 0.0.0.0         172.24.74.17    0.0.0.0 eth0
>>> ---------------------------------------------
>>> Client chunkaiw connecting to Server vns-1.stanford.edu:12345
>>> Requesting topology 170
>>> Router interfaces:
>>> eth0    HWaddr70:00:00:aa:00:01
>>>        inet addr 192.168.128.84
>>> eth1    HWaddr70:00:00:aa:00:02
>>>        inet addr 192.168.128.85
>>> eth2    HWaddr70:00:00:aa:00:06
>>>        inet addr 192.168.128.87
>>> <-- Ready to process packets -->
>>> *** -> Received packet of length 60
>>> *** -> Received packet of length 60
>>> *** -> Received packet of length 60
>>>
>>>
>>>
>>> is this right? I didn't even type "ping"...
>>>
>>>
>>>
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stub code
Date: Wed, 7 Feb 2007 10:13:25 +0000 (UTC)
Organization: Your Company
Lines: 33
Distribution: su
Message-ID: <Xns98D016A00A8ADchunkaiwstanfordedu@171.64.14.103>
References: <Xns98CFE4F2E869Fchunkaiwstanfordedu@171.64.14.103> <eqbruj$q71$3@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170843205 11024 128.12.22.217 (7 Feb 2007 10:13:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11511

its working now.

Clay Collier <ccollier@stanford.edu> wrote in
news:eqbruj$q71$3@news.Stanford.EDU: 

> What output do you get when you first start the router?  Also, what IP
> address are you pinging?
> 
> Clay
> 
> Chun Kai Wang wrote:
>> how come i don't get the packet length debug message? all i have is:
>> 
>> 
>> void sr_handlepacket(struct sr_instance* sr, 
>>         uint8_t * packet/* lent */,
>>         unsigned int len,
>>         char* interface/* lent */)
>> {
>>     /* REQUIRES */
>>     assert(sr);
>>     assert(packet);
>>     assert(interface);
>> 
>>      if(DEBUG_MODE) printf("*** -> Received packet of length %d
>>      \n",len); 
>> 
>>      return;
>> 
>> 
>> 
>> i'm not getting any output even if i ping...

.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 7 Feb 2007 04:57:40 -0800
Lines: 34
Distribution: su
Message-ID: <Pine.LNX.4.44.0702070455370.17157-100000@myth20.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU>
 <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170853061 20274 171.64.15.38 (7 Feb 2007 12:57:41 GMT)
X-Complaints-To: news@news.stanford.edu
To: Justin Pettit <jpettit@stanford.edu>
In-Reply-To: <C1E6F110.7EC6%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11512

I think ARP RFC specifies that the original packet is to be dropped at ARP
cache miss with ICMP message sent to the source. I think this constrasts
with your reply.

Also, when I send ARP request, do I need to broadcast it? I thought
broadcasting was not required, but ARP RFC says so. What method should I
use to send out ARP request?


Thanks,
-Seung


On Thu, 1 Feb 2007, Justin Pettit wrote:

> > I only send ARP requests on an ARP cache miss, right?
>
> Correct.
>
> > Also, is it okay to simply drop the packet on the first time there is a
> > cache miss for each IP address? (I'd then send an ARP request for the
> > corresponding MAC address and hopefully have the cache entry for it the
> > next time a packet arrives.)
>
> That wouldn't be very nice to the poor source that took the time to generate
> the packet.  No, you must hold onto the packet until you decide what to do
> with it.  If you don't get an ARP reply, you'll use the IP header and first
> 64-bytes of data into unreachable message.
>
> --Justin
>
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Accepting ARP replies
Date: Wed, 07 Feb 2007 07:12:57 -0800
Lines: 45
Distribution: su
Message-ID: <45C9EC79.5090809@stanford.edu>
References: <epmnem$iea$1@news.Stanford.EDU> <epmpbm$jn0$2@news.Stanford.EDU> <epp8s4$24d$1@news.Stanford.EDU> <C1E57D37.7E48%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170861180 27133 127.0.0.1 (7 Feb 2007 15:13:00 GMT)
X-Complaints-To: news@news.stanford.edu
To: Justin Pettit <jpettit@stanford.edu>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1E57D37.7E48%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11513

RFC naively adds the entry to the cache, which may be insecure, but is 
such behavior incorrect?

Thanks,
-Seung

Justin Pettit 쓴 글:
> There are obvious performance advantages to caching information that you may
> not have requested.  However, most modern systems do not accept these for
> security reasons.  There are a number of very serious ARP and DNS poisoning
> attacks that were a big deal a few years ago.  By flooding the network with
> fake responses, the attacker can redirect traffic to his/her system.
> 
> --Justin
> 
> 
> On 1/30/07 9:19 PM, in article epp8s4$24d$1@news.Stanford.EDU, "Randy
> Jennings" <randyj@stanford.edu> wrote:
> 
>> Whether you have record of sending the ARP request determines if you will be
>> sending a packet because of the response, but should you put the IP-MAC in
>> your arp cache?  I can see arguments both ways...
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>> "David Erickson" <derickso@stanford.edu> wrote in message
>> news:epmpbm$jn0$2@news.Stanford.EDU...
>>> Matt Page wrote:
>>>> Do we need to maintain a list of arp requests that we've transmitted?
>>>> Suppose we receive an arp reply for which for did not send an arp
>>>> request? I'm assuming normally we would discard the packet, but can we
>>>> assume that this wont happen?
>>>>
>>>> Thanks,
>>>> Matt
>>> For timeout purposes you should already be maintaining a list of who you
>>> have sent ARP requests for, so I would say you should check that when you
>>> get a reply that it is a reply for a request you have sent.
>>>
>>> -David 
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Default Route...
Date: Wed, 07 Feb 2007 07:17:30 -0800
Lines: 30
Distribution: su
Message-ID: <45C9ED8A.6090506@stanford.edu>
References: <epsa6g$dms$1@news.Stanford.EDU> <C1E7676E.7EDE%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170861450 27133 127.0.0.1 (7 Feb 2007 15:17:30 GMT)
X-Complaints-To: news@news.stanford.edu
To: Justin Pettit <jpettit@stanford.edu>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <C1E7676E.7EDE%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11514

If a packet is received from, say eth0, can/should a router forward it 
back to the same interface?

Currently, I don't allow such back-forwarding, b/c I don't see how 
that's useful. What should be the correct behavior?


Thanks,
-Seung


Justin Pettit 쓴 글:
> The only case I can think of is when the packet's destination is in the
> router's collision domain, but it couldn't determine the destination's
> hardware address.  This could happen because no machine has that IP address
> or the one that does is down.
> 
> --Justin
> 
> 
> On 2/1/07 12:59 AM, in article epsa6g$dms$1@news.Stanford.EDU, "Matt Page"
> <mpage@stanford.edu> wrote:
> 
>> Given the presence of a default route, how can we determine if a packet
>> has an unknown next hop address?
>>
>> Thanks,
>> Matt
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Accepting ARP replies
Date: Wed, 07 Feb 2007 08:32:34 -0800
Lines: 56
Distribution: su
Message-ID: <C1EF3F22.825F%jpettit@stanford.edu>
References: <epmnem$iea$1@news.Stanford.EDU> <epmpbm$jn0$2@news.Stanford.EDU> <epp8s4$24d$1@news.Stanford.EDU> <C1E57D37.7E48%jpettit@stanford.edu> <45C9EC79.5090809@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="EUC-KR"
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170865957 553 127.0.0.1 (7 Feb 2007 16:32:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Accepting ARP replies
Thread-Index: AcdK1ZHr0KUwt7bIEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11515

In my opinion, it's not a good idea for a system to do this.  However, most
systems seem to do it, so you can, too.

--Justin


On 2/7/07 7:12 AM, in article 45C9EC79.5090809@stanford.edu, "Seung H. Choi"
<shchoi@stanford.edu> wrote:

> RFC naively adds the entry to the cache, which may be insecure, but is
> such behavior incorrect?
> 
> Thanks,
> -Seung
> 
> Justin Pettit ¾´ ±Û:
>> There are obvious performance advantages to caching information that you may
>> not have requested.  However, most modern systems do not accept these for
>> security reasons.  There are a number of very serious ARP and DNS poisoning
>> attacks that were a big deal a few years ago.  By flooding the network with
>> fake responses, the attacker can redirect traffic to his/her system.
>> 
>> --Justin
>> 
>> 
>> On 1/30/07 9:19 PM, in article epp8s4$24d$1@news.Stanford.EDU, "Randy
>> Jennings" <randyj@stanford.edu> wrote:
>> 
>>> Whether you have record of sending the ARP request determines if you will be
>>> sending a packet because of the response, but should you put the IP-MAC in
>>> your arp cache?  I can see arguments both ways...
>>> 
>>> Sincerely,
>>> Randy Jennings
>>> 
>>> The squirrels are your friends!
>>> "David Erickson" <derickso@stanford.edu> wrote in message
>>> news:epmpbm$jn0$2@news.Stanford.EDU...
>>>> Matt Page wrote:
>>>>> Do we need to maintain a list of arp requests that we've transmitted?
>>>>> Suppose we receive an arp reply for which for did not send an arp
>>>>> request? I'm assuming normally we would discard the packet, but can we
>>>>> assume that this wont happen?
>>>>> 
>>>>> Thanks,
>>>>> Matt
>>>> For timeout purposes you should already be maintaining a list of who you
>>>> have sent ARP requests for, so I would say you should check that when you
>>>> get a reply that it is a reply for a request you have sent.
>>>> 
>>>> -David 
>>> 
>> 
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 07 Feb 2007 08:35:52 -0800
Lines: 38
Distribution: su
Message-ID: <C1EF3FE8.8262%jpettit@stanford.edu>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU> <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu> <Pine.LNX.4.44.0702070455370.17157-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170866154 585 127.0.0.1 (7 Feb 2007 16:35:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp requests
Thread-Index: AcdK1gfwRmEGA7bJEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11516

> I think ARP RFC specifies that the original packet is to be dropped at ARP
> cache miss with ICMP message sent to the source. I think this constrasts
> with your reply.

Can you point me to where it says that in the RFC?

> Also, when I send ARP request, do I need to broadcast it? I thought
> broadcasting was not required, but ARP RFC says so. What method should I
> use to send out ARP request?

You should broadcast it out the interface that matches the route.

--Justin

 
> On Thu, 1 Feb 2007, Justin Pettit wrote:
> 
>>> I only send ARP requests on an ARP cache miss, right?
>> 
>> Correct.
>> 
>>> Also, is it okay to simply drop the packet on the first time there is a
>>> cache miss for each IP address? (I'd then send an ARP request for the
>>> corresponding MAC address and hopefully have the cache entry for it the
>>> next time a packet arrives.)
>> 
>> That wouldn't be very nice to the poor source that took the time to generate
>> the packet.  No, you must hold onto the packet until you decide what to do
>> with it.  If you don't get an ARP reply, you'll use the IP header and first
>> 64-bytes of data into unreachable message.
>> 
>> --Justin
>> 
>> 
>> 
> 


.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 7 Feb 2007 10:43:53 -0800
Lines: 63
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071030170.32666-100000@myth20.Stanford.EDU>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU>
 <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu>
 <Pine.LNX.4.44.0702070455370.17157-100000@myth20.Stanford.EDU>
 <C1EF3FE8.8262%jpettit@stanford.edu>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170873834 7002 171.64.15.38 (7 Feb 2007 18:43:54 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <C1EF3FE8.8262%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11517


On Wed, 7 Feb 2007, Justin Pettit wrote:

> > I think ARP RFC specifies that the original packet is to be dropped at ARP
> > cache miss with ICMP message sent to the source. I think this constrasts
> > with your reply.
>
> Can you point me to where it says that in the RFC?

In ARP RFC section "Packet Generation", it says
" The Address Resolution module
tries to find this pair in a table.  If it finds the pair, it
gives the corresponding 48.bit Ethernet address back to the
caller (hardware driver) which then transmits the packet.  If it
does not, it probably informs the caller that it is throwing the
packet away (on the assumption the packet will be retransmitted
by a higher network layer), and generates an Ethernet packet with
a type field of ether_type$ADDRESS_RESOLUTION."


>
> > Also, when I send ARP request, do I need to broadcast it? I thought
> > broadcasting was not required, but ARP RFC says so. What method should I
> > use to send out ARP request?
>
> You should broadcast it out the interface that matches the route.

Other than filling the destination MAC to FFFFFF, is there anything
special that has to be done to broadcast the packet?

Thanks,
-Seung


>
> --Justin
>
>
> > On Thu, 1 Feb 2007, Justin Pettit wrote:
> >
> >>> I only send ARP requests on an ARP cache miss, right?
> >>
> >> Correct.
> >>
> >>> Also, is it okay to simply drop the packet on the first time there is a
> >>> cache miss for each IP address? (I'd then send an ARP request for the
> >>> corresponding MAC address and hopefully have the cache entry for it the
> >>> next time a packet arrives.)
> >>
> >> That wouldn't be very nice to the poor source that took the time to generate
> >> the packet.  No, you must hold onto the packet until you decide what to do
> >> with it.  If you don't get an ARP reply, you'll use the IP header and first
> >> 64-bytes of data into unreachable message.
> >>
> >> --Justin
> >>
> >>
> >>
> >
>
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: arp requests
Date: Wed, 07 Feb 2007 11:03:28 -0800
Lines: 29
Distribution: su
Message-ID: <C1EF6280.8280%jpettit@stanford.edu>
References: <eprt6i$pok$1@news.Stanford.EDU> <eprti8$qan$1@news.Stanford.EDU> <eprvjr$sj9$1@news.Stanford.EDU> <C1E6F110.7EC6%jpettit@stanford.edu> <Pine.LNX.4.44.0702070455370.17157-100000@myth20.Stanford.EDU> <C1EF3FE8.8262%jpettit@stanford.edu> <Pine.LNX.4.44.0702071030170.32666-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170875011 7960 127.0.0.1 (7 Feb 2007 19:03:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: arp requests
Thread-Index: AcdK6qaG5VDV07bdEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11518

>> > I think ARP RFC specifies that the original packet is to be dropped at ARP
>> > cache miss with ICMP message sent to the source. I think this constrasts
>> > with your reply.
>>
>> Can you point me to where it says that in the RFC?
>
> In ARP RFC section "Packet Generation", it says
> " The Address Resolution module
> tries to find this pair in a table.  If it finds the pair, it
> gives the corresponding 48.bit Ethernet address back to the
> caller (hardware driver) which then transmits the packet.  If it
> does not, it probably informs the caller that it is throwing the
> packet away (on the assumption the packet will be retransmitted
> by a higher network layer), and generates an Ethernet packet with
> a type field of ether_type$ADDRESS_RESOLUTION."

It's not saying that you should throw the packet away.  When the RFC was
written, memory was much more constrained, so it may have seemed reasonable
to simply toss out the packet.  I don't think that is common practice now.
Regardless, storing the packet while waiting for an ARP reply is listed in
the "Required Functionality" section of the assignment.

> Other than filling the destination MAC to FFFFFF, is there anything
> special that has to be done to broadcast the packet?

Nope, that's it.

--Justin

.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Time guarantee
Date: Wed, 7 Feb 2007 12:15:30 -0800
Lines: 14
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170879332 11279 171.64.15.38 (7 Feb 2007 20:15:32 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11519


Hi,

What implementation techniques are recommended for fulfilling time
guarantee? I've seen posts about threads on the bboard, which seems like a
good idea, but is it okay to spawn a thread for each packet that the
router receives?


Thanks,
-Seung



.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Time guarantee
Date: Wed, 07 Feb 2007 13:05:30 -0800
Lines: 20
Distribution: su
Message-ID: <eqdeuq$dlv$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170882330 14015 127.0.0.1 (7 Feb 2007 21:05:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11520

Seung Hoon Choi wrote:
> Hi,
> 
> What implementation techniques are recommended for fulfilling time
> guarantee? I've seen posts about threads on the bboard, which seems like a
> good idea, but is it okay to spawn a thread for each packet that the
> router receives?
> 
> 
> Thanks,
> -Seung
> 
> 
> 
One thread that polls at regular intervals checking for actions that 
need to be performed on the arp cache should be sufficient.  But as has 
been stated there are many ways to go about this, just remember to 
document your choice in the readme.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Time guarantee
Date: Wed, 07 Feb 2007 13:14:26 -0800
Lines: 30
Distribution: su
Message-ID: <eqdffh$e3k$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU> <eqdeuq$dlv$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170882865 14452 127.0.0.1 (7 Feb 2007 21:14:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqdeuq$dlv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11521

David Erickson wrote:
> Seung Hoon Choi wrote:
>> Hi,
>>
>> What implementation techniques are recommended for fulfilling time
>> guarantee? I've seen posts about threads on the bboard, which seems 
>> like a
>> good idea, but is it okay to spawn a thread for each packet that the
>> router receives?
>>
>>
>> Thanks,
>> -Seung
>>
>>
>>
> One thread that polls at regular intervals checking for actions that 
> need to be performed on the arp cache should be sufficient.  But as has 
> been stated there are many ways to go about this, just remember to 
> document your choice in the readme.
> 
> -David

I should have been slightly more explicit on my previous response, do 
not spawn a thread or fork a process per packet, that is very bad form 
and could overload a system quickly.  When you are making design 
decisions you must evaluate how well your design is going to work under 
the worst case situations.

-David
.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Time guarantee
Date: Wed, 7 Feb 2007 13:19:06 -0800
Lines: 42
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071312100.8120-100000@myth20.Stanford.EDU>
References: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU>
 <eqdeuq$dlv$1@news.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170883147 14687 171.64.15.38 (7 Feb 2007 21:19:07 GMT)
X-Complaints-To: news@news.stanford.edu
To: David Erickson <derickso@stanford.edu>
In-Reply-To: <eqdeuq$dlv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11522


On Wed, 7 Feb 2007, David Erickson wrote:

> Seung Hoon Choi wrote:
> > Hi,
> >
> > What implementation techniques are recommended for fulfilling time
> > guarantee? I've seen posts about threads on the bboard, which seems like a
> > good idea, but is it okay to spawn a thread for each packet that the
> > router receives?
> >
> >
> > Thanks,
> > -Seung
> >
> >
> >
> One thread that polls at regular intervals checking for actions that
> need to be performed on the arp cache should be sufficient.  But as has
> been stated there are many ways to go about this, just remember to
> document your choice in the readme.
>
> -David
>
I don't see how that's sufficient for ARP queue though. Say I got a packet
and sent ARP request. While this is happening, I need to put subsequent
packets to a queue, which needs to happen concurrently to waiting for ARP
reply. Is that right? So potentially, I belive that more threads are
needed to handle this properly in addition to ARP cache thread. Another
concern is that if we don't get ARP reply, which we waited for around 5
seconds, and if ARP request subsequent packets fail as well, the queued
packets need to wait for a very long time, which prompted me to thread per
packet design. But I think thread/packet is too heavy, but I can't think
of a design that will allow efficient handling of packets with low
overhead.


Thanks,
-Seung



.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Time guarantee
Date: Wed, 07 Feb 2007 13:24:47 -0800
Lines: 49
Distribution: su
Message-ID: <eqdg2v$ehu$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071211260.5958-100000@myth20.Stanford.EDU> <eqdeuq$dlv$1@news.Stanford.EDU> <Pine.LNX.4.44.0702071312100.8120-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170883487 14910 127.0.0.1 (7 Feb 2007 21:24:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.LNX.4.44.0702071312100.8120-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11523

Seung Hoon Choi wrote:
> On Wed, 7 Feb 2007, David Erickson wrote:
> 
>> Seung Hoon Choi wrote:
>>> Hi,
>>>
>>> What implementation techniques are recommended for fulfilling time
>>> guarantee? I've seen posts about threads on the bboard, which seems like a
>>> good idea, but is it okay to spawn a thread for each packet that the
>>> router receives?
>>>
>>>
>>> Thanks,
>>> -Seung
>>>
>>>
>>>
>> One thread that polls at regular intervals checking for actions that
>> need to be performed on the arp cache should be sufficient.  But as has
>> been stated there are many ways to go about this, just remember to
>> document your choice in the readme.
>>
>> -David
>>
> I don't see how that's sufficient for ARP queue though. Say I got a packet
> and sent ARP request. While this is happening, I need to put subsequent
> packets to a queue, which needs to happen concurrently to waiting for ARP
> reply. 

So why can't your receiving thread send the arp request, put the packet 
in queue then return?  And on any future packets that are dependent on 
that arp request, just queue them as well?

>Is that right? So potentially, I belive that more threads are
> needed to handle this properly in addition to ARP cache thread. Another
> concern is that if we don't get ARP reply, which we waited for around 5
> seconds, and if ARP request subsequent packets fail as well, the queued
> packets need to wait for a very long time, which prompted me to thread per
> packet design. But I think thread/packet is too heavy, but I can't think
> of a design that will allow efficient handling of packets with low
> overhead.

You should only wait a total of around 5 seconds for ALL your Arp 
requests, not just a single one, so by the time around 5 seconds is up 
you have sent 5 arp requests and gotten no reply from any of them.  At 
which point you send icmp replies for all the packets queue'd that are 
depending on that arp lookup.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: checksum & TTL
Date: Wed, 7 Feb 2007 23:34:05 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98D09E5F19512chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170891245 22658 128.12.22.217 (7 Feb 2007 23:34:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11524

is it true that if a packet has a wrong checksum i should drop it no matter 
what kind? (ARP, ICMP, IP, etc)




also, if the TTL is less than 0, the only time this is ok is if the packet 
is an ICMP echo right?
.

Path: shelby.stanford.edu!myth15.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: How to use web browser to test if I am remote?
Date: Wed, 7 Feb 2007 16:06:49 -0800
Lines: 14
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170893213 24461 171.64.15.56 (8 Feb 2007 00:06:53 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11525


If I remote log in to myths, I am guessing I won't be able to launch a
local browser? (I am using Exceed, and it doesn't seem to work) I am a
remote student, so I can't come in to the labs...

The assignment mentions that if my router is implemented correctly, I
should be able to download the posted files from the application servers?
Is there a way I can test it using command line? I have tried using
"telnet" to one of the application servers, but it seems to be giving me a
connection refused error message.

Any pointer as to how to test the download from application servers is
appreciated. Thanks.

.

Path: shelby.stanford.edu!myth15.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [PA2] ICMP checksum in wireshark
Date: Wed, 7 Feb 2007 16:13:58 -0800
Lines: 10
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071611260.24823-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170893641 24873 171.64.15.56 (8 Feb 2007 00:14:01 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11526

It seems to me that in wireshark, the ICMP checksum is correct when you
calculate the ICMP checksum using "only" the ICMP header, which is the
first 8 bytes, but not the body.

But in the newsgroup it seems to be mentioning that ICMP checksum should
include both header and body
(differing from IP header checksum). But I seem to be seeing wireshark
reporting this calculated checksum is rather incorrect. Can TA verify?
Thanks.

.

Path: shelby.stanford.edu!myth15.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] ICMP checksum in wireshark
Date: Wed, 7 Feb 2007 16:17:05 -0800
Lines: 16
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071616120.25135-100000@myth15.Stanford.EDU>
References: <Pine.LNX.4.44.0702071611260.24823-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170893827 25024 171.64.15.56 (8 Feb 2007 00:17:07 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.44.0702071611260.24823-100000@myth15.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11527

Actually, I am sorry, please IGNORE this! Nevermind.

On Wed, 7 Feb 2007, Ryan Chen wrote:

> It seems to me that in wireshark, the ICMP checksum is correct when you
> calculate the ICMP checksum using "only" the ICMP header, which is the
> first 8 bytes, but not the body.
>
> But in the newsgroup it seems to be mentioning that ICMP checksum should
> include both header and body
> (differing from IP header checksum). But I seem to be seeing wireshark
> reporting this calculated checksum is rather incorrect. Can TA verify?
> Thanks.
>
>

.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: 2 packets to the same destination
Date: Wed, 7 Feb 2007 16:26:00 -0800
Lines: 14
Distribution: su
Message-ID: <Pine.LNX.4.44.0702071623390.13529-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170894361 25516 171.64.15.38 (8 Feb 2007 00:26:01 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11528


Hi,


Supposed there are two packets to the same destination, and router sends
ARP request, but doesn't get a response. If both packets are in the queue
waiting, how many ICMP host unreachable messages should be sent to the
originator? What if the second packet arrives after ICMP message?


Thanks,
-Seung


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use web browser to test if I am remote?
Date: Wed, 07 Feb 2007 16:43:21 -0800
Lines: 34
Distribution: su
Message-ID: <C1EFB229.82A8%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170895404 26369 127.0.0.1 (8 Feb 2007 00:43:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: How to use web browser to test if I am remote?
Thread-Index: AcdLGiGzYIF8O7cNEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11529

You should be able to launch a web browser using X tunneled through SSH.
You may need to use the "-Y" flag:

    ssh -Y user@myth.stanford.edu

If that doesn't work, you can use a text-based browser, like lynx:

    lynx www.yahoo.com

Obviously, you would replace "www.yahoo.com" with your local web server.

--Justin


On 2/7/07 4:06 PM, in article
Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU, "Ryan Chen"
<ryanchen@stanford.edu> wrote:

> 
> If I remote log in to myths, I am guessing I won't be able to launch a
> local browser? (I am using Exceed, and it doesn't seem to work) I am a
> remote student, so I can't come in to the labs...
> 
> The assignment mentions that if my router is implemented correctly, I
> should be able to download the posted files from the application servers?
> Is there a way I can test it using command line? I have tried using
> "telnet" to one of the application servers, but it seems to be giving me a
> connection refused error message.
> 
> Any pointer as to how to test the download from application servers is
> appreciated. Thanks.
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: checksum & TTL
Date: Wed, 7 Feb 2007 16:45:32 -0800
Lines: 17
Distribution: su
Message-ID: <eqdrps$ppd$1@news.Stanford.EDU>
References: <Xns98D09E5F19512chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1170895484 26413 127.0.0.1 (8 Feb 2007 00:44:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11530

> is it true that if a packet has a wrong checksum i should drop it no 
> matter
> what kind? (ARP, ICMP, IP, etc)
Depends on whether you are forwarding it and what layer the incorrect 
checksum is.  (BTW, checksum in ARP?)

> also, if the TTL is less than 0, the only time this is ok is if the packet
> is an ICMP echo right?
I would check the FAQ/Assignment a little closer on this one (how are you 
going to get a negative TTL?).

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use web browser to test if I am remote?
Date: Wed, 7 Feb 2007 16:47:57 -0800
Lines: 19
Distribution: su
Message-ID: <eqdrue$pt4$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170895630 26532 127.0.0.1 (8 Feb 2007 00:47:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11531

> If I remote log in to myths, I am guessing I won't be able to launch a
> local browser? (I am using Exceed, and it doesn't seem to work) I am a
> remote student, so I can't come in to the labs...
If you cannot get Exceed to work, I would suggest using cygwin, as XFree 
does allow you to bring up firefox.  I have posted about cygwin before.

> The assignment mentions that if my router is implemented correctly, I
> should be able to download the posted files from the application servers?
> Is there a way I can test it using command line? I have tried using
> "telnet" to one of the application servers, but it seems to be giving me a
> connection refused error message.
If the browser thing is too much of a hastle, you could use wget...

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: 2 packets to the same destination
Date: Wed, 7 Feb 2007 16:49:58 -0800
Lines: 25
Distribution: su
Message-ID: <eqds27$pvo$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071623390.13529-100000@myth20.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170895751 26616 127.0.0.1 (8 Feb 2007 00:49:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11532

There have been quite a few of threads about this, one or two of which have 
been helpful.  I suggest you search the newsgroup for ARP.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Seung Hoon Choi" <shchoi@stanford.edu> wrote in message 
news:Pine.LNX.4.44.0702071623390.13529-100000@myth20.Stanford.EDU...
>
> Hi,
>
>
> Supposed there are two packets to the same destination, and router sends
> ARP request, but doesn't get a response. If both packets are in the queue
> waiting, how many ICMP host unreachable messages should be sent to the
> originator? What if the second packet arrives after ICMP message?
>
>
> Thanks,
> -Seung
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: checksum
Date: Thu, 8 Feb 2007 01:00:19 +0000 (UTC)
Organization: Your Company
Lines: 15
Distribution: su
Message-ID: <Xns98D0ACFDEB0DDchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170896419 24768 128.12.22.217 (8 Feb 2007 01:00:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11533

i'm calculating checksums and i always get 0...

i read some website and they said it's suppose to be 0, what's going on??? 
i thought it was suppose to match with the value in my checksum field?


my algorith is:

sum = sum all values (16-bit) into 32 bit word
sum = add the lower and higher 16bit of the 32 bit word

answer = 0xffff- sum


but i always get 0...
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: checksum
Date: Thu, 8 Feb 2007 01:39:30 +0000 (UTC)
Lines: 24
Distribution: su
Message-ID: <eqdv0i$saa$1@news.Stanford.EDU>
References: <Xns98D0ACFDEB0DDchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: vine3.stanford.edu
X-Trace: news.Stanford.EDU 1170898770 29002 171.64.15.226 (8 Feb 2007 01:39:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.15.7smp-secfix3 (i686))
Xref: shelby.stanford.edu su.class.cs244a:11534

Hi Chun,

When you are summing all values did you make sure that checksum field in
the packet is 0 ??  I think this is the problem in your case.

Thanks,
Dinesh

Chun Kai Wang <chunkaiw@stanford.edu> wrote:
> i'm calculating checksums and i always get 0...

> i read some website and they said it's suppose to be 0, what's going on??? 
> i thought it was suppose to match with the value in my checksum field?


> my algorith is:

> sum = sum all values (16-bit) into 32 bit word
> sum = add the lower and higher 16bit of the 32 bit word

> answer = 0xffff- sum


> but i always get 0...
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: checksum
Date: Thu, 8 Feb 2007 02:15:15 +0000 (UTC)
Organization: Your Company
Lines: 33
Distribution: su
Message-ID: <Xns98D0B9B25F186chunkaiwstanfordedu@171.64.14.103>
References: <Xns98D0ACFDEB0DDchunkaiwstanfordedu@171.64.14.103> <eqdv0i$saa$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170900915 935 128.12.22.217 (8 Feb 2007 02:15:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11535

yup. it was. thanks!



Dinesh Gupta <dineshg@Stanford.EDU> wrote in
news:eqdv0i$saa$1@news.Stanford.EDU: 

> Hi Chun,
> 
> When you are summing all values did you make sure that checksum field
> in the packet is 0 ??  I think this is the problem in your case.
> 
> Thanks,
> Dinesh
> 
> Chun Kai Wang <chunkaiw@stanford.edu> wrote:
>> i'm calculating checksums and i always get 0...
> 
>> i read some website and they said it's suppose to be 0, what's going
>> on??? i thought it was suppose to match with the value in my checksum
>> field? 
> 
> 
>> my algorith is:
> 
>> sum = sum all values (16-bit) into 32 bit word
>> sum = add the lower and higher 16bit of the 32 bit word
> 
>> answer = 0xffff- sum
> 
> 
>> but i always get 0...

.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 18:18:18 -0800
Lines: 74
Distribution: su
Message-ID: <eqe19l$12a$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab423334.stanford.edu
X-Trace: news.Stanford.EDU 1170901110 1098 171.66.51.52 (8 Feb 2007 02:18:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11536

"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:eqc291$67v$1@news.Stanford.EDU...
> Hey,
>
> I tested traceroute against topo 2
>
> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 ms 
> (ttl=63!)  0.227 ms (ttl=63!)
> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>
> I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
> expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 and 
> .23 respectively.
>
> I read the RFC and the FAQ and am still confused.
>
> -- 
> David Gobaud
>
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eqbrnb$q71$2@news.Stanford.EDU...
>> Try tracerouting to one of the interfaces on the reference topology (topo 
>> 2- I posted the corrected IPs earlier to the newsgroup).  Also, take a 
>> look at question 28 on the FAQ- that will help explain why the router 
>> behaves as it does.
>>
>> Clay
>> Euijong Whang wrote:
>>> Hi,
>>>
>>> I have the following IP addresses
>>> 192.168.128.139 (connected to the firewall)
>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>
>>> Question: Which IP of my router should be returned when I traceroute 
>>> 192.168.128.140
>>> from my computer? That is, what IP should be the source IP address of 
>>> the ICMP
>>> packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?
>>>
>>> The former seems reasonable because the packet is actually going through 
>>> the
>>> interface of 192.168.128.139. However, it is also true that I am 
>>> tracerouting
>>> 192.168.128.140, not 192.168.128.139.
>>>
>>> Best,
>>> Steven
>>>
>>>
>>>
>


I second the confusion.

if the router has ip's .19, .20 and .22
and the interface connected to the firewall has IP as .19,
should the final step of a traceroute to .20 (or .22) show up as to have 
come from .19 or .20 (or .22) ?

for eg:
a ping on topo 2 to 171.67.71.22 shows the last step as the packet having 
been sent from 171.67.71.20, though i would think it makes sense for it to 
have been from *.22

--
Ajay 


.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 18:19:34 -0800
Lines: 82
Distribution: su
Message-ID: <eqe1c1$13k$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab423334.stanford.edu
X-Trace: news.Stanford.EDU 1170901185 1140 171.66.51.52 (8 Feb 2007 02:19:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11537


"Ajay Martin" <ajaym@stanford.edu> wrote in message 
news:eqe19l$12a$1@news.Stanford.EDU...
> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
> news:eqc291$67v$1@news.Stanford.EDU...
>> Hey,
>>
>> I tested traceroute against topo 2
>>
>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 ms 
>> (ttl=63!)  0.227 ms (ttl=63!)
>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>
>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
>> expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 
>> and .23 respectively.
>>
>> I read the RFC and the FAQ and am still confused.
>>
>> -- 
>> David Gobaud
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>> Try tracerouting to one of the interfaces on the reference topology 
>>> (topo 2- I posted the corrected IPs earlier to the newsgroup).  Also, 
>>> take a look at question 28 on the FAQ- that will help explain why the 
>>> router behaves as it does.
>>>
>>> Clay
>>> Euijong Whang wrote:
>>>> Hi,
>>>>
>>>> I have the following IP addresses
>>>> 192.168.128.139 (connected to the firewall)
>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>
>>>> Question: Which IP of my router should be returned when I traceroute 
>>>> 192.168.128.140
>>>> from my computer? That is, what IP should be the source IP address of 
>>>> the ICMP
>>>> packet my router is returning? Is it 192.168.128.139 or 
>>>> 192.168.128.140?
>>>>
>>>> The former seems reasonable because the packet is actually going 
>>>> through the
>>>> interface of 192.168.128.139. However, it is also true that I am 
>>>> tracerouting
>>>> 192.168.128.140, not 192.168.128.139.
>>>>
>>>> Best,
>>>> Steven
>>>>
>>>>
>>>>
>>
>
>
> I second the confusion.
>
> if the router has ip's .19, .20 and .22
> and the interface connected to the firewall has IP as .19,
> should the final step of a traceroute to .20 (or .22) show up as to have 
> come from .19 or .20 (or .22) ?
>
> for eg:
> a ping on topo 2 to 171.67.71.22 shows the last step as the packet having 
> been sent from 171.67.71.20, though i would think it makes sense for it to 
> have been from *.22
>
> --
> Ajay
>

Typo:
  ... a *traceroute* on topo 2 ... 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: dest ip
Date: Thu, 8 Feb 2007 02:23:56 +0000 (UTC)
Organization: Your Company
Lines: 11
Distribution: su
Message-ID: <Xns98D0BB2B0441Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170901436 935 128.12.22.217 (8 Feb 2007 02:23:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11538

im a little confused, is it true that the only time dest ip of packet == my 
routher is


1.) ARP reply
2.) ARP request
3.) ICMP echo requests


all other packets that have my routher as the destination IP should be 
dropped right?
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 18:50:04 -0800
Lines: 106
Distribution: su
Message-ID: <eqe356$2k1$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU> <eqe1c1$13k$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170903014 2689 128.12.81.44 (8 Feb 2007 02:50:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11539

I've thought about it and this is what I think

traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 ms
(ttl=63!)  0.227 ms (ttl=63!)
 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms

is incorrect and should have ended in .23.

My reasoning is that when .20 receives the packet, the ttl will be 1 but it 
won't be cecked because the packet is addressed to a local address - .23. 
Now .23 gets the packet, sees that it is UDP, and sends a port unreachable, 
thus .20 should not show up in the route and .23 should be the 3rd hop.

Is my reasoning correct?

-- 
Thank you,
David Gobaud

"Ajay Martin" <ajaym@stanford.edu> wrote in message 
news:eqe1c1$13k$1@news.Stanford.EDU...
>
> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
> news:eqe19l$12a$1@news.Stanford.EDU...
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:eqc291$67v$1@news.Stanford.EDU...
>>> Hey,
>>>
>>> I tested traceroute against topo 2
>>>
>>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 
>>> ms (ttl=63!)  0.227 ms (ttl=63!)
>>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>>
>>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
>>> expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 
>>> and .23 respectively.
>>>
>>> I read the RFC and the FAQ and am still confused.
>>>
>>> -- 
>>> David Gobaud
>>>
>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>>> Try tracerouting to one of the interfaces on the reference topology 
>>>> (topo 2- I posted the corrected IPs earlier to the newsgroup).  Also, 
>>>> take a look at question 28 on the FAQ- that will help explain why the 
>>>> router behaves as it does.
>>>>
>>>> Clay
>>>> Euijong Whang wrote:
>>>>> Hi,
>>>>>
>>>>> I have the following IP addresses
>>>>> 192.168.128.139 (connected to the firewall)
>>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>>
>>>>> Question: Which IP of my router should be returned when I traceroute 
>>>>> 192.168.128.140
>>>>> from my computer? That is, what IP should be the source IP address of 
>>>>> the ICMP
>>>>> packet my router is returning? Is it 192.168.128.139 or 
>>>>> 192.168.128.140?
>>>>>
>>>>> The former seems reasonable because the packet is actually going 
>>>>> through the
>>>>> interface of 192.168.128.139. However, it is also true that I am 
>>>>> tracerouting
>>>>> 192.168.128.140, not 192.168.128.139.
>>>>>
>>>>> Best,
>>>>> Steven
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>> I second the confusion.
>>
>> if the router has ip's .19, .20 and .22
>> and the interface connected to the firewall has IP as .19,
>> should the final step of a traceroute to .20 (or .22) show up as to have 
>> come from .19 or .20 (or .22) ?
>>
>> for eg:
>> a ping on topo 2 to 171.67.71.22 shows the last step as the packet having 
>> been sent from 171.67.71.20, though i would think it makes sense for it 
>> to have been from *.22
>>
>> --
>> Ajay
>>
>
> Typo:
>  ... a *traceroute* on topo 2 ...
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 18:56:02 -0800
Lines: 93
Distribution: su
Message-ID: <eqe3gd$2el$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU> <eqe1c1$13k$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170903373 2517 127.0.0.1 (8 Feb 2007 02:56:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:11540

If I had to guess, I'd say that it's a slight bug in the reference router.

If you ping 171.67.71.23, the replies come as from IP  *.23, which is 
correct. When you traceroute to .23, the router eventually receives a 
packet addressed to .23 with a TTL of 1, but since it sends the ensuing 
ICMP Port Unreachable over "eth0", it probably mistakenly sets the 
ip_dst value to the IP for the eth0 interface, which is .20. I suppose 
I don't know if this is the "correct" behavior or "incorrect" behavior, 
but it's trivial enough to support either behavior in the router, so 
I'll let a TA make a ruling and then go with it.



On 2007-02-07 18:19:34 -0800, "Ajay Martin" <ajaym@stanford.edu> said:

> 
> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
> news:eqe19l$12a$1@news.Stanford.EDU...
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:eqc291$67v$1@news.Stanford.EDU...
>>> Hey,
>>> 
>>> I tested traceroute against topo 2
>>> 
>>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 
>>> ms (ttl=63!)  0.227 ms (ttl=63!)
>>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>> 
>>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
>>> expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 
>>> and .23 respectively.
>>> 
>>> I read the RFC and the FAQ and am still confused.
>>> 
>>> -- 
>>> David Gobaud
>>> 
>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>>> Try tracerouting to one of the interfaces on the reference topology 
>>>> (topo 2- I posted the corrected IPs earlier to the newsgroup).  Also, 
>>>> take a look at question 28 on the FAQ- that will help explain why the 
>>>> router behaves as it does.
>>>> 
>>>> Clay
>>>> Euijong Whang wrote:
>>>>> Hi,
>>>>> 
>>>>> I have the following IP addresses
>>>>> 192.168.128.139 (connected to the firewall)
>>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>> 
>>>>> Question: Which IP of my router should be returned when I traceroute 
>>>>> 192.168.128.140
>>>>> from my computer? That is, what IP should be the source IP address of the ICMP
>>>>> packet my router is returning? Is it 192.168.128.139 or 192.168.128.140?
>>>>> 
>>>>> The former seems reasonable because the packet is actually going through the
>>>>> interface of 192.168.128.139. However, it is also true that I am tracerouting
>>>>> 192.168.128.140, not 192.168.128.139.
>>>>> 
>>>>> Best,
>>>>> Steven
>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
>> 
>> I second the confusion.
>> 
>> if the router has ip's .19, .20 and .22
>> and the interface connected to the firewall has IP as .19,
>> should the final step of a traceroute to .20 (or .22) show up as to 
>> have come from .19 or .20 (or .22) ?
>> 
>> for eg:
>> a ping on topo 2 to 171.67.71.22 shows the last step as the packet 
>> having been sent from 171.67.71.20, though i would think it makes sense 
>> for it to have been from *.22
>> 
>> --
>> Ajay
>> 
> 
> Typo:
>   ... a *traceroute* on topo 2 ... 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 7 Feb 2007 19:14:48 -0800
Lines: 118
Distribution: su
Message-ID: <eqe4ho$3kf$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU> <eqe1c1$13k$1@news.Stanford.EDU> <eqe356$2k1$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170904441 3727 127.0.0.1 (8 Feb 2007 03:14:01 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11541

As I said in another thread, according to David Erickson, you are correct, 
and this is a bug.

Sincerely,
Randy Jennings

The squirrels are your friends!
"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:eqe356$2k1$1@news.Stanford.EDU...
> I've thought about it and this is what I think
>
> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 ms
> (ttl=63!)  0.227 ms (ttl=63!)
> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>
> is incorrect and should have ended in .23.
>
> My reasoning is that when .20 receives the packet, the ttl will be 1 but 
> it won't be cecked because the packet is addressed to a local address - 
> .23. Now .23 gets the packet, sees that it is UDP, and sends a port 
> unreachable, thus .20 should not show up in the route and .23 should be 
> the 3rd hop.
>
> Is my reasoning correct?
>
> -- 
> Thank you,
> David Gobaud
>
> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
> news:eqe1c1$13k$1@news.Stanford.EDU...
>>
>> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
>> news:eqe19l$12a$1@news.Stanford.EDU...
>>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>>> news:eqc291$67v$1@news.Stanford.EDU...
>>>> Hey,
>>>>
>>>> I tested traceroute against topo 2
>>>>
>>>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>>>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>>>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  0.254 
>>>> ms (ttl=63!)  0.227 ms (ttl=63!)
>>>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>>>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>>>
>>>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I would 
>>>> expect either 3 hops ending in .23 or 4 hops with the last 2 being .20 
>>>> and .23 respectively.
>>>>
>>>> I read the RFC and the FAQ and am still confused.
>>>>
>>>> -- 
>>>> David Gobaud
>>>>
>>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>>>> Try tracerouting to one of the interfaces on the reference topology 
>>>>> (topo 2- I posted the corrected IPs earlier to the newsgroup).  Also, 
>>>>> take a look at question 28 on the FAQ- that will help explain why the 
>>>>> router behaves as it does.
>>>>>
>>>>> Clay
>>>>> Euijong Whang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have the following IP addresses
>>>>>> 192.168.128.139 (connected to the firewall)
>>>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>>>
>>>>>> Question: Which IP of my router should be returned when I traceroute 
>>>>>> 192.168.128.140
>>>>>> from my computer? That is, what IP should be the source IP address of 
>>>>>> the ICMP
>>>>>> packet my router is returning? Is it 192.168.128.139 or 
>>>>>> 192.168.128.140?
>>>>>>
>>>>>> The former seems reasonable because the packet is actually going 
>>>>>> through the
>>>>>> interface of 192.168.128.139. However, it is also true that I am 
>>>>>> tracerouting
>>>>>> 192.168.128.140, not 192.168.128.139.
>>>>>>
>>>>>> Best,
>>>>>> Steven
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> I second the confusion.
>>>
>>> if the router has ip's .19, .20 and .22
>>> and the interface connected to the firewall has IP as .19,
>>> should the final step of a traceroute to .20 (or .22) show up as to have 
>>> come from .19 or .20 (or .22) ?
>>>
>>> for eg:
>>> a ping on topo 2 to 171.67.71.22 shows the last step as the packet 
>>> having been sent from 171.67.71.20, though i would think it makes sense 
>>> for it to have been from *.22
>>>
>>> --
>>> Ajay
>>>
>>
>> Typo:
>>  ... a *traceroute* on topo 2 ...
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: checksum & TTL
Date: Wed, 07 Feb 2007 19:28:27 -0800
Lines: 22
Distribution: su
Message-ID: <eqe5cq$43k$1@news.Stanford.EDU>
References: <Xns98D09E5F19512chunkaiwstanfordedu@171.64.14.103> <eqdrps$ppd$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170905306 4212 127.0.0.1 (8 Feb 2007 03:28:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqdrps$ppd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11542

Randy Jennings wrote:
>> is it true that if a packet has a wrong checksum i should drop it no 
>> matter
>> what kind? (ARP, ICMP, IP, etc)
> Depends on whether you are forwarding it and what layer the incorrect 
> checksum is.  (BTW, checksum in ARP?)

Take a look at the RFC and see what it says, if you find out let 
everyone know, I'm unsure off hand.

> 
>> also, if the TTL is less than 0, the only time this is ok is if the packet
>> is an ICMP echo right?
> I would check the FAQ/Assignment a little closer on this one (how are you 
> going to get a negative TTL?).

Ya I'm unsure how you could get a negative TTL, remember your router 
should not decrement it if it is destined for you, you only decrement as 
your going to route it, and if it is 0 before you route it you know you 
need to send an ICMP reply.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: dest ip
Date: Wed, 07 Feb 2007 19:31:11 -0800
Lines: 17
Distribution: su
Message-ID: <eqe5hu$43k$2@news.Stanford.EDU>
References: <Xns98D0BB2B0441Echunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170905470 4212 127.0.0.1 (8 Feb 2007 03:31:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98D0BB2B0441Echunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11543

Chun Kai Wang wrote:
> im a little confused, is it true that the only time dest ip of packet == my 
> routher is
> 
> 
> 1.) ARP reply
> 2.) ARP request
> 3.) ICMP echo requests
> 
> 
> all other packets that have my routher as the destination IP should be 
> dropped right?

Please read the FAQ:
http://www.stanford.edu/class/cs244a/2006/homeworks/hw2/faq.html#what_icmp

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: checksum & TTL
Date: Wed, 7 Feb 2007 19:34:46 -0800
Lines: 24
Distribution: su
Message-ID: <eqe5n9$4j6$1@news.Stanford.EDU>
References: <Xns98D09E5F19512chunkaiwstanfordedu@171.64.14.103> <eqdrps$ppd$1@news.Stanford.EDU> <eqe5cq$43k$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170905641 4710 127.0.0.1 (8 Feb 2007 03:34:01 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11544

>>> also, if the TTL is less than 0, the only time this is ok is if the 
>>> packet
>>> is an ICMP echo right?
>> I would check the FAQ/Assignment a little closer on this one (how are you 
>> going to get a negative TTL?).
>
> Ya I'm unsure how you could get a negative TTL, remember your router 
> should not decrement it if it is destined for you, you only decrement as 
> your going to route it, and if it is 0 before you route it you know you 
> need to send an ICMP reply.
There are no signed fields in IP, TCP, Ethernet, ARP.  There may be in other 
protocols, but I cannot think of any...  That is why I did not understand 
how you could get a negative length in IP.

If you can get negative numbers, something is fundamentally wrong with the 
code.
If you wrap an unsigned number, something is wrong with the code.

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Making the threads share memory...
Date: Wed, 7 Feb 2007 19:40:22 -0800
Lines: 26
Distribution: su
Message-ID: <eqe61n$4mk$1@news.Stanford.EDU>
References: <eq73l5$hrp$1@news.Stanford.EDU> <eq73tj$hrp$2@news.Stanford.EDU> <eq7thi$9te$1@news.Stanford.EDU> <eq9fjk$lq7$1@news.Stanford.EDU> <eqablp$g8a$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170905976 4820 127.0.0.1 (8 Feb 2007 03:39:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11545

> As to the linking problem, what machines are you using?  The Solaris boxes 
> may need a library (I cannot remember if it is -lpthread or -lthread), but 
> Linux and Cygwin both link it in with libc (e.g. automatically).
For the record, I had to change:
ifeq ($(OSTYPE),Linux)
ARCH = -D_LINUX_
SOCK = -lnsl -lresolv
endif

to:
ifeq ($(OSTYPE),Linux)
ARCH = -D_LINUX_
SOCK = -lnsl -lresolv -lpthread
endif

In the Makefile.

(I also found out that Cygwin has claimed threadsafty since 2004.  How times 
change!)

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Default Route...
Date: Wed, 7 Feb 2007 19:48:43 -0800
Lines: 42
Distribution: su
Message-ID: <eqe6hc$552$1@news.Stanford.EDU>
References: <epsa6g$dms$1@news.Stanford.EDU> <C1E7676E.7EDE%jpettit@stanford.edu> <45C9ED8A.6090506@stanford.edu>
X-Trace: news.Stanford.EDU 1170906476 5282 127.0.0.1 (8 Feb 2007 03:47:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11546

I am really interested in the answer to this.  I took the different approach 
as loopback tests can be very useful, and the TTL should eventually kill the 
packet anyway.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Seung H. Choi" <shchoi@stanford.edu> wrote in message 
news:45C9ED8A.6090506@stanford.edu...
> If a packet is received from, say eth0, can/should a router forward it 
> back to the same interface?
>
> Currently, I don't allow such back-forwarding, b/c I don't see how that's 
> useful. What should be the correct behavior?
>
>
> Thanks,
> -Seung
>
>
> Justin Pettit ? ?:
>> The only case I can think of is when the packet's destination is in the
>> router's collision domain, but it couldn't determine the destination's
>> hardware address.  This could happen because no machine has that IP 
>> address
>> or the one that does is down.
>>
>> --Justin
>>
>>
>> On 2/1/07 12:59 AM, in article epsa6g$dms$1@news.Stanford.EDU, "Matt 
>> Page"
>> <mpage@stanford.edu> wrote:
>>
>>> Given the presence of a default route, how can we determine if a packet
>>> has an unknown next hop address?
>>>
>>> Thanks,
>>> Matt
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: gateway
Date: Thu, 8 Feb 2007 04:08:18 +0000 (UTC)
Organization: Your Company
Lines: 15
Distribution: su
Message-ID: <Xns98D0CCDD2FB9Cchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170907698 5608 128.12.22.217 (8 Feb 2007 04:08:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11547

what's the gateway for our routing table for?



plus, can i assume that the routing table is valid? entries like these, 
don't exist

dest    	    	mask    	    	
1.1.1.1    	    	1.1.0.0

since if you have a 0 for mask, those corresponding values in dest have to 
be 0 too.



.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use web browser to test if I am remote?
Date: Wed, 07 Feb 2007 20:17:58 -0800
Lines: 45
Distribution: su
Message-ID: <pan.2007.02.08.04.17.57.854882@cs.stanford.edu>
References: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU> <C1EFB229.82A8%jpettit@stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170907812 6292 128.12.186.133 (8 Feb 2007 04:10:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11548

On Wed, 07 Feb 2007 16:43:21 -0800, Justin Pettit wrote:

> You should be able to launch a web browser using X tunneled through SSH.
> You may need to use the "-Y" flag:
> 
>     ssh -Y user@myth.stanford.edu
> 
> If that doesn't work, you can use a text-based browser, like lynx:
> 
>     lynx www.yahoo.com
> 
> Obviously, you would replace "www.yahoo.com" with your local web server.
> 
> --Justin
> 
> 
> On 2/7/07 4:06 PM, in article
> Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU, "Ryan Chen"
> <ryanchen@stanford.edu> wrote:
> 
>> 
>> If I remote log in to myths, I am guessing I won't be able to launch a
>> local browser? (I am using Exceed, and it doesn't seem to work) I am a
>> remote student, so I can't come in to the labs...
>> 
>> The assignment mentions that if my router is implemented correctly, I
>> should be able to download the posted files from the application servers?
>> Is there a way I can test it using command line? I have tried using
>> "telnet" to one of the application servers, but it seems to be giving me a
>> connection refused error message.
>> 
>> Any pointer as to how to test the download from application servers is
>> appreciated. Thanks.
>>

I managed to launch a web browser by using the -Y method. However, I am
confused about something. When I browse the web pages and the ftp server,
I see a flurry of activity on my router as it processes and forwards
packets, as expected. But when I download a file I don't see any activity
at all. The files successfully download though: for example I can transfer
the mp3 off of my afs to my home computer and play it.

What is going on?

Thanks
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gateway
Date: Wed, 07 Feb 2007 20:19:34 -0800
Lines: 19
Distribution: su
Message-ID: <eqe8cl$690$1@news.Stanford.EDU>
References: <Xns98D0CCDD2FB9Cchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170908373 6432 127.0.0.1 (8 Feb 2007 04:19:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98D0CCDD2FB9Cchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11549

Chun Kai Wang wrote:
> what's the gateway for our routing table for?
> 
Its your next hop.

> 
> 
> plus, can i assume that the routing table is valid? entries like these, 
> don't exist
> 
> dest    	    	mask    	    	
> 1.1.1.1    	    	1.1.0.0
> 
> since if you have a 0 for mask, those corresponding values in dest have to 
> be 0 too.

The routing table will be valid.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Repost: traffic coming back out on the same interface
Date: Wed, 7 Feb 2007 20:32:21 -0800
Lines: 21
Distribution: su
Message-ID: <eqe935$72l$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170909094 7253 127.0.0.1 (8 Feb 2007 04:31:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11550

I am really interested in the answer to this.  I took the different approach
as loopback tests can be very useful, and the TTL should eventually kill the
packet anyway.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Seung H. Choi" <shchoi@stanford.edu> wrote in message
news:45C9ED8A.6090506@stanford.edu...
> If a packet is received from, say eth0, can/should a router forward it
> back to the same interface?
>
> Currently, I don't allow such back-forwarding, b/c I don't see how that's
> useful. What should be the correct behavior?
>
>
> Thanks,
> -Seung 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Wed, 07 Feb 2007 21:18:45 -0800
Lines: 104
Distribution: su
Message-ID: <eqebri$8jp$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU> <eqe1c1$13k$1@news.Stanford.EDU> <eqe3gd$2el$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170911922 8825 127.0.0.1 (8 Feb 2007 05:18:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqe3gd$2el$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11551

Adam Cohen wrote:
> If I had to guess, I'd say that it's a slight bug in the reference router.
> 
> If you ping 171.67.71.23, the replies come as from IP  *.23, which is 
> correct. When you traceroute to .23, the router eventually receives a 
> packet addressed to .23 with a TTL of 1, but since it sends the ensuing 
> ICMP Port Unreachable over "eth0", it probably mistakenly sets the 
> ip_dst value to the IP for the eth0 interface, which is .20. I suppose I 
> don't know if this is the "correct" behavior or "incorrect" behavior, 
> but it's trivial enough to support either behavior in the router, so 
> I'll let a TA make a ruling and then go with it.
> 
> 
> 
> On 2007-02-07 18:19:34 -0800, "Ajay Martin" <ajaym@stanford.edu> said:
> 
>>
>> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
>> news:eqe19l$12a$1@news.Stanford.EDU...
>>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>>> news:eqc291$67v$1@news.Stanford.EDU...
>>>> Hey,
>>>>
>>>> I tested traceroute against topo 2
>>>>
>>>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>>>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>>>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  
>>>> 0.254 ms (ttl=63!)  0.227 ms (ttl=63!)
>>>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>>>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>>>
>>>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I 
>>>> would expect either 3 hops ending in .23 or 4 hops with the last 2 
>>>> being .20 and .23 respectively.
>>>>
>>>> I read the RFC and the FAQ and am still confused.
>>>>
>>>> -- 
>>>> David Gobaud
>>>>
>>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>>>> Try tracerouting to one of the interfaces on the reference topology 
>>>>> (topo 2- I posted the corrected IPs earlier to the newsgroup).  
>>>>> Also, take a look at question 28 on the FAQ- that will help explain 
>>>>> why the router behaves as it does.
>>>>>
>>>>> Clay
>>>>> Euijong Whang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have the following IP addresses
>>>>>> 192.168.128.139 (connected to the firewall)
>>>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>>>
>>>>>> Question: Which IP of my router should be returned when I 
>>>>>> traceroute 192.168.128.140
>>>>>> from my computer? That is, what IP should be the source IP address 
>>>>>> of the ICMP
>>>>>> packet my router is returning? Is it 192.168.128.139 or 
>>>>>> 192.168.128.140?
>>>>>>
>>>>>> The former seems reasonable because the packet is actually going 
>>>>>> through the
>>>>>> interface of 192.168.128.139. However, it is also true that I am 
>>>>>> tracerouting
>>>>>> 192.168.128.140, not 192.168.128.139.
>>>>>>
>>>>>> Best,
>>>>>> Steven
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> I second the confusion.
>>>
>>> if the router has ip's .19, .20 and .22
>>> and the interface connected to the firewall has IP as .19,
>>> should the final step of a traceroute to .20 (or .22) show up as to 
>>> have come from .19 or .20 (or .22) ?
>>>
>>> for eg:
>>> a ping on topo 2 to 171.67.71.22 shows the last step as the packet 
>>> having been sent from 171.67.71.20, though i would think it makes 
>>> sense for it to have been from *.22
>>>
>>> -- 
>>> Ajay
>>>
>>
>> Typo:
>>   ... a *traceroute* on topo 2 ... 
> 
> 


Can the TAs confirm which is the correct behavior?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: vns firewall configuration
Date: Wed, 07 Feb 2007 21:42:34 -0800
Lines: 10
Distribution: su
Message-ID: <pan.2007.02.08.05.42.34.295276@cs.stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170912887 9971 128.12.186.133 (8 Feb 2007 05:34:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11552

Hi,

Is the firewall configured to block tcp connections from the app servers?
Active mode ftp is failing for me and using tcpdump it looks like the
firewall is bouncing SYNs originating from the app servers and destined
for outside the firewall.

Or my router could not be working of course...

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Wed, 07 Feb 2007 21:37:34 -0800
Lines: 26
Distribution: su
Message-ID: <eqecuk$9qd$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170913044 10061 127.0.0.1 (8 Feb 2007 05:37:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqe935$72l$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11553

Randy Jennings wrote:
> I am really interested in the answer to this.  I took the different approach
> as loopback tests can be very useful, and the TTL should eventually kill the
> packet anyway.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> "Seung H. Choi" <shchoi@stanford.edu> wrote in message
> news:45C9ED8A.6090506@stanford.edu...
>> If a packet is received from, say eth0, can/should a router forward it
>> back to the same interface?
>>
>> Currently, I don't allow such back-forwarding, b/c I don't see how that's
>> useful. What should be the correct behavior?
>>
>>
>> Thanks,
>> -Seung 
> 
> 

We won't test generating traffic from your own interface to itself.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: vns firewall configuration
Date: Wed, 07 Feb 2007 21:40:01 -0800
Lines: 15
Distribution: su
Message-ID: <eqed37$9qd$2@news.Stanford.EDU>
References: <pan.2007.02.08.05.42.34.295276@cs.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170913191 10061 127.0.0.1 (8 Feb 2007 05:39:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <pan.2007.02.08.05.42.34.295276@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11554

Paolo wrote:
> Hi,
> 
> Is the firewall configured to block tcp connections from the app servers?
> Active mode ftp is failing for me and using tcpdump it looks like the
> firewall is bouncing SYNs originating from the app servers and destined
> for outside the firewall.
> 
> Or my router could not be working of course...
> 
> Thanks.

Active mode didn't work for me on Clack so assume its the firewall.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: icmp messages
Date: Thu, 8 Feb 2007 05:42:03 +0000 (UTC)
Organization: Your Company
Lines: 21
Distribution: su
Message-ID: <Xns98D0DCC185C0Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170913323 10255 128.12.22.217 (8 Feb 2007 05:42:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11555

i would just like to confirm incase i head off to do the wrong thing


in the FAQ


Host unreachable 
=> type 3, error code 1


Port unreachable 
=> type 3, error code 3



Timeout 
=> type 11



thanks
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Wed, 7 Feb 2007 21:45:14 -0800
Lines: 27
Distribution: su
Message-ID: <eqedbr$a4v$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170913467 10399 127.0.0.1 (8 Feb 2007 05:44:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11556

>> I am really interested in the answer to this.  I took the different 
>> approach
>> as loopback tests can be very useful, and the TTL should eventually kill 
>> the
>> packet anyway.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>> If a packet is received from, say eth0, can/should a router forward it
>>> back to the same interface?
>>>
>>> Currently, I don't allow such back-forwarding, b/c I don't see how 
>>> that's
>>> useful. What should be the correct behavior?
>
> We won't test generating traffic from your own interface to itself.
Glad to hear it.  You wouldn't happen to know what the correct behavior for 
a router is, would you?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Wed, 07 Feb 2007 21:47:12 -0800
Lines: 26
Distribution: su
Message-ID: <eqedgl$a7u$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqedbr$a4v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170913621 10494 127.0.0.1 (8 Feb 2007 05:47:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqedbr$a4v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11557

Randy Jennings wrote:
>>> I am really interested in the answer to this.  I took the different 
>>> approach
>>> as loopback tests can be very useful, and the TTL should eventually kill 
>>> the
>>> packet anyway.
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> The squirrels are your friends!
>>>> If a packet is received from, say eth0, can/should a router forward it
>>>> back to the same interface?
>>>>
>>>> Currently, I don't allow such back-forwarding, b/c I don't see how 
>>>> that's
>>>> useful. What should be the correct behavior?
>> We won't test generating traffic from your own interface to itself.
> Glad to hear it.  You wouldn't happen to know what the correct behavior for 
> a router is, would you?
> 

Well first of all you have to ask yourself why a router would be sending 
itself data when if it really needed to it could just use a loopback...

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: icmp messages
Date: Wed, 07 Feb 2007 21:48:21 -0800
Lines: 27
Distribution: su
Message-ID: <eqedir$a7u$2@news.Stanford.EDU>
References: <Xns98D0DCC185C0Bchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170913691 10494 127.0.0.1 (8 Feb 2007 05:48:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98D0DCC185C0Bchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11558

Chun Kai Wang wrote:
> i would just like to confirm incase i head off to do the wrong thing
> 
> 
> in the FAQ
> 
> 
> Host unreachable 
> => type 3, error code 1
> 
> 
> Port unreachable 
> => type 3, error code 3
> 
> 
> 
> Timeout 
> => type 11
> 
> 
> 
> thanks

If you don't trust our FAQ please feel free to read the RFC: 
http://www.faqs.org/rfcs/rfc792.html

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use web browser to test if I am remote?
Date: Wed, 7 Feb 2007 22:00:51 -0800
Lines: 60
Distribution: su
Message-ID: <eqeeav$b2b$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU> <C1EFB229.82A8%jpettit@stanford.edu> <pan.2007.02.08.04.17.57.854882@cs.stanford.edu>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1170914463 11339 128.12.137.162 (8 Feb 2007 06:01:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11559


"Paolo" <paolo@cs.stanford.edu> wrote in message 
news:pan.2007.02.08.04.17.57.854882@cs.stanford.edu...
> On Wed, 07 Feb 2007 16:43:21 -0800, Justin Pettit wrote:
>
>> You should be able to launch a web browser using X tunneled through SSH.
>> You may need to use the "-Y" flag:
>>
>>     ssh -Y user@myth.stanford.edu
>>
>> If that doesn't work, you can use a text-based browser, like lynx:
>>
>>     lynx www.yahoo.com
>>
>> Obviously, you would replace "www.yahoo.com" with your local web server.
>>
>> --Justin
>>
>>
>> On 2/7/07 4:06 PM, in article
>> Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU, "Ryan Chen"
>> <ryanchen@stanford.edu> wrote:
>>
>>>
>>> If I remote log in to myths, I am guessing I won't be able to launch a
>>> local browser? (I am using Exceed, and it doesn't seem to work) I am a
>>> remote student, so I can't come in to the labs...
>>>
>>> The assignment mentions that if my router is implemented correctly, I
>>> should be able to download the posted files from the application 
>>> servers?
>>> Is there a way I can test it using command line? I have tried using
>>> "telnet" to one of the application servers, but it seems to be giving me 
>>> a
>>> connection refused error message.
>>>
>>> Any pointer as to how to test the download from application servers is
>>> appreciated. Thanks.
>>>
>
> I managed to launch a web browser by using the -Y method. However, I am
> confused about something. When I browse the web pages and the ftp server,
> I see a flurry of activity on my router as it processes and forwards
> packets, as expected. But when I download a file I don't see any activity
> at all. The files successfully download though: for example I can transfer
> the mp3 off of my afs to my home computer and play it.
>
> What is going on?
>
> Thanks

just make sure the address from which the file is being downloaded are fine.
some of the links are hand links to vns-app-1.stanford.edu. or vns-app-2.xxx 
etc.
if you want to download those songs, try the direct http://<your ap 
server::8888/ .

Ajay


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: icmp error packet
Date: Thu, 8 Feb 2007 06:19:50 +0000 (UTC)
Organization: Your Company
Lines: 12
Distribution: su
Message-ID: <Xns98D0E3298D47Fchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170915590 12151 128.12.22.217 (8 Feb 2007 06:19:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11560

while running clack,


i saw that the ICMP error packet for port unreachable had 32 bytes of 
"unknown packet".

should ours have this 32 bytes of stuff?

or can we just send the ICMP header without the body?


thanks
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Wed, 07 Feb 2007 22:22:39 -0800
Lines: 13
Distribution: su
Message-ID: <C1F001AF.82D6%jpettit@stanford.edu>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqedbr$a4v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170915763 12407 127.0.0.1 (8 Feb 2007 06:22:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Repost: traffic coming back out on the same interface
Thread-Index: AcdLSYgDxrApebc8EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11561

>> We won't test generating traffic from your own interface to itself.
> Glad to hear it.  You wouldn't happen to know what the correct behavior for
> a router is, would you?

There actually is an old attack called "land" based on this:

    http://en.wikipedia.org/wiki/LAND

The best thing to do is drop it, since it will never legitimately be
created.  If you ever want to hear about late 90's hacks, I'm your guy!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: everybody.mp3
Date: Wed, 7 Feb 2007 22:39:44 -0800
Lines: 7
Distribution: su
Message-ID: <eqegji$cpn$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1170916787 13111 171.64.75.59 (8 Feb 2007 06:39:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11562


Hm.. that everybody song is pretty addictive.
Where did you get it?  :-)

-Steven


.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Wed, 07 Feb 2007 23:14:24 -0800
Lines: 40
Distribution: su
Message-ID: <eqeikj$een$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170918867 14807 127.0.0.1 (8 Feb 2007 07:14:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqecuk$9qd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11563

My question was, say if a packet was received from eth0, and its dest IP
is not found on forwarding table, so the default behavior is forwarding
it to eth0, the collision domain. Should this be allowed in general 
case? I can see how ARP requests and ICMP echo messages will do this, 
but I just wonder if this is to be done in general, since if routing is 
correct, IP packet should never have arrived at my router.

Thanks,
-Seung

David Erickson 쓴 글:
> Randy Jennings wrote:
>> I am really interested in the answer to this.  I took the different 
>> approach
>> as loopback tests can be very useful, and the TTL should eventually 
>> kill the
>> packet anyway.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>> "Seung H. Choi" <shchoi@stanford.edu> wrote in message
>> news:45C9ED8A.6090506@stanford.edu...
>>> If a packet is received from, say eth0, can/should a router forward it
>>> back to the same interface?
>>>
>>> Currently, I don't allow such back-forwarding, b/c I don't see how 
>>> that's
>>> useful. What should be the correct behavior?
>>>
>>>
>>> Thanks,
>>> -Seung 
>>
>>
> 
> We won't test generating traffic from your own interface to itself.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: pthreads sleep
Date: Thu, 8 Feb 2007 07:14:57 +0000 (UTC)
Organization: Your Company
Lines: 11
Distribution: su
Message-ID: <Xns98D0EC81E7C2Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170918897 14791 128.12.22.217 (8 Feb 2007 07:14:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11564

for some reason, even if i have #include <pthread.h>

and even if all my threads work properly, my sleep function has an error:

sr_router.c:317: warning: implicit declaration of function 'sleep'


why? it seems as if sleep function was never declared...


help...
.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Environment configuration
Date: Wed, 07 Feb 2007 23:35:00 -0800
Lines: 9
Distribution: su
Message-ID: <eqejr9$fi4$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170920105 15940 127.0.0.1 (8 Feb 2007 07:35:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11565

Hi,

When our routers are tested, will they be tested on the same topology
that we're given? That is, will it be tested on a topology with three
interfaces, or could they be tested in arbitrary topology?


Thanks,
-Seung
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: pthreads sleep
Date: Thu, 8 Feb 2007 00:30:17 -0800
Lines: 21
Distribution: su
Message-ID: <eqen34$mh2$1@news.Stanford.EDU>
References: <Xns98D0EC81E7C2Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1170923428 23074 128.12.81.44 (8 Feb 2007 08:30:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11566

#include <unistd.h>


-- 
David Gobaud

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98D0EC81E7C2Bchunkaiwstanfordedu@171.64.14.103...
> for some reason, even if i have #include <pthread.h>
>
> and even if all my threads work properly, my sleep function has an error:
>
> sr_router.c:317: warning: implicit declaration of function 'sleep'
>
>
> why? it seems as if sleep function was never declared...
>
>
> help... 


.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: routing table entries
Date: Thu, 8 Feb 2007 00:31:34 -0800
Lines: 14
Distribution: su
Message-ID: <eqen5h$mj4$1@news.Stanford.EDU>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1170923505 23140 128.12.137.162 (8 Feb 2007 08:31:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11567


1. Can we make the assumption that the routing table is sorted from most 
specific to least specific (e.g. if you use hierarchical masks in a more 
populated topology)?

2. Can we assume that the default route is the last entry?


The answers to both were yes in last years news group. Am just confirming.
What have the rest of you'll done?

Ajay 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Thu, 08 Feb 2007 01:05:11 -0800
Lines: 12
Distribution: su
Message-ID: <eqep47$o2q$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqeikj$een$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170925511 24666 127.0.0.1 (8 Feb 2007 09:05:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqeikj$een$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11568

Seung H. Choi wrote:
> My question was, say if a packet was received from eth0, and its dest IP
> is not found on forwarding table, so the default behavior is forwarding
> it to eth0, the collision domain. Should this be allowed in general 
> case? I can see how ARP requests and ICMP echo messages will do this, 
> but I just wonder if this is to be done in general, since if routing is 
> correct, IP packet should never have arrived at my router.

As far as I know you never want to forward a packet back out the 
interface it came in on, it just doesn't make sense.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: icmp error packet
Date: Thu, 08 Feb 2007 01:05:47 -0800
Lines: 17
Distribution: su
Message-ID: <eqep5b$o2q$2@news.Stanford.EDU>
References: <Xns98D0E3298D47Fchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170925547 24666 127.0.0.1 (8 Feb 2007 09:05:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98D0E3298D47Fchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11569

Chun Kai Wang wrote:
> while running clack,
> 
> 
> i saw that the ICMP error packet for port unreachable had 32 bytes of 
> "unknown packet".
> 
> should ours have this 32 bytes of stuff?
> 
> or can we just send the ICMP header without the body?
> 
> 
> thanks

Please, please, please read the ICMP RFC *begs*

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Environment configuration
Date: Thu, 08 Feb 2007 01:07:20 -0800
Lines: 16
Distribution: su
Message-ID: <eqep88$o2q$3@news.Stanford.EDU>
References: <eqejr9$fi4$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170925640 24666 127.0.0.1 (8 Feb 2007 09:07:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqejr9$fi4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11570

Seung H. Choi wrote:
> Hi,
> 
> When our routers are tested, will they be tested on the same topology
> that we're given? That is, will it be tested on a topology with three
> interfaces, or could they be tested in arbitrary topology?
> 
> 
> Thanks,
> -Seung

*thinks back to grading the first assignment*.. we dinged for setting
static buffers, so if you are setting a static amount of routes would
that be a good idea?

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: routing table entries
Date: Thu, 08 Feb 2007 01:08:37 -0800
Lines: 21
Distribution: su
Message-ID: <eqepal$o2q$4@news.Stanford.EDU>
References: <eqen5h$mj4$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170925717 24666 127.0.0.1 (8 Feb 2007 09:08:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqen5h$mj4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11571

Ajay Martin wrote:
> 1. Can we make the assumption that the routing table is sorted from most 
> specific to least specific (e.g. if you use hierarchical masks in a more 
> populated topology)?

No.

> 2. Can we assume that the default route is the last entry?
> 

No.

> The answers to both were yes in last years news group. Am just confirming.
> What have the rest of you'll done?
> 
> Ajay 

All you need to do is make one loop through the route list and use 
longest prefix matching to find the route you need.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute behavior
Date: Thu, 08 Feb 2007 01:23:00 -0800
Lines: 111
Distribution: su
Message-ID: <eqeq5k$p5k$1@news.Stanford.EDU>
References: <eqbq5p$pbh$1@news.Stanford.EDU> <eqbrnb$q71$2@news.Stanford.EDU> <eqc291$67v$1@news.Stanford.EDU> <eqe19l$12a$1@news.Stanford.EDU> <eqe1c1$13k$1@news.Stanford.EDU> <eqe3gd$2el$1@news.Stanford.EDU> <eqebri$8jp$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170926580 25780 127.0.0.1 (8 Feb 2007 09:23:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqebri$8jp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11572

Neelima Balakrishnan wrote:
> Adam Cohen wrote:
>> If I had to guess, I'd say that it's a slight bug in the reference 
>> router.
>>
>> If you ping 171.67.71.23, the replies come as from IP  *.23, which is 
>> correct. When you traceroute to .23, the router eventually receives a 
>> packet addressed to .23 with a TTL of 1, but since it sends the 
>> ensuing ICMP Port Unreachable over "eth0", it probably mistakenly sets 
>> the ip_dst value to the IP for the eth0 interface, which is .20. I 
>> suppose I don't know if this is the "correct" behavior or "incorrect" 
>> behavior, but it's trivial enough to support either behavior in the 
>> router, so I'll let a TA make a ruling and then go with it.
>>
>>
>>
>> On 2007-02-07 18:19:34 -0800, "Ajay Martin" <ajaym@stanford.edu> said:
>>
>>>
>>> "Ajay Martin" <ajaym@stanford.edu> wrote in message 
>>> news:eqe19l$12a$1@news.Stanford.EDU...
>>>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>>>> news:eqc291$67v$1@news.Stanford.EDU...
>>>>> Hey,
>>>>>
>>>>> I tested traceroute against topo 2
>>>>>
>>>>> traceroute to 171.67.71.23 (171.67.71.23): 1-30 hops, 38 byte packets
>>>>> 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.419 ms  0.345 ms  0.328 ms
>>>>> 2  vns-firewall.Stanford.EDU (172.24.74.11)  0.240 ms (ttl=63!)  
>>>>> 0.254 ms (ttl=63!)  0.227 ms (ttl=63!)
>>>>> 3  171.67.71.20 (171.67.71.20)  2.00 ms  1.84 ms  1.86 ms
>>>>> myth24:~/Winter 2007/CS 244A/Assignment 2/sr_stub/stub>
>>>>>
>>>>> I'm confused. Why is the 3rd and final hop .20 instead of .23? I 
>>>>> would expect either 3 hops ending in .23 or 4 hops with the last 2 
>>>>> being .20 and .23 respectively.
>>>>>
>>>>> I read the RFC and the FAQ and am still confused.
>>>>>
>>>>> -- 
>>>>> David Gobaud
>>>>>
>>>>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>>>>> news:eqbrnb$q71$2@news.Stanford.EDU...
>>>>>> Try tracerouting to one of the interfaces on the reference 
>>>>>> topology (topo 2- I posted the corrected IPs earlier to the 
>>>>>> newsgroup).  Also, take a look at question 28 on the FAQ- that 
>>>>>> will help explain why the router behaves as it does.
>>>>>>
>>>>>> Clay
>>>>>> Euijong Whang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have the following IP addresses
>>>>>>> 192.168.128.139 (connected to the firewall)
>>>>>>> 192.168.128.140 (connected to the web server 192.168.128.141)
>>>>>>> 192.168.128.142 (connected to the web server 192.168.128.143)
>>>>>>>
>>>>>>> Question: Which IP of my router should be returned when I 
>>>>>>> traceroute 192.168.128.140
>>>>>>> from my computer? That is, what IP should be the source IP 
>>>>>>> address of the ICMP
>>>>>>> packet my router is returning? Is it 192.168.128.139 or 
>>>>>>> 192.168.128.140?
>>>>>>>
>>>>>>> The former seems reasonable because the packet is actually going 
>>>>>>> through the
>>>>>>> interface of 192.168.128.139. However, it is also true that I am 
>>>>>>> tracerouting
>>>>>>> 192.168.128.140, not 192.168.128.139.
>>>>>>>
>>>>>>> Best,
>>>>>>> Steven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> I second the confusion.
>>>>
>>>> if the router has ip's .19, .20 and .22
>>>> and the interface connected to the firewall has IP as .19,
>>>> should the final step of a traceroute to .20 (or .22) show up as to 
>>>> have come from .19 or .20 (or .22) ?
>>>>
>>>> for eg:
>>>> a ping on topo 2 to 171.67.71.22 shows the last step as the packet 
>>>> having been sent from 171.67.71.20, though i would think it makes 
>>>> sense for it to have been from *.22
>>>>
>>>> -- 
>>>> Ajay
>>>>
>>>
>>> Typo:
>>>   ... a *traceroute* on topo 2 ... 
>>
>>
> 
> 
> Can the TAs confirm which is the correct behavior?
> 
> Thanks
> Neelima

You only report one hop per device, so if your tracing to an ip on the 
router you only report that destination ip.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: is 192.168.128.86 down?
Date: Thu, 8 Feb 2007 09:42:32 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98D11163A5A8Dchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170927752 26027 128.12.22.217 (8 Feb 2007 09:42:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11573

for some reason, no one replies to my broadcast.

i used wireshark and all the data is valid in my broadcast packet and i 
broadcast through all 3 interfaces. how come no computer replies?


thanks.

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: is 192.168.128.86 down?
Date: Thu, 8 Feb 2007 10:29:47 +0000 (UTC)
Organization: Your Company
Lines: 16
Distribution: su
Message-ID: <Xns98D11966653EFchunkaiwstanfordedu@171.64.14.103>
References: <Xns98D11163A5A8Dchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170930587 28471 128.12.22.217 (8 Feb 2007 10:29:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11574

nvm. got it.


Chun Kai Wang <chunkaiw@stanford.edu> wrote in 
news:Xns98D11163A5A8Dchunkaiwstanfordedu@171.64.14.103:

> for some reason, no one replies to my broadcast.
> 
> i used wireshark and all the data is valid in my broadcast packet and i 
> broadcast through all 3 interfaces. how come no computer replies?
> 
> 
> thanks.
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: traceroute
Date: Thu, 8 Feb 2007 12:04:09 +0000 (UTC)
Organization: Your Company
Lines: 18
Distribution: su
Message-ID: <Xns98D129662E8BDchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170936249 3335 128.12.22.217 (8 Feb 2007 12:04:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11575

i get this for my traceroute:


elaine1:~> traceroute -n 192.168.128.88
traceroute to 192.168.128.88 (192.168.128.88): 1-30 hops, 38 byte packets
 1  171.64.15.65  113 ms  107 ms  114 ms
 2  172.24.74.11  113 ms (ttl=63!)  100 ms (ttl=63!)  76.9 ms (ttl=63!)
 3  *  *  *
 4  192.168.128.88  2333 ms (ttl=61!)  243 ms (ttl=61!)  12.7 ms (ttl=61!)



is that correct?

my gateway for 0.0.0.0 is not 172.24.74.11, its 172.24.74.17


help
.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Thu, 08 Feb 2007 06:51:50 -0800
Lines: 19
Distribution: su
Message-ID: <eqfde7$d3r$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqeikj$een$1@news.Stanford.EDU> <eqep47$o2q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170946311 13435 127.0.0.1 (8 Feb 2007 14:51:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqep47$o2q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11576

So should I silently drop it? or send some kind of ICMP?

Thanks,
-Seung


David Erickson 쓴 글:
> Seung H. Choi wrote:
>> My question was, say if a packet was received from eth0, and its dest IP
>> is not found on forwarding table, so the default behavior is forwarding
>> it to eth0, the collision domain. Should this be allowed in general 
>> case? I can see how ARP requests and ICMP echo messages will do this, 
>> but I just wonder if this is to be done in general, since if routing 
>> is correct, IP packet should never have arrived at my router.
> 
> As far as I know you never want to forward a packet back out the 
> interface it came in on, it just doesn't make sense.
> 
> -David
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to use web browser to test if I am remote?
Date: Thu, 08 Feb 2007 09:07:49 -0800
Lines: 63
Distribution: su
Message-ID: <pan.2007.02.08.17.07.46.51937@cs.stanford.edu>
References: <Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU> <C1EFB229.82A8%jpettit@stanford.edu> <pan.2007.02.08.04.17.57.854882@cs.stanford.edu> <eqeeav$b2b$1@news.Stanford.EDU>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170954001 18914 128.12.186.133 (8 Feb 2007 17:00:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11577

On Wed, 07 Feb 2007 22:00:51 -0800, Ajay Martin wrote:

> 
> "Paolo" <paolo@cs.stanford.edu> wrote in message 
> news:pan.2007.02.08.04.17.57.854882@cs.stanford.edu...
>> On Wed, 07 Feb 2007 16:43:21 -0800, Justin Pettit wrote:
>>
>>> You should be able to launch a web browser using X tunneled through SSH.
>>> You may need to use the "-Y" flag:
>>>
>>>     ssh -Y user@myth.stanford.edu
>>>
>>> If that doesn't work, you can use a text-based browser, like lynx:
>>>
>>>     lynx www.yahoo.com
>>>
>>> Obviously, you would replace "www.yahoo.com" with your local web server.
>>>
>>> --Justin
>>>
>>>
>>> On 2/7/07 4:06 PM, in article
>>> Pine.LNX.4.44.0702071600550.24334-100000@myth15.Stanford.EDU, "Ryan Chen"
>>> <ryanchen@stanford.edu> wrote:
>>>
>>>>
>>>> If I remote log in to myths, I am guessing I won't be able to launch a
>>>> local browser? (I am using Exceed, and it doesn't seem to work) I am a
>>>> remote student, so I can't come in to the labs...
>>>>
>>>> The assignment mentions that if my router is implemented correctly, I
>>>> should be able to download the posted files from the application 
>>>> servers?
>>>> Is there a way I can test it using command line? I have tried using
>>>> "telnet" to one of the application servers, but it seems to be giving me 
>>>> a
>>>> connection refused error message.
>>>>
>>>> Any pointer as to how to test the download from application servers is
>>>> appreciated. Thanks.
>>>>
>>
>> I managed to launch a web browser by using the -Y method. However, I am
>> confused about something. When I browse the web pages and the ftp server,
>> I see a flurry of activity on my router as it processes and forwards
>> packets, as expected. But when I download a file I don't see any activity
>> at all. The files successfully download though: for example I can transfer
>> the mp3 off of my afs to my home computer and play it.
>>
>> What is going on?
>>
>> Thanks
> 
> just make sure the address from which the file is being downloaded are fine.
> some of the links are hand links to vns-app-1.stanford.edu. or vns-app-2.xxx 
> etc.
> if you want to download those songs, try the direct http://<your ap 
> server::8888/ .
> 
> Ajay

Thanks Ajay, that worked :)

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Thu, 08 Feb 2007 09:47:12 -0800
Lines: 26
Distribution: su
Message-ID: <eqfnn0$km9$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqeikj$een$1@news.Stanford.EDU> <eqep47$o2q$1@news.Stanford.EDU> <eqfde7$d3r$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1170956832 21193 127.0.0.1 (8 Feb 2007 17:47:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqfde7$d3r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11578

Seung H. Choi wrote:
> So should I silently drop it? or send some kind of ICMP?
> 
> Thanks,
> -Seung
> 
> 
> David Erickson 쓴 글:
>> Seung H. Choi wrote:
>>> My question was, say if a packet was received from eth0, and its dest IP
>>> is not found on forwarding table, so the default behavior is forwarding
>>> it to eth0, the collision domain. Should this be allowed in general 
>>> case? I can see how ARP requests and ICMP echo messages will do this, 
>>> but I just wonder if this is to be done in general, since if routing 
>>> is correct, IP packet should never have arrived at my router.
>>
>> As far as I know you never want to forward a packet back out the 
>> interface it came in on, it just doesn't make sense.
>>
>> -David

If your only choice is to send it back where it came from then I believe 
that should be an ICMP host unreachable error, but you should examine 
the router and ICMP RFC's to make sure.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: everybody.mp3
Date: Thu, 08 Feb 2007 13:00:41 -0800
Lines: 19
Distribution: su
Message-ID: <C1F0CF79.830C%jpettit@stanford.edu>
References: <eqegji$cpn$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170968444 673 127.0.0.1 (8 Feb 2007 21:00:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: everybody.mp3
Thread-Index: AcdLxDDvb3/hire3EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11579

It's from Homestar Runner:

    http://www.homestarrunner.com/

--Justin


On 2/7/07 10:39 PM, in article eqegji$cpn$1@news.Stanford.EDU, "Euijong
Whang" <euijong@stanford.edu> wrote:

> 
> Hm.. that everybody song is pretty addictive.
> Where did you get it?  :-)
> 
> -Steven
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute
Date: Thu, 08 Feb 2007 13:01:44 -0800
Lines: 29
Distribution: su
Message-ID: <C1F0CFB8.830E%jpettit@stanford.edu>
References: <Xns98D129662E8BDchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170968504 673 127.0.0.1 (8 Feb 2007 21:01:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: traceroute
Thread-Index: AcdLxFZ8lMGCsre3EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11580

Try running Clack with your topology.

--Justin


On 2/8/07 4:04 AM, in article
Xns98D129662E8BDchunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> i get this for my traceroute:
> 
> 
> elaine1:~> traceroute -n 192.168.128.88
> traceroute to 192.168.128.88 (192.168.128.88): 1-30 hops, 38 byte packets
>  1  171.64.15.65  113 ms  107 ms  114 ms
>  2  172.24.74.11  113 ms (ttl=63!)  100 ms (ttl=63!)  76.9 ms (ttl=63!)
>  3  *  *  *
>  4  192.168.128.88  2333 ms (ttl=61!)  243 ms (ttl=61!)  12.7 ms (ttl=61!)
> 
> 
> 
> is that correct?
> 
> my gateway for 0.0.0.0 is not 172.24.74.11, its 172.24.74.17
> 
> 
> help


.

Path: shelby.stanford.edu!myth15.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [PA2] Is an ARP reply permanent?
Date: Thu, 8 Feb 2007 13:06:01 -0800
Lines: 19
Distribution: su
Message-ID: <Pine.LNX.4.44.0702081300180.3508-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170968767 914 171.64.15.56 (8 Feb 2007 21:06:07 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11581

So after reading David's post about having the first packet comes in to
spawn off an ARP requests and all subsequent packets put on the queue (for
a total of 5 seconds) and then send ICMP host unreachable to all packets,
here is my questions:

So say a batch of 10 packets arrive like the scenario mentioned about at
time t = 0, and then the first packet spawn off a thread to try to send
 5 ARP requests, after 5 seconds, no reply, we send 10 ICMP host
unreachable to all original sources.

Now about 20 minutes later, another batch of 10 packets arrive and is
destined to this same address, should we resend ARP requests or should we
think that "oh, this address is permanently unreachable"? If not,
is "sedning ICMP host unreachable" a drawing line, meaning any packets
after "sending ICMP host unreachable" destined to the same address will
again spawn off ARP requests?

Thanks for any clarification.

.

Path: shelby.stanford.edu!myth15.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] Is an ARP reply permanent?
Date: Thu, 8 Feb 2007 13:07:42 -0800
Lines: 25
Distribution: su
Message-ID: <Pine.LNX.4.44.0702081307050.3932-100000@myth15.Stanford.EDU>
References: <Pine.LNX.4.44.0702081300180.3508-100000@myth15.Stanford.EDU>
NNTP-Posting-Host: myth15.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1170968863 947 171.64.15.56 (8 Feb 2007 21:07:43 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.44.0702081300180.3508-100000@myth15.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11582

The title should have been "Is an ICMP host unreachable permanent?"

On Thu, 8 Feb 2007, Ryan Chen wrote:

> So after reading David's post about having the first packet comes in to
> spawn off an ARP requests and all subsequent packets put on the queue (for
> a total of 5 seconds) and then send ICMP host unreachable to all packets,
> here is my questions:
>
> So say a batch of 10 packets arrive like the scenario mentioned about at
> time t = 0, and then the first packet spawn off a thread to try to send
>  5 ARP requests, after 5 seconds, no reply, we send 10 ICMP host
> unreachable to all original sources.
>
> Now about 20 minutes later, another batch of 10 packets arrive and is
> destined to this same address, should we resend ARP requests or should we
> think that "oh, this address is permanently unreachable"? If not,
> is "sedning ICMP host unreachable" a drawing line, meaning any packets
> after "sending ICMP host unreachable" destined to the same address will
> again spawn off ARP requests?
>
> Thanks for any clarification.
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PA2] Is an ARP reply permanent?
Date: Thu, 08 Feb 2007 13:22:51 -0800
Lines: 38
Distribution: su
Message-ID: <C1F0D4AB.8315%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0702081300180.3508-100000@myth15.Stanford.EDU> <Pine.LNX.4.44.0702081307050.3932-100000@myth15.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170969775 1744 127.0.0.1 (8 Feb 2007 21:22:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: [PA2] Is an ARP reply permanent?
Thread-Index: AcdLx0mtiEB2d7e6EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11583

You should resend the ARP requests.  Consider the situation when a system
comes up with a new IP address.  Just because an IP address wasn't available
at one time doesn't mean that it never will.

--Justin


On 2/8/07 1:07 PM, in article
Pine.LNX.4.44.0702081307050.3932-100000@myth15.Stanford.EDU, "Ryan Chen"
<ryanchen@stanford.edu> wrote:

> The title should have been "Is an ICMP host unreachable permanent?"
> 
> On Thu, 8 Feb 2007, Ryan Chen wrote:
> 
>> So after reading David's post about having the first packet comes in to
>> spawn off an ARP requests and all subsequent packets put on the queue (for
>> a total of 5 seconds) and then send ICMP host unreachable to all packets,
>> here is my questions:
>> 
>> So say a batch of 10 packets arrive like the scenario mentioned about at
>> time t = 0, and then the first packet spawn off a thread to try to send
>>  5 ARP requests, after 5 seconds, no reply, we send 10 ICMP host
>> unreachable to all original sources.
>> 
>> Now about 20 minutes later, another batch of 10 packets arrive and is
>> destined to this same address, should we resend ARP requests or should we
>> think that "oh, this address is permanently unreachable"? If not,
>> is "sedning ICMP host unreachable" a drawing line, meaning any packets
>> after "sending ICMP host unreachable" destined to the same address will
>> again spawn off ARP requests?
>> 
>> Thanks for any clarification.
>> 
>> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: myth firefox
Date: Fri, 9 Feb 2007 01:47:53 +0000 (UTC)
Organization: Your Company
Lines: 12
Distribution: su
Message-ID: <Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170985673 15338 128.12.22.217 (9 Feb 2007 01:47:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11584

for some reason, i can't run firefox anymore. the message tells me that i 
have to close firefox before i run it.


i did ps -efl and couldn't find firefox there, i did ps -u chunkaiw and 
still can't find it.


what can i do now if i wana test my router?


thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: myth firefox
Date: Thu, 08 Feb 2007 18:12:41 -0800
Lines: 26
Distribution: su
Message-ID: <C1F11899.832D%jpettit@stanford.edu>
References: <Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170987165 16713 127.0.0.1 (9 Feb 2007 02:12:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: myth firefox
Thread-Index: AcdL78bsBZWlkbfjEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11585

My guess is that you are running Firefox on a different Myth than you are
running "ps" or it died and left some sort of marker file sitting around.
If you can't figure out how to get it working, you can try some of CLI-based
web clients like "lynx" or "wget".

--Justin


On 2/8/07 5:47 PM, in article
Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> for some reason, i can't run firefox anymore. the message tells me that i
> have to close firefox before i run it.
> 
> 
> i did ps -efl and couldn't find firefox there, i did ps -u chunkaiw and
> still can't find it.
> 
> 
> what can i do now if i wana test my router?
> 
> 
> thanks.


.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: myth firefox
Date: Thu, 08 Feb 2007 21:11:20 -0500
Lines: 19
Distribution: su
Message-ID: <eqglb1$g50$1@news.Stanford.EDU>
References: <Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170987169 16544 127.0.0.1 (9 Feb 2007 02:12:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
In-Reply-To: <Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11586

This worked for me.  In your home directory,

	rm -rf .mozilla
	firefox &


Chun Kai Wang wrote:
> for some reason, i can't run firefox anymore. the message tells me that i 
> have to close firefox before i run it.
> 
> 
> i did ps -efl and couldn't find firefox there, i did ps -u chunkaiw and 
> still can't find it.
> 
> 
> what can i do now if i wana test my router?
> 
> 
> thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: myth firefox
Date: Fri, 9 Feb 2007 02:18:05 +0000 (UTC)
Organization: Your Company
Lines: 25
Distribution: su
Message-ID: <Xns98D1BA2D939E4chunkaiwstanfordedu@171.64.14.103>
References: <Xns98D1B50E9670Achunkaiwstanfordedu@171.64.14.103> <eqglb1$g50$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170987485 16311 128.12.22.217 (9 Feb 2007 02:18:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11587

perfect! thanks.

Jin Wang <jinwang@stanford.edu> wrote in
news:eqglb1$g50$1@news.Stanford.EDU: 

> This worked for me.  In your home directory,
> 
>      rm -rf .mozilla
>      firefox &
> 
> 
> Chun Kai Wang wrote:
>> for some reason, i can't run firefox anymore. the message tells me
>> that i have to close firefox before i run it.
>> 
>> 
>> i did ps -efl and couldn't find firefox there, i did ps -u chunkaiw
>> and still can't find it.
>> 
>> 
>> what can i do now if i wana test my router?
>> 
>> 
>> thanks.

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: trace route behavior
Date: Fri, 9 Feb 2007 02:20:15 +0000 (UTC)
Organization: Your Company
Lines: 14
Distribution: su
Message-ID: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170987615 16311 128.12.22.217 (9 Feb 2007 02:20:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11588

when i trace route to a app server (clack), it works and you can see the ip 
of my router (now clack).


but when i trace route when my router is running, i see *** for my router 
IP.


then I look at the IP packets, the reason is trace route sends UDP with 
TTL1, with source = host, destination = appserver, thus, my router, when it 
sees it, drops the packet and sends a timeout ICMP


why is my router not acting correctly???
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Thu, 8 Feb 2007 19:27:45 -0700
Lines: 37
Distribution: su
Message-ID: <eqgm74$h0b$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqeikj$een$1@news.Stanford.EDU> <eqep47$o2q$1@news.Stanford.EDU> <eqfde7$d3r$1@news.Stanford.EDU> <eqfnn0$km9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1170988068 17419 127.0.0.1 (9 Feb 2007 02:27:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11589

Based on RFC 1812, it seems to me this should be a "network unreachable" 
error, not a "host unreachable" error.  See pp. 80-81.  That's what I'm 
going to implement unless the TAs disagree.  TA comments?

--Kevin

"David Erickson" <derickso@stanford.edu> wrote in message 
news:eqfnn0$km9$1@news.Stanford.EDU...
> Seung H. Choi wrote:
>> So should I silently drop it? or send some kind of ICMP?
>>
>> Thanks,
>> -Seung
>>
>>
>> David Erickson ? ?:
>>> Seung H. Choi wrote:
>>>> My question was, say if a packet was received from eth0, and its dest 
>>>> IP
>>>> is not found on forwarding table, so the default behavior is forwarding
>>>> it to eth0, the collision domain. Should this be allowed in general 
>>>> case? I can see how ARP requests and ICMP echo messages will do this, 
>>>> but I just wonder if this is to be done in general, since if routing is 
>>>> correct, IP packet should never have arrived at my router.
>>>
>>> As far as I know you never want to forward a packet back out the 
>>> interface it came in on, it just doesn't make sense.
>>>
>>> -David
>
> If your only choice is to send it back where it came from then I believe 
> that should be an ICMP host unreachable error, but you should examine the 
> router and ICMP RFC's to make sure.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Thu, 08 Feb 2007 18:43:00 -0800
Lines: 28
Distribution: su
Message-ID: <C1F11FB4.8338%jpettit@stanford.edu>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170988986 18101 127.0.0.1 (9 Feb 2007 02:43:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: trace route behavior
Thread-Index: AcdL9AMhQbyWMLfnEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11590

Try running jethereal on Clack to see what the packets look like.  Then,
have your router dump the packets you are generating and look at them in
Wireshark to make sure they look like the ones produced by Clack.  Make sure
that you are generating valid TTLs and checksums.

--Justin
 

On 2/8/07 6:20 PM, in article
Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> when i trace route to a app server (clack), it works and you can see the ip
> of my router (now clack).
> 
> 
> but when i trace route when my router is running, i see *** for my router
> IP.
> 
> 
> then I look at the IP packets, the reason is trace route sends UDP with
> TTL1, with source = host, destination = appserver, thus, my router, when it
> sees it, drops the packet and sends a timeout ICMP
> 
> 
> why is my router not acting correctly???


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Fri, 9 Feb 2007 02:49:32 +0000 (UTC)
Organization: Your Company
Lines: 45
Distribution: su
Message-ID: <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170989372 16311 128.12.22.217 (9 Feb 2007 02:49:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11591

i did and all my values are the same except:

1.) my ttl is 60 not 63
2.) ICMP body is all 0

and of course, the checksum for IP and ICMP is different with clack. but 
that's it...





Justin Pettit <jpettit@stanford.edu> wrote in
news:C1F11FB4.8338%jpettit@stanford.edu: 

> Try running jethereal on Clack to see what the packets look like. 
> Then, have your router dump the packets you are generating and look at
> them in Wireshark to make sure they look like the ones produced by
> Clack.  Make sure that you are generating valid TTLs and checksums.
> 
> --Justin
>  
> 
> On 2/8/07 6:20 PM, in article
> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
> <chunkaiw@stanford.edu> wrote:
> 
>> when i trace route to a app server (clack), it works and you can see
>> the ip of my router (now clack).
>> 
>> 
>> but when i trace route when my router is running, i see *** for my
>> router IP.
>> 
>> 
>> then I look at the IP packets, the reason is trace route sends UDP
>> with TTL1, with source = host, destination = appserver, thus, my
>> router, when it sees it, drops the packet and sends a timeout ICMP
>> 
>> 
>> why is my router not acting correctly???
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Fri, 9 Feb 2007 02:51:51 +0000 (UTC)
Organization: Your Company
Lines: 63
Distribution: su
Message-ID: <Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu> <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170989511 16311 128.12.22.217 (9 Feb 2007 02:51:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11592

oh and same thing for telnet. when i telnet to clack, it is fast and 
says port unreachable.

when i telnet to my router, it just keeps waiting...







Chun Kai Wang <chunkaiw@stanford.edu> wrote in 
news:Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103:

> i did and all my values are the same except:
> 
> 1.) my ttl is 60 not 63
> 2.) ICMP body is all 0
> 
> and of course, the checksum for IP and ICMP is different with clack. 
but 
> that's it...
> 
> 
> 
> 
> 
> Justin Pettit <jpettit@stanford.edu> wrote in
> news:C1F11FB4.8338%jpettit@stanford.edu: 
> 
>> Try running jethereal on Clack to see what the packets look like. 
>> Then, have your router dump the packets you are generating and look 
at
>> them in Wireshark to make sure they look like the ones produced by
>> Clack.  Make sure that you are generating valid TTLs and checksums.
>> 
>> --Justin
>>  
>> 
>> On 2/8/07 6:20 PM, in article
>> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>> <chunkaiw@stanford.edu> wrote:
>> 
>>> when i trace route to a app server (clack), it works and you can see
>>> the ip of my router (now clack).
>>> 
>>> 
>>> but when i trace route when my router is running, i see *** for my
>>> router IP.
>>> 
>>> 
>>> then I look at the IP packets, the reason is trace route sends UDP
>>> with TTL1, with source = host, destination = appserver, thus, my
>>> router, when it sees it, drops the packet and sends a timeout ICMP
>>> 
>>> 
>>> why is my router not acting correctly???
>> 
>> 
>> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Thu, 08 Feb 2007 18:57:32 -0800
Lines: 76
Distribution: su
Message-ID: <C1F1231C.833E%jpettit@stanford.edu>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu> <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103> <Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170989855 18684 127.0.0.1 (9 Feb 2007 02:57:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: trace route behavior
Thread-Index: AcdL9griSTeo2rfpEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11593

It doesn't sound like you're sending proper ICMP packets.  As David
mentioned last night, you need to carefully implement the RFCs.  Use Clack's
output as a reference.

--Justin


On 2/8/07 6:51 PM, in article
Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> oh and same thing for telnet. when i telnet to clack, it is fast and
> says port unreachable.
> 
> when i telnet to my router, it just keeps waiting...
> 
> 
> 
> 
> 
> 
> 
> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
> news:Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103:
> 
>> i did and all my values are the same except:
>> 
>> 1.) my ttl is 60 not 63
>> 2.) ICMP body is all 0
>> 
>> and of course, the checksum for IP and ICMP is different with clack.
> but 
>> that's it...
>> 
>> 
>> 
>> 
>> 
>> Justin Pettit <jpettit@stanford.edu> wrote in
>> news:C1F11FB4.8338%jpettit@stanford.edu:
>> 
>>> Try running jethereal on Clack to see what the packets look like.
>>> Then, have your router dump the packets you are generating and look
> at
>>> them in Wireshark to make sure they look like the ones produced by
>>> Clack.  Make sure that you are generating valid TTLs and checksums.
>>> 
>>> --Justin
>>>  
>>> 
>>> On 2/8/07 6:20 PM, in article
>>> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>>> <chunkaiw@stanford.edu> wrote:
>>> 
>>>> when i trace route to a app server (clack), it works and you can see
>>>> the ip of my router (now clack).
>>>> 
>>>> 
>>>> but when i trace route when my router is running, i see *** for my
>>>> router IP.
>>>> 
>>>> 
>>>> then I look at the IP packets, the reason is trace route sends UDP
>>>> with TTL1, with source = host, destination = appserver, thus, my
>>>> router, when it sees it, drops the packet and sends a timeout ICMP
>>>> 
>>>> 
>>>> why is my router not acting correctly???
>>> 
>>> 
>>> 
>> 
>> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Thu, 08 Feb 2007 20:01:55 -0800
Lines: 47
Distribution: su
Message-ID: <C1F13233.8341%jpettit@stanford.edu>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqeikj$een$1@news.Stanford.EDU> <eqep47$o2q$1@news.Stanford.EDU> <eqfde7$d3r$1@news.Stanford.EDU> <eqfnn0$km9$1@news.Stanford.EDU> <eqgm74$h0b$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170993721 21374 127.0.0.1 (9 Feb 2007 04:02:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Repost: traffic coming back out on the same interface
Thread-Index: AcdL/wlpSBkMErfyEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11594

That seems very reasonable to me.

--Justin


On 2/8/07 6:27 PM, in article eqgm74$h0b$1@news.Stanford.EDU, "Kevin Hart"
<kevin.hart@hp.com> wrote:

> Based on RFC 1812, it seems to me this should be a "network unreachable"
> error, not a "host unreachable" error.  See pp. 80-81.  That's what I'm
> going to implement unless the TAs disagree.  TA comments?
> 
> --Kevin
> 
> "David Erickson" <derickso@stanford.edu> wrote in message
> news:eqfnn0$km9$1@news.Stanford.EDU...
>> Seung H. Choi wrote:
>>> So should I silently drop it? or send some kind of ICMP?
>>> 
>>> Thanks,
>>> -Seung
>>> 
>>> 
>>> David Erickson ? ?:
>>>> Seung H. Choi wrote:
>>>>> My question was, say if a packet was received from eth0, and its dest
>>>>> IP
>>>>> is not found on forwarding table, so the default behavior is forwarding
>>>>> it to eth0, the collision domain. Should this be allowed in general
>>>>> case? I can see how ARP requests and ICMP echo messages will do this,
>>>>> but I just wonder if this is to be done in general, since if routing is
>>>>> correct, IP packet should never have arrived at my router.
>>>> 
>>>> As far as I know you never want to forward a packet back out the
>>>> interface it came in on, it just doesn't make sense.
>>>> 
>>>> -David
>> 
>> If your only choice is to send it back where it came from then I believe
>> that should be an ICMP host unreachable error, but you should examine the
>> router and ICMP RFC's to make sure.
>> 
>> -David 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Fri, 9 Feb 2007 04:28:53 +0000 (UTC)
Organization: Your Company
Lines: 101
Distribution: su
Message-ID: <Xns98D1D05A7AD76chunkaiwstanfordedu@171.64.14.103>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu> <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103> <Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103> <C1F1231C.833E%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170995333 21371 128.12.22.217 (9 Feb 2007 04:28:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11595

thanks, i got it working now, but when i traceroute my interface, i get:


elaine15:~> traceroute -n 192.168.128.84
traceroute to 192.168.128.84 (192.168.128.84): 1-30 hops, 38 byte 
packets
 1  171.64.15.65  0.802 ms  0.474 ms  0.349 ms
 2  172.24.74.11  0.308 ms (ttl=63!)  0.334 ms (ttl=63!)  0.341 ms (ttl=
63!)
 3  192.168.128.84  1.98 ms  1.87 ms  1.84 ms


instead of what clack has, which is *******


is clack correct?




Justin Pettit <jpettit@stanford.edu> wrote in
news:C1F1231C.833E%jpettit@stanford.edu: 

> It doesn't sound like you're sending proper ICMP packets.  As David
> mentioned last night, you need to carefully implement the RFCs.  Use
> Clack's output as a reference.
> 
> --Justin
> 
> 
> On 2/8/07 6:51 PM, in article
> Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
> <chunkaiw@stanford.edu> wrote:
> 
>> oh and same thing for telnet. when i telnet to clack, it is fast and
>> says port unreachable.
>> 
>> when i telnet to my router, it just keeps waiting...
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
>> news:Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103:
>> 
>>> i did and all my values are the same except:
>>> 
>>> 1.) my ttl is 60 not 63
>>> 2.) ICMP body is all 0
>>> 
>>> and of course, the checksum for IP and ICMP is different with clack.
>> but 
>>> that's it...
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Justin Pettit <jpettit@stanford.edu> wrote in
>>> news:C1F11FB4.8338%jpettit@stanford.edu:
>>> 
>>>> Try running jethereal on Clack to see what the packets look like.
>>>> Then, have your router dump the packets you are generating and look
>> at
>>>> them in Wireshark to make sure they look like the ones produced by
>>>> Clack.  Make sure that you are generating valid TTLs and checksums.
>>>> 
>>>> --Justin
>>>>  
>>>> 
>>>> On 2/8/07 6:20 PM, in article
>>>> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>>>> <chunkaiw@stanford.edu> wrote:
>>>> 
>>>>> when i trace route to a app server (clack), it works and you can
>>>>> see the ip of my router (now clack).
>>>>> 
>>>>> 
>>>>> but when i trace route when my router is running, i see *** for my
>>>>> router IP.
>>>>> 
>>>>> 
>>>>> then I look at the IP packets, the reason is trace route sends UDP
>>>>> with TTL1, with source = host, destination = appserver, thus, my
>>>>> router, when it sees it, drops the packet and sends a timeout ICMP
>>>>> 
>>>>> 
>>>>> why is my router not acting correctly???
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Fri, 9 Feb 2007 04:35:41 +0000 (UTC)
Organization: Your Company
Lines: 130
Distribution: su
Message-ID: <Xns98D1D181B64E0chunkaiwstanfordedu@171.64.14.103>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu> <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103> <Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103> <C1F1231C.833E%jpettit@stanford.edu> <Xns98D1D05A7AD76chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1170995741 21371 128.12.22.217 (9 Feb 2007 04:35:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11596

i just re-read the assignment and it seems that mine is correct because 
as one of the requred functionality, "the reouter handles tcp/udp 
packets sent to one of its interface ... respond ... port unreachable" 


whereas i'm probing clack and it just drops packets that go to udp 
(traceroute), and hence you see ****



is my implementation correct?





Chun Kai Wang <chunkaiw@stanford.edu> wrote in 
news:Xns98D1D05A7AD76chunkaiwstanfordedu@171.64.14.103:

> thanks, i got it working now, but when i traceroute my interface, i 
get:
> 
> 
> elaine15:~> traceroute -n 192.168.128.84
> traceroute to 192.168.128.84 (192.168.128.84): 1-30 hops, 38 byte 
> packets
>  1  171.64.15.65  0.802 ms  0.474 ms  0.349 ms
>  2  172.24.74.11  0.308 ms (ttl=63!)  0.334 ms (ttl=63!)  0.341 ms 
(ttl=
> 63!)
>  3  192.168.128.84  1.98 ms  1.87 ms  1.84 ms
> 
> 
> instead of what clack has, which is *******
> 
> 
> is clack correct?
> 
> 
> 
> 
> Justin Pettit <jpettit@stanford.edu> wrote in
> news:C1F1231C.833E%jpettit@stanford.edu: 
> 
>> It doesn't sound like you're sending proper ICMP packets.  As David
>> mentioned last night, you need to carefully implement the RFCs.  Use
>> Clack's output as a reference.
>> 
>> --Justin
>> 
>> 
>> On 2/8/07 6:51 PM, in article
>> Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>> <chunkaiw@stanford.edu> wrote:
>> 
>>> oh and same thing for telnet. when i telnet to clack, it is fast and
>>> says port unreachable.
>>> 
>>> when i telnet to my router, it just keeps waiting...
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
>>> news:Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103:
>>> 
>>>> i did and all my values are the same except:
>>>> 
>>>> 1.) my ttl is 60 not 63
>>>> 2.) ICMP body is all 0
>>>> 
>>>> and of course, the checksum for IP and ICMP is different with 
clack.
>>> but 
>>>> that's it...
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Justin Pettit <jpettit@stanford.edu> wrote in
>>>> news:C1F11FB4.8338%jpettit@stanford.edu:
>>>> 
>>>>> Try running jethereal on Clack to see what the packets look like.
>>>>> Then, have your router dump the packets you are generating and 
look
>>> at
>>>>> them in Wireshark to make sure they look like the ones produced by
>>>>> Clack.  Make sure that you are generating valid TTLs and 
checksums.
>>>>> 
>>>>> --Justin
>>>>>  
>>>>> 
>>>>> On 2/8/07 6:20 PM, in article
>>>>> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>>>>> <chunkaiw@stanford.edu> wrote:
>>>>> 
>>>>>> when i trace route to a app server (clack), it works and you can
>>>>>> see the ip of my router (now clack).
>>>>>> 
>>>>>> 
>>>>>> but when i trace route when my router is running, i see *** for 
my
>>>>>> router IP.
>>>>>> 
>>>>>> 
>>>>>> then I look at the IP packets, the reason is trace route sends 
UDP
>>>>>> with TTL1, with source = host, destination = appserver, thus, my
>>>>>> router, when it sees it, drops the packet and sends a timeout 
ICMP
>>>>>> 
>>>>>> 
>>>>>> why is my router not acting correctly???
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Routing table entries
Date: Fri, 9 Feb 2007 05:05:01 +0000 (UTC)
Lines: 6
Distribution: su
Message-ID: <eqgvdt$n6b$1@news.Stanford.EDU>
NNTP-Posting-Host: myth25.stanford.edu
X-Trace: news.Stanford.EDU 1170997501 23755 171.64.15.40 (9 Feb 2007 05:05:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11597



My routing table has just the default interface eth0. 
How do I add entries to the table?
Are we supposed to handle this part too?

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing table entries
Date: Thu, 08 Feb 2007 21:20:09 -0800
Lines: 17
Distribution: su
Message-ID: <C1F14489.8349%jpettit@stanford.edu>
References: <eqgvdt$n6b$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1170998627 24755 127.0.0.1 (9 Feb 2007 05:23:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Routing table entries
Thread-Index: AcdMCfdBNeKMZLf9EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11598

This is clearly explained in the assignment description.  It has also been
previously discussed in the newsgroup.

--Justin


On 2/8/07 9:05 PM, in article eqgvdt$n6b$1@news.Stanford.EDU, "Dina Thomas"
<dinat@Stanford.EDU> wrote:

> 
> 
> My routing table has just the default interface eth0.
> How do I add entries to the table?
> Are we supposed to handle this part too?
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: trace route behavior
Date: Thu, 8 Feb 2007 21:40:01 -0800
Lines: 141
Distribution: su
Message-ID: <eqh1e1$opo$1@news.Stanford.EDU>
References: <Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103> <C1F11FB4.8338%jpettit@stanford.edu> <Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103> <Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103> <C1F1231C.833E%jpettit@stanford.edu> <Xns98D1D05A7AD76chunkaiwstanfordedu@171.64.14.103> <Xns98D1D181B64E0chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1170999554 25400 127.0.0.1 (9 Feb 2007 05:39:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11599

Search for earlier post about ICMP and Clack.

Sincerely,
Randy Jennings

The squirrels are your friends!

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98D1D181B64E0chunkaiwstanfordedu@171.64.14.103...
>i just re-read the assignment and it seems that mine is correct because
> as one of the requred functionality, "the reouter handles tcp/udp
> packets sent to one of its interface ... respond ... port unreachable"
>
>
> whereas i'm probing clack and it just drops packets that go to udp
> (traceroute), and hence you see ****
>
>
>
> is my implementation correct?
>
>
>
>
>
> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
> news:Xns98D1D05A7AD76chunkaiwstanfordedu@171.64.14.103:
>
>> thanks, i got it working now, but when i traceroute my interface, i
> get:
>>
>>
>> elaine15:~> traceroute -n 192.168.128.84
>> traceroute to 192.168.128.84 (192.168.128.84): 1-30 hops, 38 byte
>> packets
>>  1  171.64.15.65  0.802 ms  0.474 ms  0.349 ms
>>  2  172.24.74.11  0.308 ms (ttl=63!)  0.334 ms (ttl=63!)  0.341 ms
> (ttl=
>> 63!)
>>  3  192.168.128.84  1.98 ms  1.87 ms  1.84 ms
>>
>>
>> instead of what clack has, which is *******
>>
>>
>> is clack correct?
>>
>>
>>
>>
>> Justin Pettit <jpettit@stanford.edu> wrote in
>> news:C1F1231C.833E%jpettit@stanford.edu:
>>
>>> It doesn't sound like you're sending proper ICMP packets.  As David
>>> mentioned last night, you need to carefully implement the RFCs.  Use
>>> Clack's output as a reference.
>>>
>>> --Justin
>>>
>>>
>>> On 2/8/07 6:51 PM, in article
>>> Xns98D1BFE6B751Dchunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>>> <chunkaiw@stanford.edu> wrote:
>>>
>>>> oh and same thing for telnet. when i telnet to clack, it is fast and
>>>> says port unreachable.
>>>>
>>>> when i telnet to my router, it just keeps waiting...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
>>>> news:Xns98D1BF82C954Cchunkaiwstanfordedu@171.64.14.103:
>>>>
>>>>> i did and all my values are the same except:
>>>>>
>>>>> 1.) my ttl is 60 not 63
>>>>> 2.) ICMP body is all 0
>>>>>
>>>>> and of course, the checksum for IP and ICMP is different with
> clack.
>>>> but
>>>>> that's it...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Justin Pettit <jpettit@stanford.edu> wrote in
>>>>> news:C1F11FB4.8338%jpettit@stanford.edu:
>>>>>
>>>>>> Try running jethereal on Clack to see what the packets look like.
>>>>>> Then, have your router dump the packets you are generating and
> look
>>>> at
>>>>>> them in Wireshark to make sure they look like the ones produced by
>>>>>> Clack.  Make sure that you are generating valid TTLs and
> checksums.
>>>>>>
>>>>>> --Justin
>>>>>>
>>>>>>
>>>>>> On 2/8/07 6:20 PM, in article
>>>>>> Xns98D1BA8BB7D44chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
>>>>>> <chunkaiw@stanford.edu> wrote:
>>>>>>
>>>>>>> when i trace route to a app server (clack), it works and you can
>>>>>>> see the ip of my router (now clack).
>>>>>>>
>>>>>>>
>>>>>>> but when i trace route when my router is running, i see *** for
> my
>>>>>>> router IP.
>>>>>>>
>>>>>>>
>>>>>>> then I look at the IP packets, the reason is trace route sends
> UDP
>>>>>>> with TTL1, with source = host, destination = appserver, thus, my
>>>>>>> router, when it sees it, drops the packet and sends a timeout
> ICMP
>>>>>>>
>>>>>>>
>>>>>>> why is my router not acting correctly???
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: not getting packets
Date: Thu, 08 Feb 2007 22:03:29 -0800
Lines: 8
Distribution: su
Message-ID: <eqh2rk$poi$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171001012 26386 127.0.0.1 (9 Feb 2007 06:03:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11600

Hi,

All of sudden, my router is not getting any packets. Is there anyone
else with similar problems?


Thanks,
-Seung
.

Path: shelby.stanford.edu!not-for-mail
From: "Seung H. Choi" <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: not getting packets
Date: Thu, 08 Feb 2007 22:15:15 -0800
Lines: 26
Distribution: su
Message-ID: <eqh3hl$qa0$1@news.Stanford.EDU>
References: <eqh2rk$poi$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171001717 26944 127.0.0.1 (9 Feb 2007 06:15:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqh2rk$poi$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11601

I thought this was CPU being too busy, but my stack looks like this:

#0  0xffffe410 in ?? ()
#1  0xbf920258 in ?? ()
#2  0xb7effadc in ?? () from /lib/tls/i686/cmov/libc.so.6
#3  0xbf920210 in ?? ()
#4  0xb7f16878 in recv () from /lib/tls/i686/cmov/libpthread.so.0
#5  0x0804ad5d in sr_read_from_server (sr=0xbf920290) at sr_vns_comm.c:241
#6  0x08049c1a in main (argc=5, argv=0xbf9203e4) at sr_main.c:149


And it gets packets very sporadically while I'm pinging to its interface.

Thanks,
-Seung


Seung H. Choi ¾´ ±Û:
> Hi,
> 
> All of sudden, my router is not getting any packets. Is there anyone
> else with similar problems?
> 
> 
> Thanks,
> -Seung
.

Path: shelby.stanford.edu!not-for-mail
From: Sanjay Jeyakumar <sjeyakum@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: firewall not responding
Date: Fri, 9 Feb 2007 10:49:22 +0000 (UTC)
Lines: 7
Distribution: su
Message-ID: <eqhjji$ccf$1@news.Stanford.EDU>
NNTP-Posting-Host: myth29.stanford.edu
X-Trace: news.Stanford.EDU 1171018162 12687 171.64.15.44 (9 Feb 2007 10:49:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11602


The firewall at 172.24.74.11 is not responding and seems to have
crashed. Thus none of the packets are being forwarded to the virtual
routers. Hope one of the TAs can take a look at this.

Thanks,
Sanjay
.

Path: shelby.stanford.edu!not-for-mail
From: Benjamin Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Routing table entries
Date: Fri, 09 Feb 2007 03:13:47 -0800
Lines: 10
Distribution: su
Message-ID: <eqhl1c$duj$1@news.Stanford.EDU>
References: <eqgvdt$n6b$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171019628 14291 128.12.94.22 (9 Feb 2007 11:13:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqgvdt$n6b$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11603

Check the first e-mail about PA2, there should have been a custom rtable 
file for your topology in it.

Ben

Dina Thomas wrote:
> My routing table has just the default interface eth0. 
> How do I add entries to the table?
> Are we supposed to handle this part too?
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ICMP destination unreachable message
Date: Fri, 09 Feb 2007 09:38:41 -0800
Lines: 22
Distribution: su
Message-ID: <eqibj2$6jj$1@news.Stanford.EDU>
NNTP-Posting-Host: hr-chyoon-1158559642.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171042722 6771 171.66.147.181 (9 Feb 2007 17:38:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11604

I think both my port unreachable and host unreachable messages are not 
being matched by the client. Tcpdump says bad hdr length, but I think I 
exactly matched the RFC for ICMP dest unreachable. I sniffed at real 
ICMP messages and they seem to be longer (at 90 bytes). Is there 
something I am missing?

here's the tcpdump of the icmp port unreachable message i send out.


08:41:33.537949 70:00:00:ab:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui 
Unknown), ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl  64, id 0, 
offset 0, flags [none], proto: ICMP (1), length: 56) 
wsr23-router-1.stanford.edu > hr-chyoon-1158559642.stanford.edu: ICMP 
wsr23-router-1.stanford.edu tcp port http unreachable, length 36
         (tos 0x0, ttl  60, id 19735, offset 0, flags [DF], proto: TCP 
(6), length: 64) hr-chyoon-1158559642.stanford.edu.52877 > 
wsr23-router-1.stanford.edu.http:  tcp 44 [bad hdr length 0 - too short, 
< 20]
         0x0000:  4500 0038 0000 0000 4001 facb c0a8 8059
         0x0010:  ab42 93b5 0303 c6d5 0000 0000 4500 0040
         0x0020:  4d17 4000 3c06 71a7 ab42 93b5 c0a8 8059
         0x0030:  ce8d 0050 db92 8bb6
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: firewall not responding
Date: Fri, 09 Feb 2007 09:58:37 -0800
Lines: 18
Distribution: su
Message-ID: <C1F1F64D.8376%jpettit@stanford.edu>
References: <eqhjji$ccf$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171043919 8013 127.0.0.1 (9 Feb 2007 17:58:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: firewall not responding
Thread-Index: AcdMc+wiKpPhwrhnEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11605

I just heard from on high that the firewall is up and the demo router on
topology 2 is still reachable.

--Justin


On 2/9/07 2:49 AM, in article eqhjji$ccf$1@news.Stanford.EDU, "Sanjay
Jeyakumar" <sjeyakum@Stanford.EDU> wrote:

> 
> The firewall at 172.24.74.11 is not responding and seems to have
> crashed. Thus none of the packets are being forwarded to the virtual
> routers. Hope one of the TAs can take a look at this.
> 
> Thanks,
> Sanjay


.

Path: shelby.stanford.edu!myth18.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: traceroute output
Date: Fri, 9 Feb 2007 10:12:41 -0800
Lines: 29
Distribution: su
Message-ID: <Pine.LNX.4.44.0702091009570.9338-100000@myth18.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171044762 8794 171.64.15.61 (9 Feb 2007 18:12:42 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11606

Hi,

I'm seeing some difference that I can't parse myself.

traceroute to my router :
traceroute to 192.168.129.78 (192.168.129.78): 1-30 hops, 38 byte packets
 1  171.64.15.1  0.549 ms  0.306 ms  0.240 ms
 2  172.24.74.11  0.234 ms (ttl=63!)  0.238 ms (ttl=63!)  0.241 ms
(ttl=63!)
 3  192.168.129.78  2.74 ms (ttl=62!) !A  1.85 ms (ttl=62!) !A  2.64 ms
(ttl=62!) !A

traceroute to reference router :
traceroute to 171.67.71.20 (171.67.71.20): 1-30 hops, 38 byte packets
 1  171.64.15.1  0.409 ms  0.208 ms  0.239 ms
 2  172.24.74.11  0.234 ms (ttl=63!)  0.238 ms (ttl=63!)  0.242 ms
(ttl=63!)
 3  171.67.71.20  2.12 ms  1.86 ms  1.87 ms


I'm seeing (ttl=62!) !A for each packet my router sent back, which I don't
see in reference one. How does it know the exact number of hops back to
the source, and what's !A?


Thanks,
-Seung


.

Path: shelby.stanford.edu!myth18.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ICMP source
Date: Fri, 9 Feb 2007 10:40:17 -0800
Lines: 12
Distribution: su
Message-ID: <Pine.LNX.4.44.0702091038220.10262-100000@myth18.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171046418 10055 171.64.15.61 (9 Feb 2007 18:40:18 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11607

Hi,

When sending out ICMP message, what should the source interface be?
It seems that we should calculate the source interface by consulting
rtable, according to the previous posts, but reference router simply takes
the destination interface of ICMP timeout as the source interface. (during
traceroute)


Thanks,
-Seung

.

Path: shelby.stanford.edu!myth18.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: traceroute output
Date: Fri, 9 Feb 2007 10:51:55 -0800
Lines: 45
Distribution: su
Message-ID: <Pine.LNX.4.44.0702091050450.10919-100000@myth18.Stanford.EDU>
References: <Pine.LNX.4.44.0702091009570.9338-100000@myth18.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171047117 10776 171.64.15.61 (9 Feb 2007 18:51:57 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.44.0702091009570.9338-100000@myth18.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11608

I'm answering my own question...

FYI,

!A means the router is not properly sending host unreachable ICMP.

ttl=63! means that ttl value of received packet is unconventional.


Thanks,
-Seung

On Fri, 9 Feb 2007, Seung Hoon Choi wrote:

> Hi,
>
> I'm seeing some difference that I can't parse myself.
>
> traceroute to my router :
> traceroute to 192.168.129.78 (192.168.129.78): 1-30 hops, 38 byte packets
>  1  171.64.15.1  0.549 ms  0.306 ms  0.240 ms
>  2  172.24.74.11  0.234 ms (ttl=63!)  0.238 ms (ttl=63!)  0.241 ms
> (ttl=63!)
>  3  192.168.129.78  2.74 ms (ttl=62!) !A  1.85 ms (ttl=62!) !A  2.64 ms
> (ttl=62!) !A
>
> traceroute to reference router :
> traceroute to 171.67.71.20 (171.67.71.20): 1-30 hops, 38 byte packets
>  1  171.64.15.1  0.409 ms  0.208 ms  0.239 ms
>  2  172.24.74.11  0.234 ms (ttl=63!)  0.238 ms (ttl=63!)  0.242 ms
> (ttl=63!)
>  3  171.67.71.20  2.12 ms  1.86 ms  1.87 ms
>
>
> I'm seeing (ttl=62!) !A for each packet my router sent back, which I don't
> see in reference one. How does it know the exact number of hops back to
> the source, and what's !A?
>
>
> Thanks,
> -Seung
>
>
>

.

Path: shelby.stanford.edu!myth18.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP source
Date: Fri, 9 Feb 2007 10:55:05 -0800
Lines: 28
Distribution: su
Message-ID: <Pine.LNX.4.44.0702091052030.10919-100000@myth18.Stanford.EDU>
References: <Pine.LNX.4.44.0702091038220.10262-100000@myth18.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171047307 10920 171.64.15.61 (9 Feb 2007 18:55:07 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.44.0702091038220.10262-100000@myth18.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11609

Again, I'm answering my own question again...


FYI,

The reference router in fact behaves as expected, inspecting rtable for
source interface for ICMP. Sorry for the confusion.


Thanks,
-Seung

On Fri, 9 Feb 2007, Seung Hoon Choi wrote:

> Hi,
>
> When sending out ICMP message, what should the source interface be?
> It seems that we should calculate the source interface by consulting
> rtable, according to the previous posts, but reference router simply takes
> the destination interface of ICMP timeout as the source interface. (during
> traceroute)
>
>
> Thanks,
> -Seung
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP destination unreachable message
Date: Fri, 09 Feb 2007 10:57:42 -0800
Lines: 7
Distribution: su
Message-ID: <C1F20426.8381%jpettit@stanford.edu>
References: <eqibj2$6jj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171047464 10984 127.0.0.1 (9 Feb 2007 18:57:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ICMP destination unreachable message
Thread-Index: AcdMfC0ea5JNlbhvEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11610

On 2/9/07 9:38 AM, in article eqibj2$6jj$1@news.Stanford.EDU, "Chee-Hyung
Yoon" <chyoon@stanford.edu> wrote:

> 4500 0040
>          0x0020:  4d17 4000 3c06 71a7 ab42 93b5 c0a8 8059


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ICMP destination unreachable message
Date: Fri, 09 Feb 2007 11:02:03 -0800
Lines: 41
Distribution: su
Message-ID: <C1F2052B.8384%jpettit@stanford.edu>
References: <eqibj2$6jj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171047726 11273 127.0.0.1 (9 Feb 2007 19:02:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ICMP destination unreachable message
Thread-Index: AcdMfMiwB2um6bhwEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11611

Sorry about that last post, my finger slipped.

I don't see anything wrong with your output (although you should be setting
the IP ID field).  The reason you are getting a complaint about a bad TCP
header length is that tcpdump is trying to decode the packet carried in the
ICMP payload.  Since you are only sending the first 8 bytes of the TCP
header (from the original packet), it stands to reason that it would appear
truncated to tcpdump.

Are you sending this out of the correct interface?

--Justin


On 2/9/07 9:38 AM, in article eqibj2$6jj$1@news.Stanford.EDU, "Chee-Hyung
Yoon" <chyoon@stanford.edu> wrote:

> I think both my port unreachable and host unreachable messages are not
> being matched by the client. Tcpdump says bad hdr length, but I think I
> exactly matched the RFC for ICMP dest unreachable. I sniffed at real
> ICMP messages and they seem to be longer (at 90 bytes). Is there
> something I am missing?
> 
> here's the tcpdump of the icmp port unreachable message i send out.
> 
> 
> 08:41:33.537949 70:00:00:ab:00:01 (oui Unknown) > 00:e0:81:04:26:d9 (oui
> Unknown), ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl  64, id 0,
> offset 0, flags [none], proto: ICMP (1), length: 56)
> wsr23-router-1.stanford.edu > hr-chyoon-1158559642.stanford.edu: ICMP
> wsr23-router-1.stanford.edu tcp port http unreachable, length 36
>          (tos 0x0, ttl  60, id 19735, offset 0, flags [DF], proto: TCP
> (6), length: 64) hr-chyoon-1158559642.stanford.edu.52877 >
> wsr23-router-1.stanford.edu.http:  tcp 44 [bad hdr length 0 - too short,
> < 20]
>          0x0000:  4500 0038 0000 0000 4001 facb c0a8 8059
>          0x0010:  ab42 93b5 0303 c6d5 0000 0000 4500 0040
>          0x0020:  4d17 4000 3c06 71a7 ab42 93b5 c0a8 8059
>          0x0030:  ce8d 0050 db92 8bb6


.

Path: shelby.stanford.edu!myth18.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Wireshark?
Date: Fri, 9 Feb 2007 11:13:50 -0800
Lines: 8
Distribution: su
Message-ID: <Pine.LNX.4.44.0702091113020.11366-100000@myth18.Stanford.EDU>
NNTP-Posting-Host: myth18.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171048431 11864 171.64.15.61 (9 Feb 2007 19:13:51 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11612



So a lot of people seem to have access to packet analyzer. Is there one on
myth machines?

Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Memory cleanup
Date: Fri, 9 Feb 2007 19:19:37 +0000 (UTC)
Lines: 8
Distribution: su
Message-ID: <eqihg9$bq8$1@news.Stanford.EDU>
NNTP-Posting-Host: myth25.stanford.edu
X-Trace: news.Stanford.EDU 1171048777 12104 171.64.15.40 (9 Feb 2007 19:19:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11613



Where should I handle freeing allocations to the sr_instance ?
The ideal place I see is in the sr_destroy() function. However that is
not in the files that we are allowed to modify.

Thanks
Dina 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Wireshark?
Date: Fri, 09 Feb 2007 11:21:41 -0800
Lines: 17
Distribution: su
Message-ID: <C1F209C5.838C%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0702091113020.11366-100000@myth18.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171048904 12329 127.0.0.1 (9 Feb 2007 19:21:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Wireshark?
Thread-Index: AcdMf4bUxTq9i7hyEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11614

Search the newsgroup.


On 2/9/07 11:13 AM, in article
Pine.LNX.4.44.0702091113020.11366-100000@myth18.Stanford.EDU, "Seung Hoon
Choi" <shchoi@stanford.edu> wrote:

> 
> 
> So a lot of people seem to have access to packet analyzer. Is there one on
> myth machines?
> 
> Thanks,
> -Seung
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Memory cleanup
Date: Fri, 09 Feb 2007 11:25:52 -0800
Lines: 21
Distribution: su
Message-ID: <C1F20AC0.8390%jpettit@stanford.edu>
References: <eqihg9$bq8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171049156 12530 127.0.0.1 (9 Feb 2007 19:25:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Memory cleanup
Thread-Index: AcdMgBxwWyhkFLhzEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11615

Don't worry about cleaning up things that are only allocated once and used
throughout the life of the router.  However, you definitely need to make
sure that you're not leaking memory for other types of allocations; you
wouldn't want to put those in sr_destroy() anyways.

--Justin


On 2/9/07 11:19 AM, in article eqihg9$bq8$1@news.Stanford.EDU, "Dina Thomas"
<dinat@Stanford.EDU> wrote:

> 
> 
> Where should I handle freeing allocations to the sr_instance ?
> The ideal place I see is in the sr_destroy() function. However that is
> not in the files that we are allowed to modify.
> 
> Thanks
> Dina 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Fri, 9 Feb 2007 09:33:55 -0800
Lines: 10
Distribution: su
Message-ID: <eqihth$c86$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqedbr$a4v$1@news.Stanford.EDU> <eqedgl$a7u$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171049201 12550 127.0.0.1 (9 Feb 2007 19:26:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11616

> Well first of all you have to ask yourself why a router would be sending 
> itself data when if it really needed to it could just use a loopback...
I think we are talking about different kinds of loopback tests.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Fri, 09 Feb 2007 11:38:34 -0800
Lines: 27
Distribution: su
Message-ID: <C1F20DBA.8395%jpettit@stanford.edu>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqedbr$a4v$1@news.Stanford.EDU> <eqedgl$a7u$1@news.Stanford.EDU> <eqihth$c86$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171049917 13173 127.0.0.1 (9 Feb 2007 19:38:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Repost: traffic coming back out on the same interface
Thread-Index: AcdMgeKgIOr6vrh1EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11617

We've answered this question from a couple of different angles.  I know
we've answered it from the point of view of the packet going back out of the
same interface it came in on and the case of the source and destination IP
address being set to the router's address.  However, I'm not sure if we've
got it right yet.  

Can you take another stab at asking if it hasn't been answered
satisfactorily?  

--Justin


On 2/9/07 9:33 AM, in article eqihth$c86$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

>> Well first of all you have to ask yourself why a router would be sending
>> itself data when if it really needed to it could just use a loopback...
> I think we are talking about different kinds of loopback tests.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Repost: traffic coming back out on the same interface
Date: Fri, 9 Feb 2007 12:55:39 -0800
Lines: 51
Distribution: su
Message-ID: <eqin2r$gro$1@news.Stanford.EDU>
References: <eqe935$72l$1@news.Stanford.EDU> <eqecuk$9qd$1@news.Stanford.EDU> <eqedbr$a4v$1@news.Stanford.EDU> <eqedgl$a7u$1@news.Stanford.EDU> <eqihth$c86$1@news.Stanford.EDU> <C1F20DBA.8395%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1171054491 17272 127.0.0.1 (9 Feb 2007 20:54:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11618

Oh, no, Justin.  You answered my question just fine.  I _think_ David's 
final post was talking about a loopback of a packet starting inside the 
router (which is not what I was asking), but I could be wrong.  Your answer 
was exactly what I was looking for.

For traffic generation and prototype testing, loopback can be very useful 
(think IXIA or even the analyzers I worked on if you ever heard of Data 
Transit or Finisar).  However, we were mainly on layer 2, so layer 3 may be 
a different story.  However, I can see that you would not want it in a 
production environment.  (The layer 2 chips let you turn it on or off.)

I just find it interesting how some things that were left to the operator 
are now expected to be taken care of by the machine.  Automation is good; 
although, you loose some flexibility.

Sincerely,
Randy Jennings

The squirrels are your friends
"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1F20DBA.8395%jpettit@stanford.edu...
> We've answered this question from a couple of different angles.  I know
> we've answered it from the point of view of the packet going back out of 
> the
> same interface it came in on and the case of the source and destination IP
> address being set to the router's address.  However, I'm not sure if we've
> got it right yet.
>
> Can you take another stab at asking if it hasn't been answered
> satisfactorily?
>
> --Justin
>
>
> On 2/9/07 9:33 AM, in article eqihth$c86$1@news.Stanford.EDU, "Randy
> Jennings" <randyj@stanford.edu> wrote:
>
>>> Well first of all you have to ask yourself why a router would be sending
>>> itself data when if it really needed to it could just use a loopback...
>> I think we are talking about different kinds of loopback tests.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 9 Feb 2007 16:13:33 -0700
Lines: 36
Distribution: su
Message-ID: <eqiv6v$oq2$1@news.Stanford.EDU>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1171062816 25410 127.0.0.1 (9 Feb 2007 23:13:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11619

FYI, I just noticed the following:  Due to the admonition in RFC 792 (page 
1) that "no ICMP messages are sent about ICMP messages," you can't really 
use ping to determine whether your implementation will send the host 
unreachable error after 5 failed arp attempts.  That's because the ping 
stimulus is itself an ICMP message, so no ICMP error message should be sent 
in response to it.  To test whether your implementation sends the host 
unreachable message after 5 arp failures, you have to use a non-ICMP 
stimulus packet.

--Kevin

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1E44B89.7DDB%jpettit@stanford.edu...
>I think the short timeout in VNS is more a function of easing our testing.
> 20 minutes is common in real systems.
>
> --Justin
>
>
> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
> Pawlowski" <pawlowski@stanford.edu> wrote:
>
>> Hi--
>>
>> The class FAQ recommends an ARP cache timeout on the order of 15
>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>> simply indicative of the fact that no one can agree what the correct
>> value is, or is there rationale for using a shorter time period in VNS?
>>
>> Cheers,
>> Peter
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 9 Feb 2007 15:23:28 -0800
Lines: 49
Distribution: su
Message-ID: <eqivo0$pca$1@news.Stanford.EDU>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu> <eqiv6v$oq2$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171063360 25994 127.0.0.1 (9 Feb 2007 23:22:40 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11620

Interesting.  rfc1122 restricts it to ICMP error messages.  I think that RFC 
792 might have been updated because not getting a "host unreachable/net 
unreachable" message to a ping is undesirable, and I think, not the way it 
is done in practice.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:eqiv6v$oq2$1@news.Stanford.EDU...
> FYI, I just noticed the following:  Due to the admonition in RFC 792 (page 
> 1) that "no ICMP messages are sent about ICMP messages," you can't really 
> use ping to determine whether your implementation will send the host 
> unreachable error after 5 failed arp attempts.  That's because the ping 
> stimulus is itself an ICMP message, so no ICMP error message should be 
> sent in response to it.  To test whether your implementation sends the 
> host unreachable message after 5 arp failures, you have to use a non-ICMP 
> stimulus packet.
>
> --Kevin
>
> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
> news:C1E44B89.7DDB%jpettit@stanford.edu...
>>I think the short timeout in VNS is more a function of easing our testing.
>> 20 minutes is common in real systems.
>>
>> --Justin
>>
>>
>> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
>> Pawlowski" <pawlowski@stanford.edu> wrote:
>>
>>> Hi--
>>>
>>> The class FAQ recommends an ARP cache timeout on the order of 15
>>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>>> simply indicative of the fact that no one can agree what the correct
>>> value is, or is there rationale for using a shorter time period in VNS?
>>>
>>> Cheers,
>>> Peter
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 9 Feb 2007 16:33:16 -0700
Lines: 68
Distribution: su
Message-ID: <eqj0bv$pt0$1@news.Stanford.EDU>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu> <eqiv6v$oq2$1@news.Stanford.EDU> <eqivo0$pca$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171064000 26528 127.0.0.1 (9 Feb 2007 23:33:20 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11621

RFC 792 says "no ICMP messages are sent about ICMP messages."  RFC 792 at 
p.1.

RFC 1122 says "an ICMP error message must not be sent as the result of 
receiving an ICMP error message."  RFC 1122 at p.39.

These two statements are consistent with one another.  Neither says that an 
ICMP error message must be sent about a failed ICMP query message.  Unless 
the TAs say otherwise within the next few minutes, I'm not going to try to 
change my implementation.

--Kevin


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:eqivo0$pca$1@news.Stanford.EDU...
> Interesting.  rfc1122 restricts it to ICMP error messages.  I think that 
> RFC 792 might have been updated because not getting a "host 
> unreachable/net unreachable" message to a ping is undesirable, and I 
> think, not the way it is done in practice.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:eqiv6v$oq2$1@news.Stanford.EDU...
>> FYI, I just noticed the following:  Due to the admonition in RFC 792 
>> (page 1) that "no ICMP messages are sent about ICMP messages," you can't 
>> really use ping to determine whether your implementation will send the 
>> host unreachable error after 5 failed arp attempts.  That's because the 
>> ping stimulus is itself an ICMP message, so no ICMP error message should 
>> be sent in response to it.  To test whether your implementation sends the 
>> host unreachable message after 5 arp failures, you have to use a non-ICMP 
>> stimulus packet.
>>
>> --Kevin
>>
>> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
>> news:C1E44B89.7DDB%jpettit@stanford.edu...
>>>I think the short timeout in VNS is more a function of easing our 
>>>testing.
>>> 20 minutes is common in real systems.
>>>
>>> --Justin
>>>
>>>
>>> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
>>> Pawlowski" <pawlowski@stanford.edu> wrote:
>>>
>>>> Hi--
>>>>
>>>> The class FAQ recommends an ARP cache timeout on the order of 15
>>>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>>>> simply indicative of the fact that no one can agree what the correct
>>>> value is, or is there rationale for using a shorter time period in VNS?
>>>>
>>>> Cheers,
>>>> Peter
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 9 Feb 2007 17:35:13 -0700
Lines: 80
Distribution: su
Message-ID: <eqj404$1q$1@news.Stanford.EDU>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu> <eqiv6v$oq2$1@news.Stanford.EDU> <eqivo0$pca$1@news.Stanford.EDU> <eqj0bv$pt0$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171067716 58 127.0.0.1 (10 Feb 2007 00:35:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11622

I now have an alternative implementation that will make an exception when 
the stimulus packet is an ICMP echo request (a ping).  Would the TA's please 
chime in here and let us know which is the preferred/expected behavior, 
regardless of what the RFC's say?

--Kevin

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:eqj0bv$pt0$1@news.Stanford.EDU...
> RFC 792 says "no ICMP messages are sent about ICMP messages."  RFC 792 at 
> p.1.
>
> RFC 1122 says "an ICMP error message must not be sent as the result of 
> receiving an ICMP error message."  RFC 1122 at p.39.
>
> These two statements are consistent with one another.  Neither says that 
> an ICMP error message must be sent about a failed ICMP query message. 
> Unless the TAs say otherwise within the next few minutes, I'm not going to 
> try to change my implementation.
>
> --Kevin
>
>
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:eqivo0$pca$1@news.Stanford.EDU...
>> Interesting.  rfc1122 restricts it to ICMP error messages.  I think that 
>> RFC 792 might have been updated because not getting a "host 
>> unreachable/net unreachable" message to a ping is undesirable, and I 
>> think, not the way it is done in practice.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
>> news:eqiv6v$oq2$1@news.Stanford.EDU...
>>> FYI, I just noticed the following:  Due to the admonition in RFC 792 
>>> (page 1) that "no ICMP messages are sent about ICMP messages," you can't 
>>> really use ping to determine whether your implementation will send the 
>>> host unreachable error after 5 failed arp attempts.  That's because the 
>>> ping stimulus is itself an ICMP message, so no ICMP error message should 
>>> be sent in response to it.  To test whether your implementation sends 
>>> the host unreachable message after 5 arp failures, you have to use a 
>>> non-ICMP stimulus packet.
>>>
>>> --Kevin
>>>
>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
>>> news:C1E44B89.7DDB%jpettit@stanford.edu...
>>>>I think the short timeout in VNS is more a function of easing our 
>>>>testing.
>>>> 20 minutes is common in real systems.
>>>>
>>>> --Justin
>>>>
>>>>
>>>> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
>>>> Pawlowski" <pawlowski@stanford.edu> wrote:
>>>>
>>>>> Hi--
>>>>>
>>>>> The class FAQ recommends an ARP cache timeout on the order of 15
>>>>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>>>>> simply indicative of the fact that no one can agree what the correct
>>>>> value is, or is there rationale for using a shorter time period in 
>>>>> VNS?
>>>>>
>>>>> Cheers,
>>>>> Peter
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 09 Feb 2007 17:02:33 -0800
Lines: 91
Distribution: su
Message-ID: <C1F259A9.83B9%jpettit@stanford.edu>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu> <eqiv6v$oq2$1@news.Stanford.EDU> <eqivo0$pca$1@news.Stanford.EDU> <eqj0bv$pt0$1@news.Stanford.EDU> <eqj404$1q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171069355 1479 127.0.0.1 (10 Feb 2007 01:02:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ARP timeouts
Thread-Index: AcdMryUsY/f5SriiEduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11623

You don't need to send host unreachable messages for pings.  However, we
won't dock you if you do, either.

--Justin


On 2/9/07 4:35 PM, in article eqj404$1q$1@news.Stanford.EDU, "Kevin Hart"
<kevin.hart@hp.com> wrote:

> I now have an alternative implementation that will make an exception when
> the stimulus packet is an ICMP echo request (a ping).  Would the TA's please
> chime in here and let us know which is the preferred/expected behavior,
> regardless of what the RFC's say?
> 
> --Kevin
> 
> "Kevin Hart" <kevin.hart@hp.com> wrote in message
> news:eqj0bv$pt0$1@news.Stanford.EDU...
>> RFC 792 says "no ICMP messages are sent about ICMP messages."  RFC 792 at
>> p.1.
>> 
>> RFC 1122 says "an ICMP error message must not be sent as the result of
>> receiving an ICMP error message."  RFC 1122 at p.39.
>> 
>> These two statements are consistent with one another.  Neither says that
>> an ICMP error message must be sent about a failed ICMP query message.
>> Unless the TAs say otherwise within the next few minutes, I'm not going to
>> try to change my implementation.
>> 
>> --Kevin
>> 
>> 
>> "Randy Jennings" <randyj@stanford.edu> wrote in message
>> news:eqivo0$pca$1@news.Stanford.EDU...
>>> Interesting.  rfc1122 restricts it to ICMP error messages.  I think that
>>> RFC 792 might have been updated because not getting a "host
>>> unreachable/net unreachable" message to a ping is undesirable, and I
>>> think, not the way it is done in practice.
>>> 
>>> Sincerely,
>>> Randy Jennings
>>> 
>>> The squirrels are your friends!
>>> "Kevin Hart" <kevin.hart@hp.com> wrote in message
>>> news:eqiv6v$oq2$1@news.Stanford.EDU...
>>>> FYI, I just noticed the following:  Due to the admonition in RFC 792
>>>> (page 1) that "no ICMP messages are sent about ICMP messages," you can't
>>>> really use ping to determine whether your implementation will send the
>>>> host unreachable error after 5 failed arp attempts.  That's because the
>>>> ping stimulus is itself an ICMP message, so no ICMP error message should
>>>> be sent in response to it.  To test whether your implementation sends
>>>> the host unreachable message after 5 arp failures, you have to use a
>>>> non-ICMP stimulus packet.
>>>> 
>>>> --Kevin
>>>> 
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message
>>>> news:C1E44B89.7DDB%jpettit@stanford.edu...
>>>>> I think the short timeout in VNS is more a function of easing our
>>>>> testing.
>>>>> 20 minutes is common in real systems.
>>>>> 
>>>>> --Justin
>>>>> 
>>>>> 
>>>>> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
>>>>> Pawlowski" <pawlowski@stanford.edu> wrote:
>>>>> 
>>>>>> Hi--
>>>>>> 
>>>>>> The class FAQ recommends an ARP cache timeout on the order of 15
>>>>>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>>>>>> simply indicative of the fact that no one can agree what the correct
>>>>>> value is, or is there rationale for using a shorter time period in
>>>>>> VNS?
>>>>>> 
>>>>>> Cheers,
>>>>>> Peter
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ARP timeouts
Date: Fri, 9 Feb 2007 17:03:16 -0800
Lines: 88
Distribution: su
Message-ID: <eqj5km$1i1$1@news.Stanford.EDU>
References: <epn181$ub$1@news.Stanford.EDU> <C1E44B89.7DDB%jpettit@stanford.edu> <eqiv6v$oq2$1@news.Stanford.EDU> <eqivo0$pca$1@news.Stanford.EDU> <eqj0bv$pt0$1@news.Stanford.EDU> <eqj404$1q$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171069398 1601 127.0.0.1 (10 Feb 2007 01:03:18 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11624

I'd posted a similar question before. Look for the thread titled "ICMP 
Packet forwarding errors".


"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:eqj404$1q$1@news.Stanford.EDU...
>I now have an alternative implementation that will make an exception when 
>the stimulus packet is an ICMP echo request (a ping).  Would the TA's 
>please chime in here and let us know which is the preferred/expected 
>behavior, regardless of what the RFC's say?
>
> --Kevin
>
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:eqj0bv$pt0$1@news.Stanford.EDU...
>> RFC 792 says "no ICMP messages are sent about ICMP messages."  RFC 792 at 
>> p.1.
>>
>> RFC 1122 says "an ICMP error message must not be sent as the result of 
>> receiving an ICMP error message."  RFC 1122 at p.39.
>>
>> These two statements are consistent with one another.  Neither says that 
>> an ICMP error message must be sent about a failed ICMP query message. 
>> Unless the TAs say otherwise within the next few minutes, I'm not going 
>> to try to change my implementation.
>>
>> --Kevin
>>
>>
>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
>> news:eqivo0$pca$1@news.Stanford.EDU...
>>> Interesting.  rfc1122 restricts it to ICMP error messages.  I think that 
>>> RFC 792 might have been updated because not getting a "host 
>>> unreachable/net unreachable" message to a ping is undesirable, and I 
>>> think, not the way it is done in practice.
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> The squirrels are your friends!
>>> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
>>> news:eqiv6v$oq2$1@news.Stanford.EDU...
>>>> FYI, I just noticed the following:  Due to the admonition in RFC 792 
>>>> (page 1) that "no ICMP messages are sent about ICMP messages," you 
>>>> can't really use ping to determine whether your implementation will 
>>>> send the host unreachable error after 5 failed arp attempts.  That's 
>>>> because the ping stimulus is itself an ICMP message, so no ICMP error 
>>>> message should be sent in response to it.  To test whether your 
>>>> implementation sends the host unreachable message after 5 arp failures, 
>>>> you have to use a non-ICMP stimulus packet.
>>>>
>>>> --Kevin
>>>>
>>>> "Justin Pettit" <jpettit@stanford.edu> wrote in message 
>>>> news:C1E44B89.7DDB%jpettit@stanford.edu...
>>>>>I think the short timeout in VNS is more a function of easing our 
>>>>>testing.
>>>>> 20 minutes is common in real systems.
>>>>>
>>>>> --Justin
>>>>>
>>>>>
>>>>> On 1/30/07 12:56 AM, in article epn181$ub$1@news.Stanford.EDU, "Peter
>>>>> Pawlowski" <pawlowski@stanford.edu> wrote:
>>>>>
>>>>>> Hi--
>>>>>>
>>>>>> The class FAQ recommends an ARP cache timeout on the order of 15
>>>>>> seconds. Stevens recommends ones on the other of 20 minutes. Is this
>>>>>> simply indicative of the fact that no one can agree what the correct
>>>>>> value is, or is there rationale for using a shorter time period in 
>>>>>> VNS?
>>>>>>
>>>>>> Cheers,
>>>>>> Peter
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: TCP checksum error
Date: Sat, 10 Feb 2007 01:14:41 +0000 (UTC)
Lines: 11
Distribution: su
Message-ID: <eqj6a1$1pd$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1171070081 1837 171.64.15.6 (10 Feb 2007 01:14:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11625



I am trying to connect on port 80 of the application server.
All the HTTP packets arriving at my router from the client-side
has TCP-checksum error. 
This is what ethereal says:

[Unreassembled packet [incorrect TCP checksum]: HTTP]

How could this be a problem with my router as these are incoming
packets?
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: TCP checksum error
Date: Fri, 09 Feb 2007 19:15:31 -0800
Lines: 23
Distribution: su
Message-ID: <C1F278D3.83C2%jpettit@stanford.edu>
References: <eqj6a1$1pd$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171077335 7650 127.0.0.1 (10 Feb 2007 03:15:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: TCP checksum error
Thread-Index: AcdMwbhu9xkYMri0EduZHwARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11626

Could you be specifying the wrong length somehow?  You're not changing the
IP addresses are you?  Does it work properly with Clack?  Can you send a
packet that exhibits the behavior dumped with "tcpdump -x -vvv"?

--Justin


On 2/9/07 5:14 PM, in article eqj6a1$1pd$1@news.Stanford.EDU, "Dina Thomas"
<dinat@Stanford.EDU> wrote:

> 
> 
> I am trying to connect on port 80 of the application server.
> All the HTTP packets arriving at my router from the client-side
> has TCP-checksum error.
> This is what ethereal says:
> 
> [Unreassembled packet [incorrect TCP checksum]: HTTP]
> 
> How could this be a problem with my router as these are incoming
> packets?


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Hw2 problem 7(b)(ii)
Date: Sat, 10 Feb 2007 09:49:52 -0800
Lines: 13
Distribution: su
Message-ID: <eql2ct$phf$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171131614 26159 127.0.0.1 (10 Feb 2007 18:20:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11627

Part 7(b)(i) seems to be speaking of an arbitrary topology with any number 
of hops.  However, it seems to me that for part 7(b)(ii), R2 would need to 
be the final router before the final destination.  Or is the question just 
asking for the destination after R2?

Or is there an arbitrary topology after R2, and the question is asking for 
back-to-back delivery at the end destination?  I would have to think about 
that because I do not see how back-to-back delivery is possible.

Sincerely,
Randy Jennings 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: how to find i/fs of a router
Date: Sat, 10 Feb 2007 19:23:53 +0000 (UTC)
Lines: 6
Distribution: su
Message-ID: <eql649$slp$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine26.stanford.edu
X-Trace: news.Stanford.EDU 1171135433 29369 171.64.15.101 (10 Feb 2007 19:23:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:11628

Hi,

How can we find the i/fs of a router. I could use ifconfig to find them for the host but not for any router. (Are we supposed to use commands other than ifconfig, tracroute and host?)

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Unknown host medcbbr2.stanford.edu
Date: Sat, 10 Feb 2007 16:24:22 -0800
Lines: 12
Distribution: su
Message-ID: <eqlnm6$dc0$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171153414 13696 127.0.0.1 (11 Feb 2007 00:23:34 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11629

myth22:~> ping medcbbr2.stanford.edu
Unknown host medcbbr2.stanford.edu

Anyone figure out a way around this?  It's terrible when other organizations 
update their resources without asking our permission :-)!

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Hw2 problem 7(b)(ii)
Date: Sun, 11 Feb 2007 15:58:10 -0800
Lines: 7
Distribution: su
Message-ID: <eqoail$nm7$1@news.Stanford.EDU>
References: <eql2ct$phf$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171238293 24263 128.12.133.106 (11 Feb 2007 23:58:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eql2ct$phf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11630

7 only has a - i. I'm going to act like you asked about question 8

> Part 7(b)(i) seems to be speaking of an arbitrary topology with any number 
> of hops.  However, it seems to me that for part 7(b)(ii), R2 would need to 
> be the final router before the final destination.  Or is the question just 
> asking for the destination after R2?
R2 is the second router in a network of unspecified length.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: how to find i/fs of a router
Date: Sun, 11 Feb 2007 16:01:48 -0800
Lines: 4
Distribution: su
Message-ID: <eqoapf$o3t$1@news.Stanford.EDU>
References: <eql649$slp$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171238511 24701 128.12.133.106 (12 Feb 2007 00:01:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eql649$slp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11631

> How can we find the i/fs of a router. I could use ifconfig to find them for the host but not for any router. (Are we supposed to use commands other than ifconfig, tracroute and host?)
> 
Think about what traceroute does, and how you can use it to learn about 
a topology.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Unknown host medcbbr2.stanford.edu
Date: Sun, 11 Feb 2007 16:05:55 -0800
Lines: 19
Distribution: su
Message-ID: <eqob16$o6v$1@news.Stanford.EDU>
References: <eqlnm6$dc0$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171238758 24799 128.12.133.106 (12 Feb 2007 00:05:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqlnm6$dc0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11632

They don't have a forward lookup for that but they do have a reverse 
lookup (if you get the IP, you'll get the right hostname back). Try to 
be creative and find their router! (It took me 1 minute to find it, so 
that should be a hint that bruteforcing all of stanford's IP space isn't 
a good strategy).

Randy Jennings wrote:
> myth22:~> ping medcbbr2.stanford.edu
> Unknown host medcbbr2.stanford.edu
> 
> Anyone figure out a way around this?  It's terrible when other organizations 
> update their resources without asking our permission :-)!
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: myth subnet masks
Date: Sun, 11 Feb 2007 17:40:03 -0800
Lines: 17
Distribution: su
Message-ID: <eqoghq$s56$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek-laptop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171244410 28838 128.12.104.76 (12 Feb 2007 01:40:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11633

Hello--

I'm a bit confused about how subnet masks work on the myths. My 
impression was that when configuring an interface, one provides (or 
gets via DHCP) an IP, subnet mask, and default gateway. Packets 
destined for IPs on the same subnet get dumped onto the LAN, while 
packets destined for different networks are forwarded to the gateway. 
However, it appears that the myths are configured with an subnet mask 
of 255.255.0.0. Sending a packets to (for example) 171.64.1.1 from any 
of the myths, however, goes through the gates-rtr despite being on the 
same subnet as the myths. Am I msising something here? Is there some 
extra configuriation information not displayed in the kernel routing 
table? Or is my understanding of subnetting buggy?

Thanks,
Peter

.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: netblock ownership
Date: Sun, 11 Feb 2007 17:48:56 -0800
Lines: 12
Distribution: su
Message-ID: <eqoh2f$sbm$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek-laptop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171244943 29046 128.12.104.76 (12 Feb 2007 01:49:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11634

Hello--

It appears that the IP to which www.whitehouse.gov resolves 
(198.189.255.81) belongs to a netblock owned by the calstate system 
(and not to A----). Does this mean that the netblock's original owner 
subleased some part of their netblock space (is this even allowed? if 
it is, wouldn't that create incentive to hog address space?)? What else 
could be going on here?

Cheers,
Peter

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: myth subnet masks
Date: Sun, 11 Feb 2007 18:20:49 -0800
Lines: 47
Distribution: su
Message-ID: <C1F50F01.8410%jpettit@stanford.edu>
References: <eqoghq$s56$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171246852 532 127.0.0.1 (12 Feb 2007 02:20:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: myth subnet masks
Thread-Index: AcdOTGkIp3pIvro/EduG0AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11635

Your understanding is correct, but the Gates network is configured in a
strange and confusing way.  The Gates router does something called Proxy
ARP, which means that it responds to ARP requests for hosts on other
physical networks that it can reach.

To illustrate, I did some pinging from Myth14.  Here are some entries from
the ARP cache:

 myth18.Stanford.EDU (171.64.15.61) at 00:0F:1F:84:73:32 [ether] on eth0
 Gates-rtr.Stanford.EDU (171.64.15.65) at 00:D0:05:5D:27:FC [ether] on eth0
 syllabus.Stanford.EDU (171.64.15.220) at 00:D0:05:5D:27:FC [ether] on eth0

As you can see, the Myth18 entry has a different hardware address from the
other entries; this is its actual address.  The other two entries are the
hardware address of an interface on the Gates router.  So you can see that
it generates ARP replies for some IP addresses in this subnet and not
others.

I think the reason that they do this is to allow for some flexibility in
their network design without requiring changes to the end hosts.  However,
it also causes problems for the occasional research project...grr.

--Justin


On 2/11/07 5:40 PM, in article eqoghq$s56$1@news.Stanford.EDU, "Peter
Pawlowski" <pawlowski@stanford.edu> wrote:

> Hello--
> 
> I'm a bit confused about how subnet masks work on the myths. My
> impression was that when configuring an interface, one provides (or
> gets via DHCP) an IP, subnet mask, and default gateway. Packets
> destined for IPs on the same subnet get dumped onto the LAN, while
> packets destined for different networks are forwarded to the gateway.
> However, it appears that the myths are configured with an subnet mask
> of 255.255.0.0. Sending a packets to (for example) 171.64.1.1 from any
> of the myths, however, goes through the gates-rtr despite being on the
> same subnet as the myths. Am I msising something here? Is there some
> extra configuriation information not displayed in the kernel routing
> table? Or is my understanding of subnetting buggy?
> 
> Thanks,
> Peter
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: myth subnet masks
Date: Mon, 12 Feb 2007 00:28:17 -0700
Lines: 89
Distribution: su
Message-ID: <eqp4uk$cja$1@news.Stanford.EDU>
References: <eqoghq$s56$1@news.Stanford.EDU> <C1F50F01.8410%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1171265300 12906 127.0.0.1 (12 Feb 2007 07:28:20 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11636

I also spent (wasted?) several hours this weekend puzzling about the myth 
routing tables.  There are only two entries; both are odd.  Your posts clear 
up the first line I think, but the second one is still mysterious.

dest                gateway            mask
174.64.0.0        0.0.0.0            255.255.0.0
0.0.0.0              171.64.1.1      0.0.0.0

1)  As your posts pointed out, the first entry suggests the entire Stanford 
network is a big tangle of ethernet hubs and switches with no routers, 
connecting 65,536 hosts in a single lan.  To follow up on what Justin said, 
there is an RFC 1027 that sheds some light on this.  Apparently they call 
this the "arp hack."  Subnets and routers really exist, but the end hosts 
don't have to know about them.  The end hosts just pretend it's one big lan. 
When a gateway router for a subnet sees an arp request for an ip addr not on 
the lan (but reachable through the router), the router jumps in and spoofs 
an arp reply (I think) on behalf of the distant host.  But the router gives 
its own mac addr, not that of the distant host.  The router will then get 
the real packets destined for the distant host, and its normal ip forwarding 
function gets them to the right place.

2)  As for the second line, could we get some more TA guidance?  We all know 
from traceroute that our outbound traffic exits through the Gates router, 
but the Gates router interface it exits through is *not* 171.64.1.1.  This 
piece of magic appears to be "anycast,"  but nobody has told us how anycast 
works (!).  Maybe the Gates router does an arp trick here too?  (Maybe it 
jumps in and spoofs an arp reply for 171.64.1.1?)  The Gates router has many 
interfaces, but 171.64.1.1 is not one of them.  When you do a host command, 
you find an entry with the name "zyx-anycast.stanford.edu" having this 
address and a handful of others.  But I suspect that entry doesn't 
correspond to a real machine.  Could the TAs jump in and give details on how 
this piece works?

Thanks,
Kevin



"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1F50F01.8410%jpettit@stanford.edu...
> Your understanding is correct, but the Gates network is configured in a
> strange and confusing way.  The Gates router does something called Proxy
> ARP, which means that it responds to ARP requests for hosts on other
> physical networks that it can reach.
>
> To illustrate, I did some pinging from Myth14.  Here are some entries from
> the ARP cache:
>
> myth18.Stanford.EDU (171.64.15.61) at 00:0F:1F:84:73:32 [ether] on eth0
> Gates-rtr.Stanford.EDU (171.64.15.65) at 00:D0:05:5D:27:FC [ether] on eth0
> syllabus.Stanford.EDU (171.64.15.220) at 00:D0:05:5D:27:FC [ether] on eth0
>
> As you can see, the Myth18 entry has a different hardware address from the
> other entries; this is its actual address.  The other two entries are the
> hardware address of an interface on the Gates router.  So you can see that
> it generates ARP replies for some IP addresses in this subnet and not
> others.
>
> I think the reason that they do this is to allow for some flexibility in
> their network design without requiring changes to the end hosts.  However,
> it also causes problems for the occasional research project...grr.
>
> --Justin
>
>
> On 2/11/07 5:40 PM, in article eqoghq$s56$1@news.Stanford.EDU, "Peter
> Pawlowski" <pawlowski@stanford.edu> wrote:
>
>> Hello--
>>
>> I'm a bit confused about how subnet masks work on the myths. My
>> impression was that when configuring an interface, one provides (or
>> gets via DHCP) an IP, subnet mask, and default gateway. Packets
>> destined for IPs on the same subnet get dumped onto the LAN, while
>> packets destined for different networks are forwarded to the gateway.
>> However, it appears that the myths are configured with an subnet mask
>> of 255.255.0.0. Sending a packets to (for example) 171.64.1.1 from any
>> of the myths, however, goes through the gates-rtr despite being on the
>> same subnet as the myths. Am I msising something here? Is there some
>> extra configuriation information not displayed in the kernel routing
>> table? Or is my understanding of subnetting buggy?
>>
>> Thanks,
>> Peter
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Don't ISP's really throttle Internet traffic?
Date: Mon, 12 Feb 2007 00:46:07 -0700
Lines: 20
Distribution: su
Message-ID: <eqp604$dn8$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171266372 14056 127.0.0.1 (12 Feb 2007 07:46:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11637

I think Nick suggested in class that TCP is the reason why the Internet 
doesn't appear to be too congested, that TCP causes sending hosts to be 
well-behaved.  But he also said 70% of Internet traffic is attributable to 
bittorrent, which means it's coming from individual users at the edges of 
the network.  If that's true, then it seems like the reason for low 
congestion is not nearly so exotic as TCP congestion control.  It's the big 
blunt instrument of ISP upload bandwidth caps.  Am I wrong about this?

When I checked my cable modem configuration, the upload speed is limited to 
384kbps (as opposed to 6Mbps in the download direction).  And this is not a 
user-tweakable setting.  It appears to be set by the ISP as part of the 
DHCP-like connection protocol that happens when the cable modem comes alive. 
If the cable modem doesn't obey, it will not be allowed to have access to 
the ISP's network.  If 70% of all internet traffic is coming from end users 
who have these kinds of limitations, doesn't that render the TCP congestion 
control scheme kind of irrelevant?

--Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Questions on IP masks
Date: Mon, 12 Feb 2007 05:04:14 -0800
Lines: 4
Distribution: su
Message-ID: <eqpokh$315$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171285457 3109 128.12.194.72 (12 Feb 2007 13:04:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11638

If the prefix is, say, 17 bits long, is the IP mask 255.255.128.0 or 
255.255.1.0? It's the former, right?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Unknown host medcbbr2.stanford.edu
Date: Mon, 12 Feb 2007 10:55:37 -0800
Lines: 31
Distribution: su
Message-ID: <eqqd5o$kvm$1@news.Stanford.EDU>
References: <eqlnm6$dc0$1@news.Stanford.EDU> <eqob16$o6v$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171306488 21494 127.0.0.1 (12 Feb 2007 18:54:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11639

That was not very helpful.  The problem was the host name is 
med-cbbr2.stanford.edu.  I did not notice the hyphen because it caused a 
line break on the text.

Sincerely,
Randy Jennings

The squirrels are your friends!


"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:eqob16$o6v$1@news.Stanford.EDU...
> They don't have a forward lookup for that but they do have a reverse 
> lookup (if you get the IP, you'll get the right hostname back). Try to be 
> creative and find their router! (It took me 1 minute to find it, so that 
> should be a hint that bruteforcing all of stanford's IP space isn't a good 
> strategy).
>
> Randy Jennings wrote:
>> myth22:~> ping medcbbr2.stanford.edu
>> Unknown host medcbbr2.stanford.edu
>>
>> Anyone figure out a way around this?  It's terrible when other 
>> organizations update their resources without asking our permission :-)!
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Questions on IP masks
Date: Mon, 12 Feb 2007 12:04:00 -0700
Lines: 13
Distribution: su
Message-ID: <eqqdn3$lk3$1@news.Stanford.EDU>
References: <eqpokh$315$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171307044 22147 127.0.0.1 (12 Feb 2007 19:04:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11640

Right.  The mask bits need to be contiguous starting from the msb because 
their purpose is to isolate the prefix portion of an ip address.

--Kevin

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:eqpokh$315$1@news.Stanford.EDU...
> If the prefix is, say, 17 bits long, is the IP mask 255.255.128.0 or 
> 255.255.1.0? It's the former, right?
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: myth subnet masks
Date: Mon, 12 Feb 2007 13:03:31 -0800
Lines: 41
Distribution: su
Message-ID: <C1F61623.8460%jpettit@stanford.edu>
References: <eqoghq$s56$1@news.Stanford.EDU> <C1F50F01.8410%jpettit@stanford.edu> <eqp4uk$cja$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171314215 28776 127.0.0.1 (12 Feb 2007 21:03:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: myth subnet masks
Thread-Index: AcdO6T/qfkfLU7rcEduG0AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11641

> dest                gateway            mask
> 174.64.0.0        0.0.0.0            255.255.0.0
> 0.0.0.0              171.64.1.1      0.0.0.0
> 
> 2)  As for the second line, could we get some more TA guidance?  We all know
> from traceroute that our outbound traffic exits through the Gates router,
> but the Gates router interface it exits through is *not* 171.64.1.1.  This
> piece of magic appears to be "anycast,"  but nobody has told us how anycast
> works (!).  Maybe the Gates router does an arp trick here too?  (Maybe it
> jumps in and spoofs an arp reply for 171.64.1.1?)  The Gates router has many
> interfaces, but 171.64.1.1 is not one of them.  When you do a host command,
> you find an entry with the name "zyx-anycast.stanford.edu" having this
> address and a handful of others.  But I suspect that entry doesn't
> correspond to a real machine.  Could the TAs jump in and give details on how
> this piece works?

I doubt that anycast is involved in routing packets out of the Gates
network.  Here is the traceroute out to Google:

----------------------
[jpettit@myth6 ~] traceroute www.google.com
traceroute to www.l.google.com (66.102.7.147): 1-30 hops, 38 byte packets
 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.359 ms  0.212 ms  0.238 ms
 2  bbra-rtr.Stanford.EDU (171.64.1.52)  0.731 ms  0.724 ms  0.616 ms
 3  dc1-rtr.Stanford.EDU (171.64.1.132)  0.860 ms  0.854 ms  0.742 ms
 4  dc-svl-dc1--stan-ge.cenic.net (137.164.23.37)  1.36 ms  1.45 ms  1.49 ms
 ....
----------------------

My guess is that the Gates router proxy ARPs for 171.64.1.1 and then passes
the traffic to whatever the next hop is.  An interesting thing is that when
I ping gates-rtr, I get sub-millisecond response times.  However, when I
ping 171.64.1.1, I get response times slightly greater than a millisecond,
so while 171.64.1.1 is a real machine, it doesn't appear to be gates-rtr.

I have a meeting with one of the Gates admins tomorrow, so I'll ask him
about this.  If it is any different than what I've posted here, I'll add
another follow-up.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: "Karns" algorithm
Date: Mon, 12 Feb 2007 14:14:30 -0800
Lines: 13
Distribution: su
Message-ID: <eqqosq$1uo$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171318490 2008 127.0.0.1 (12 Feb 2007 22:14:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:11642

I have a quick question about the exponential back-off of TCP timeout values.

Suppose my TCP connection is chugging along, it has it's estimated RTT 
and variance which it uses to calculate a timeout value, and all of a 
sudden, the sender experiences a timeout. It retransmits the packet 
with an RTO of double the previous value. Does it start doubling RTO 
for every subsequent packet as well? I'm a bit confused by how the 
"doubled RTO" interoperates with the "formula version" which calculates 
the RTO from estimated values.


Adam Cohen

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: "Karns" algorithm
Date: Mon, 12 Feb 2007 15:36:07 -0800
Lines: 54
Distribution: su
Message-ID: <eqqtl1$70g$1@news.Stanford.EDU>
References: <eqqosq$1uo$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171323361 7184 127.0.0.1 (12 Feb 2007 23:36:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqqosq$1uo$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11643

Adam Cohen wrote:
> I have a quick question about the exponential back-off of TCP timeout 
> values.
> 
> Suppose my TCP connection is chugging along, it has it's estimated RTT 
> and variance which it uses to calculate a timeout value, and all of a 
> sudden, the sender experiences a timeout. It retransmits the packet with 
> an RTO of double the previous value. Does it start doubling RTO for 
> every subsequent packet as well? I'm a bit confused by how the "doubled 
> RTO" interoperates with the "formula version" which calculates the RTO 
> from estimated values.
> 
> 
> Adam Cohen
> 

"Refinements to RTT Calculation and Karn's Algorithm

TCP's solution to round-trip time calculation is based on the use of a 
technique called Karn's algorithm, after its inventor, Phil Karn. The 
main change this algorithm makes is the separation of the calculation of 
average round-trip time from the calculation of the value to use for 
timers on retransmitted segments.

The first change made under Karn's algorithm is to not use measured 
round-trip times for any segments that are retransmitted in the 
calculation of the overall average round-trip time for the connection. 
This completely eliminates the problem of acknowledgment ambiguity.

However, this by itself would not allow increased delays due to 
retransmissions to affect the average round-trip time. For this, we need 
the second change: incorporation of a timer backoff scheme for 
retransmitted segments. We start by setting the retransmission timer for 
each newly-transmitted segment based on the current average round-trip 
time. When a segment is retransmitted, the timer is not reset to the 
same value it was set for the initial transmission. It is “backed off” 
(increased) using a multiplier (typically 2) to give the retransmission 
more time to be received. The timer continues to be increased until a 
retransmission is successful, up to a certain maximum value. This 
prevents retransmissions from being sent too quickly and further adding 
to network congestion.

Once the retransmission succeeds, the round-trip timer is kept at the 
longer (backed-off) value until a valid round-trip time can be measured 
on a segment that is sent and acknowledged without retransmission. This 
permits a device to respond with longer timers to occasional 
circumstances that cause delays to persist for a period of time on a 
connection, while eventually having the round-trip time settle back to a 
long-term average when normal conditions resume."

 From 
http://www.tcpipguide.com/free/t_TCPAdaptiveRetransmissionandRetransmissionTimerCal-3.htm

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: HW#1 problem 1d, 6b
Date: Mon, 12 Feb 2007 17:25:14 -0800
Lines: 36
Distribution: su
Message-ID: <eqr40h$d0m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171329873 13334 127.0.0.1 (13 Feb 2007 01:24:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11644


//-------------------------------------
Problem 1d: I was expecting the answer key to have a bit more explanation. 
Would
someone care to elaborate why the probability would be higher?  I do not see
it.

If the person takes the class again, the class will not start on the same
day because cs244a is (with high probability) on Tuesday/Thursday.  The next
year, that day of the week shifts one day.  Therefore, that person has two
days he must not have a birthday, making the probability 
((364/365)^(5*50-2))*(363/365), which is 50.3647%, or lower than 
((364/365)^(5*50)), which is 50.3651%.

If we were talking about Christmas, which always lands on the same day of 
the year, the answer would be ((364/365)^(5N-1)), or 50.5035%, which is, of 
course, higher.  However, that was not the question in the assignment.
//--------------------------------------------------
Problem 6b:  Why did the problem assume that queue length was still 128KB?

It was asked on the newsgroup if we should assume this, but the response was 
off topic, and the restate was ignored.

That does not seem like a reasonable assumption as the problem is stated. 
Sure, it makes the problem easier, and independent of the arrival process, 
but that does not mean it is realistic.  If you drop the incoming rate, you 
should drop the queue length!
//--------------------------------------------------

Sincerely,
Randy Jennings

The squirrels are your friends!



.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: netblock ownership
Date: Mon, 12 Feb 2007 17:31:31 -0800
Lines: 50
Distribution: su
Message-ID: <eqr4dd$dbm$1@news.Stanford.EDU>
References: <eqoh2f$sbm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171330286 13686 127.0.0.1 (13 Feb 2007 01:31:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqoh2f$sbm$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11645

Peter Pawlowski wrote:
> Hello--
> 
> It appears that the IP to which www.whitehouse.gov resolves 
> (198.189.255.81) belongs to a netblock owned by the calstate system (and 
> not to A----). Does this mean that the netblock's original owner 
> subleased some part of their netblock space (is this even allowed? if it 
> is, wouldn't that create incentive to hog address space?)? What else 
> could be going on here?
> 
> Cheers,
> Peter
> 

That domain seems to be hosted from multiple locations, a lookup from 
home on my comcast account gives me:

C:\Documents and Settings\Administrator>ping www.whitehouse.gov

Pinging a1289.g.akamai.net [63.82.132.11] with 32 bytes of data:

Which is registered to MCI.  So yes, if you have a block of IP addreses 
you can assign them to whatever you want.

Also take a look at the trace to www.whitehouse.gov from Stanford:
[derickso@doemail lab2]$ traceroute 198.189.255.81
traceroute to 198.189.255.81 (198.189.255.81), 30 hops max, 38 byte packets
  1  Gates-rtr (171.64.74.1)  1.236 ms  1.504 ms  1.259 ms
  2  bbra-rtr (171.64.1.52)  2.522 ms  1.652 ms  2.300 ms
  3  hpr1-rtr (171.64.1.131)  4.545 ms  2.026 ms  8.533 ms
  4  hpr-svl-hpr--stan-ge.cenic.net (137.164.27.161)  5.559 ms  13.652 
ms  6.694 ms
  5  oak-hpr--svl-hpr-10ge.cenic.net (137.164.25.9)  3.301 ms  2.959 ms 
  3.102 ms
  6  sac-hpr--oak-hpr-10ge.cenic.net (137.164.25.17)  5.020 ms  4.711 ms 
  4.918 ms
  7  dc-sac-dc1--hpr-p2p.cenic.net (137.164.40.108)  5.336 ms  4.908 ms 
  5.197 ms
  8  198.189.255.81 (198.189.255.81)  5.241 ms  5.151 ms  5.014 ms

It goes out over Internet 2 which is interesting.  And Justin found out 
that if you telnet in to the webserver it is Akamai as well, so Akamai 
is hosting the website all over the place, and using IP's assigned to 
them from larger authorities, IE MCI or Cal.  I don't necessarily think 
that creates incentive to hog IP address space, as ultimately it is all 
assigned by ARIN and the companies I assume have to justify their use of 
the blocks, I know that anytime in a hosting center or at home that I 
request further IPs I have to tell them what I am going to use them for.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Don't ISP's really throttle Internet traffic?
Date: Mon, 12 Feb 2007 17:54:24 -0800
Lines: 35
Distribution: su
Message-ID: <eqr5oa$efb$1@news.Stanford.EDU>
References: <eqp604$dn8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171331658 14827 127.0.0.1 (13 Feb 2007 01:54:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqp604$dn8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11646

Kevin Hart wrote:
> I think Nick suggested in class that TCP is the reason why the Internet 
> doesn't appear to be too congested, that TCP causes sending hosts to be 
> well-behaved.  But he also said 70% of Internet traffic is attributable to 
> bittorrent, which means it's coming from individual users at the edges of 
> the network.  If that's true, then it seems like the reason for low 
> congestion is not nearly so exotic as TCP congestion control.  It's the big 
> blunt instrument of ISP upload bandwidth caps.  Am I wrong about this?
> 
> When I checked my cable modem configuration, the upload speed is limited to 
> 384kbps (as opposed to 6Mbps in the download direction).  And this is not a 
> user-tweakable setting.  It appears to be set by the ISP as part of the 
> DHCP-like connection protocol that happens when the cable modem comes alive. 
> If the cable modem doesn't obey, it will not be allowed to have access to 
> the ISP's network.  If 70% of all internet traffic is coming from end users 
> who have these kinds of limitations, doesn't that render the TCP congestion 
> control scheme kind of irrelevant?
> 
> --Kevin

Honestly I don't think that the lower (in general) speed of most end 
user's upstream is enforcing any kind of bound on traffic.  If you think 
about it, nearly all ISPs way oversell their bandwidth, IE they bank 
only a fraction of their actual users to be using their bandwidth at a 
time.  Now if you aggregate a large majority of the people connected to 
the internet using their full upstream pipes, they ought to easily be 
able to saturate not only the local links on the way to the backbones, 
but quite possibly the backbones as well, and at that point the only 
thing saving people would potentially be TCP's congestion control.  This 
is all speculation on my part, and could be wrong.  But I am definitely 
an advocate for higher end user upstream bandwidth =)

-David


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW#1 problem 1d, 6b
Date: Mon, 12 Feb 2007 18:21:56 -0800
Lines: 44
Distribution: su
Message-ID: <eqr7bv$fr3$1@news.Stanford.EDU>
References: <eqr40h$d0m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171333311 16227 127.0.0.1 (13 Feb 2007 02:21:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqr40h$d0m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11647

Randy Jennings wrote:
> //-------------------------------------
> Problem 1d: I was expecting the answer key to have a bit more explanation. 
> Would
> someone care to elaborate why the probability would be higher?  I do not see
> it.
> 
> If the person takes the class again, the class will not start on the same
> day because cs244a is (with high probability) on Tuesday/Thursday.  The next
> year, that day of the week shifts one day.  Therefore, that person has two
> days he must not have a birthday, making the probability 
> ((364/365)^(5*50-2))*(363/365), which is 50.3647%, or lower than 
> ((364/365)^(5*50)), which is 50.3651%.
> 
> If we were talking about Christmas, which always lands on the same day of 
> the year, the answer would be ((364/365)^(5N-1)), or 50.5035%, which is, of 
> course, higher.  However, that was not the question in the assignment.

I believe the rubric made the assumption that class was on the same day 
each year which would result in a larger value.  If you stated that you 
made the assumption that class was on different days each year and used 
the above formula I think we can safely give you points back.

> //--------------------------------------------------
> Problem 6b:  Why did the problem assume that queue length was still 128KB?
> 
> It was asked on the newsgroup if we should assume this, but the response was 
> off topic, and the restate was ignored.
> 
> That does not seem like a reasonable assumption as the problem is stated. 
> Sure, it makes the problem easier, and independent of the arrival process, 
> but that does not mean it is realistic.  If you drop the incoming rate, you 
> should drop the queue length!

I'm sorry you did not get an sufficient reply to your question on the 
newsgroup.  If you examine the 6b you will see that it is asking for the 
  average delay in the router.  Using Little's Result: L = AD  (L is 
customers in system, A is arrival rate, D is time waiting in the 
system).  You are given the fact A is 15% of what it was in 6a.  You 
need 2 variables to solve for the third, and nothing is told to you 
about any changes to the queue size so you must assume it stays the 
same, thus giving you the ability to solve for D.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW#1 problem 1d, 6b
Date: Mon, 12 Feb 2007 18:45:25 -0800
Lines: 20
Distribution: su
Message-ID: <eqr8mk$gpq$1@news.Stanford.EDU>
References: <eqr40h$d0m$1@news.Stanford.EDU> <eqr7bv$fr3$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171334676 17210 127.0.0.1 (13 Feb 2007 02:44:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11648

> I'm sorry you did not get an sufficient reply to your question on the 
> newsgroup.  If you examine the 6b you will see that it is asking for the 
> average delay in the router.  Using Little's Result: L = AD  (L is 
> customers in system, A is arrival rate, D is time waiting in the system). 
> You are given the fact A is 15% of what it was in 6a.  You need 2 
> variables to solve for the third, and nothing is told to you about any 
> changes to the queue size so you must assume it stays the same, thus 
> giving you the ability to solve for D.
If I understand your response, you are saying assume queue length is the 
same so you can solve the problem, and on no other basis.  Is that correct?

If I made a different assumption (queue length varied and the queue was 
M/M/1), would that also be a valid assumption?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: past exams
Date: Mon, 12 Feb 2007 19:52:15 -0700
Lines: 29
Distribution: su
Message-ID: <eqr951$h7e$1@news.Stanford.EDU>
References: <eoc0nt$oan$1@news.Stanford.EDU> <C1CF2323.74E3%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1171335137 17646 127.0.0.1 (13 Feb 2007 02:52:17 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11649

May we have a practice exam or two to take a look at?  Also, will the 
midterm be open or closed notes?

Thanks

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1CF2323.74E3%jpettit@stanford.edu...
> In previous versions of this course, past exams have been posted.  I'm 
> sure
> we'll do the same when we get closer to midterm and final.
>
> --Justin
>
>
> On 1/13/07 5:25 PM, in article eoc0nt$oan$1@news.Stanford.EDU, "Jad Naous"
> <jnaous@stanford.edu> wrote:
>
>> Hi,
>>
>> It would be very useful if we could have past exams posted so we can
>> know what the format is and how to read the book and what to concentrate 
>> on.
>>
>> Thanks,
>> Jad.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW#1 problem 1d, 6b
Date: Mon, 12 Feb 2007 19:19:06 -0800
Lines: 21
Distribution: su
Message-ID: <eqran4$i60$1@news.Stanford.EDU>
References: <eqr40h$d0m$1@news.Stanford.EDU> <eqr7bv$fr3$1@news.Stanford.EDU> <eqr8mk$gpq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171336740 18624 127.0.0.1 (13 Feb 2007 03:19:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqr8mk$gpq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11650

Randy Jennings wrote:
>> I'm sorry you did not get an sufficient reply to your question on the 
>> newsgroup.  If you examine the 6b you will see that it is asking for the 
>> average delay in the router.  Using Little's Result: L = AD  (L is 
>> customers in system, A is arrival rate, D is time waiting in the system). 
>> You are given the fact A is 15% of what it was in 6a.  You need 2 
>> variables to solve for the third, and nothing is told to you about any 
>> changes to the queue size so you must assume it stays the same, thus 
>> giving you the ability to solve for D.
> If I understand your response, you are saying assume queue length is the 
> same so you can solve the problem, and on no other basis.  Is that correct?
> 
> If I made a different assumption (queue length varied and the queue was 
> M/M/1), would that also be a valid assumption?
> 

I believe on this problem there was nothing to point you toward a 
Poisson Model for arrival, or to a M/M/1 queue.  You are certainly 
welcome to take the question to Nick if you would like to pursue it.

-David
.

Path: shelby.stanford.edu!elaine26.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: [PS2] Traceroute to Baghdad University?
Date: Mon, 12 Feb 2007 21:44:30 -0800
Lines: 5
Distribution: su
Message-ID: <Pine.GSO.4.44.0702122141580.10587-100000@elaine26.Stanford.EDU>
NNTP-Posting-Host: elaine26.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171345472 25431 171.64.15.101 (13 Feb 2007 05:44:32 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11651

Hi, I have a question regarding traceroute. If I am able to always view a
particular site (i.e. Baghdad University) using a browser, why is my
traceroute always getting stuck midway and can not complete? Is this a
normal behavior?

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: past exams
Date: Mon, 12 Feb 2007 21:44:51 -0800
Lines: 49
Distribution: su
Message-ID: <C1F69053.84B2%jpettit@stanford.edu>
References: <eoc0nt$oan$1@news.Stanford.EDU> <C1CF2323.74E3%jpettit@stanford.edu> <eqr951$h7e$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171345497 25440 127.0.0.1 (13 Feb 2007 05:44:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: past exams
Thread-Index: AcdPMhQ/UvGoRbslEduG0AARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11652

Last year's midterm and solutions have been posted to the main page.  You
can reach them directly here:

    http://www.stanford.edu/class/cs244a/midterm/midterm_2006.pdf

    http://www.stanford.edu/class/cs244a/midterm/midterm_2006_soln.pdf

You are allowed to bring one sheet of 8.5x11-inch paper with writing on one
side.  Make sure to keep it, since you'll be able to use both sides for the
final.  Also, you are allowed, and encouraged, to bring a calculator to the
exam.

--Justin


On 2/12/07 6:52 PM, in article eqr951$h7e$1@news.Stanford.EDU, "Kevin Hart"
<kevin.hart@hp.com> wrote:

> May we have a practice exam or two to take a look at?  Also, will the
> midterm be open or closed notes?
> 
> Thanks
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1CF2323.74E3%jpettit@stanford.edu...
>> In previous versions of this course, past exams have been posted.  I'm
>> sure
>> we'll do the same when we get closer to midterm and final.
>> 
>> --Justin
>> 
>> 
>> On 1/13/07 5:25 PM, in article eoc0nt$oan$1@news.Stanford.EDU, "Jad Naous"
>> <jnaous@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> It would be very useful if we could have past exams posted so we can
>>> know what the format is and how to read the book and what to concentrate
>>> on.
>>> 
>>> Thanks,
>>> Jad.
>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PS2] Traceroute to Baghdad University?
Date: Mon, 12 Feb 2007 22:54:01 -0800
Lines: 53
Distribution: su
Message-ID: <eqrna2$rcf$1@news.Stanford.EDU>
References: <Pine.GSO.4.44.0702122141580.10587-100000@elaine26.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171349635 28047 127.0.0.1 (13 Feb 2007 06:53:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Pine.GSO.4.44.0702122141580.10587-100000@elaine26.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11653

Ryan Chen wrote:
> Hi, I have a question regarding traceroute. If I am able to always view a
> particular site (i.e. Baghdad University) using a browser, why is my
> traceroute always getting stuck midway and can not complete? Is this a
> normal behavior?
> 

I was unable to reproduce your problem:
Tracing route to univofbaghdad.com [204.10.37.9]
over a maximum of 30 hops:

   1    45 ms    45 ms    45 ms  192.168.1.1
   2     *        *        *     Request timed out.
   3    59 ms    63 ms    25 ms 
ge-4-5-ur02.santaclara.ca.sfba.comcast.net [68.8
6.249.1]
   4     *       50 ms     *     te-5-1-ar01.oakland.ca.sfba.comcast.net 
[68.87.2
26.221]
   5    65 ms    44 ms    73 ms  68.87.226.134
   6    67 ms    60 ms    63 ms  12.116.188.13
   7    96 ms    93 ms    99 ms  tbr1011401.sffca.ip.att.net [12.123.12.122]
   8    62 ms    72 ms    66 ms  tbr1-cl3.la2ca.ip.att.net [12.122.10.26]
   9   101 ms    44 ms    53 ms  tbr2-cl2384.la2ca.ip.att.net [12.122.9.146]
  10   106 ms   111 ms    69 ms  gbr2-p30.sd2ca.ip.att.net [12.122.2.121]
  11   117 ms   100 ms    48 ms  gar2-p391.sd2ca.ip.att.net [12.123.145.181]
  12   126 ms   107 ms   126 ms  12.118.229.14
  13   117 ms    53 ms   116 ms  rsmtdsrj01-so000.rd.oc.cox.net [68.1.0.185]
  14    64 ms    85 ms    94 ms  rsmtsysj01.rd.oc.cox.net [68.4.14.254]
  15    44 ms    32 ms    80 ms  ip68-4-13-242.oc.oc.cox.net [68.4.13.242]
  16    76 ms    78 ms   114 ms  wsip-64-58-132-102.oc.oc.cox.net 
[64.58.132.102]

  17    94 ms    60 ms    52 ms  wsip-64-58-132-113.oc.oc.cox.net 
[64.58.132.113]

  18    52 ms    80 ms    91 ms  wsip-64-58-132-238.oc.oc.cox.net 
[64.58.132.238]

  19    60 ms    55 ms    97 ms  wsip-66-210-48-122.oc.oc.cox.net 
[66.210.48.122]

  20    30 ms    79 ms    75 ms  v9.core2.irv.intelenet.net [216.23.160.97]
  21    84 ms    75 ms    35 ms  gi1-0-1.core1.irv.ndchost.com 
[216.23.174.20]
  22    53 ms    99 ms   104 ms  rs101.ehostdepot.net [204.10.37.9]

Trace complete.

But in general if your trace is dieing its possible the routes are setup 
wrong, or a router is specifically dropping your traffic for some reason.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: [PS2] Traceroute to Baghdad University?
Date: Mon, 12 Feb 2007 23:34:11 -0800
Lines: 19
Distribution: su
Message-ID: <eqrpk2$75$1@news.Stanford.EDU>
References: <Pine.GSO.4.44.0702122141580.10587-100000@elaine26.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171352002 229 127.0.0.1 (13 Feb 2007 07:33:22 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11654

> Hi, I have a question regarding traceroute. If I am able to always view a
> particular site (i.e. Baghdad University) using a browser, why is my
> traceroute always getting stuck midway and can not complete? Is this a
> normal behavior?

Unfortunately, all to common, and common enough that it has to be 
intentional.  I had some real gems in South America, but they refuse to 
complete.  Those three stars on the next 3-4 lines got really irritating.  I 
am sure it is a security issue, perhaps a NAT or other firewall (although 
port 80 was not completing either).

:-(

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: sr Topologies
Date: Tue, 13 Feb 2007 09:52:04 -0800
Lines: 8
Distribution: su
Message-ID: <eqsu8n$3p3$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171389527 3875 171.64.74.54 (13 Feb 2007 17:58:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:11655

I'm currently taking down the sr topologies to facilitate some 
renumbering that needs to be done, and getting out the topologies for 
assignment 4.  If anyone still needs theirs for some reason (you're 
working on sr late with an extension, for instance), please let me know 
via email so I can make sure you're still able to work while I'm moving 
things around.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2: Q 7(g)
Date: Tue, 13 Feb 2007 11:53:59 -0800
Lines: 5
Distribution: su
Message-ID: <eqt4t4$a5m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171396324 10422 127.0.0.1 (13 Feb 2007 19:52:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11656

What are the commands in unix that'd give the time taken for a command like 
traceroute to complete? I tried using date and times. Saw no difference in 
the time taken for traceroute with and without '-n' option. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 11:55:06 -0800
Lines: 3
Distribution: su
Message-ID: <eqt4v7$a6r$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171396391 10459 127.0.0.1 (13 Feb 2007 19:53:11 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11657

What's the IP address (or name) of  "the Sweet Hall router"? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2: Q 7(d)
Date: Tue, 13 Feb 2007 11:58:42 -0800
Lines: 4
Distribution: su
Message-ID: <eqt55v$abt$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171396607 10621 127.0.0.1 (13 Feb 2007 19:56:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11658

When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
hops. Is anyone else facing this problem? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2: Q 1(c)
Date: Tue, 13 Feb 2007 12:03:03 -0800
Lines: 6
Distribution: su
Message-ID: <eqt5e4$aih$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171396868 10833 127.0.0.1 (13 Feb 2007 20:01:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11659

The question has a part "why it exists"? Is the "it" here "the owner of the 
network" or "the network"?
Either way it is just a matter of googling, I suppose. Or is there any other 
way to figure this out? 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(g)
Date: Tue, 13 Feb 2007 12:16:33 -0800
Lines: 9
Distribution: su
Message-ID: <eqt6nl$bod$1@news.Stanford.EDU>
References: <eqt4t4$a5m$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171398197 12045 171.64.74.54 (13 Feb 2007 20:23:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqt4t4$a5m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11660

Take a look at man 1 time.

Clay
Riju Kallivalappil wrote:
> What are the commands in unix that'd give the time taken for a command like 
> traceroute to complete? I tried using date and times. Saw no difference in 
> the time taken for traceroute with and without '-n' option. 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 1(c)
Date: Tue, 13 Feb 2007 12:23:57 -0800
Lines: 15
Distribution: su
Message-ID: <eqt75m$c7a$1@news.Stanford.EDU>
References: <eqt5e4$aih$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171398646 12522 171.64.74.54 (13 Feb 2007 20:30:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqt5e4$aih$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11661

The question is why that network link/router exists, not why the owner 
of the network exists (which is a fairly complex ontological question, 
in some cases).  And I believe the thrust of the question is 'why is 
that router there/why are your packets passing through this 
organizations router en route to Tokyo', rather than figuring out why 
that organization decided to build a network at all.

Clay
Riju Kallivalappil wrote:
> The question has a part "why it exists"? Is the "it" here "the owner of the 
> network" or "the network"?
> Either way it is just a matter of googling, I suppose. Or is there any other 
> way to figure this out? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem connecting to elaine25
Date: Tue, 13 Feb 2007 12:36:09 -0800
Lines: 6
Distribution: su
Message-ID: <eqt7fr$ccv$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-98337.stanford.edu
X-Trace: news.Stanford.EDU 1171398972 12703 128.12.159.69 (13 Feb 2007 20:36:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11662

I don't know why I am not able to connect to elaine25.stanford.edu.

can I write down the sequence of routers from any elaine cluster machine or 
elaine25 is the strict requirement? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Q9
Date: Tue, 13 Feb 2007 12:38:53 -0800
Lines: 6
Distribution: su
Message-ID: <eqt7l0$cfh$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-98337.stanford.edu
X-Trace: news.Stanford.EDU 1171399136 12785 128.12.159.69 (13 Feb 2007 20:38:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11663

Can we consider a path having some loopbacks and at the end reach the 
destination.

My question is that can we consider that path as the longest path ? 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem connecting to elaine25
Date: Tue, 13 Feb 2007 13:32:39 -0800
Lines: 15
Distribution: su
Message-ID: <eqtb6b$fhr$1@news.Stanford.EDU>
References: <eqt7fr$ccv$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171402764 15931 171.64.74.54 (13 Feb 2007 21:39:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqt7fr$ccv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11664

The other machines in the elaine cluster should have an identical path, 
so you can use one of those.  Please make a note of which machine in the 
cluster you ran the command from in case we find later that there is 
some discrepancy.  I've opened a ticket with ITS to try and figure out 
what's going on with elaine25- it doesn't seem to be responding to ping 
requests either.

Clay
Mohammad Asif wrote:
> I don't know why I am not able to connect to elaine25.stanford.edu.
> 
> can I write down the sequence of routers from any elaine cluster machine or 
> elaine25 is the strict requirement? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Wed, 14 Feb 2007 00:43:26 +0000 (UTC)
Lines: 7
Distribution: su
Message-ID: <eqtlve$qof$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU>
NNTP-Posting-Host: myth24.stanford.edu
X-Trace: news.Stanford.EDU 1171413806 27407 171.64.15.34 (14 Feb 2007 00:43:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11665

I have the same issue....

Riju Kallivalappil <riju@stanford.edu> wrote:
> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
> hops. Is anyone else facing this problem? 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 17:22:28 -0800
Lines: 10
Distribution: su
Message-ID: <eqtolb$6c$1@news.Stanford.EDU>
References: <eqt4v7$a6r$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171416555 204 171.64.74.54 (14 Feb 2007 01:29:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqt4v7$a6r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11666

Just use Gates-rtr for this one- there were some significant changes to 
the setup of the clusters since the assignment was written (the clusters 
are no longer in Sweet Hall, for instance).

Clay

Riju Kallivalappil wrote:
> What's the IP address (or name) of  "the Sweet Hall router"? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Tue, 13 Feb 2007 17:42:06 -0800
Lines: 28
Distribution: su
Message-ID: <eqtpqa$16r$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171417739 1243 171.64.74.54 (14 Feb 2007 01:48:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqtlve$qof$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11667

Hm, it appears that the UCL network has a firewall blocking the UDP 
probe packets.  I would take a look at the IP addresses that you get 
from traceroute before the hosts stop responding; remember, the question 
is how many hops to UCL, not to a particular UCL host.

Furthermore, if you think it's necessary information, I can tell you 
that there is only one more hop in the traceroute and that its RTT is 
~179 ms on average.

Plus, the first person to tell me how I know this to be the case wins a 
No Prize.

Clay

Dinesh Gupta wrote:
Riju Kallivalappil wrote:
> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
> hops. Is anyone else facing this problem? 
> 
> 

> I have the same issue....
> 
> Riju Kallivalappil <riju@stanford.edu> wrote:
>> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
>> hops. Is anyone else facing this problem? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 18:27:55 -0800
Lines: 15
Distribution: su
Message-ID: <eqts37$32j$1@news.Stanford.EDU>
References: <eqt4v7$a6r$1@news.Stanford.EDU> <eqtolb$6c$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171420071 3155 128.12.194.72 (14 Feb 2007 02:27:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eqtolb$6c$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11668

Would Sweet-rtr be acceptable? That still seems to be around.

-Yangfan

Clay Collier wrote:
> Just use Gates-rtr for this one- there were some significant changes to 
> the setup of the clusters since the assignment was written (the clusters 
> are no longer in Sweet Hall, for instance).
> 
> Clay
> 
> Riju Kallivalappil wrote:
> 
>> What's the IP address (or name) of  "the Sweet Hall router"?
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Wed, 14 Feb 2007 02:31:46 +0000 (UTC)
Lines: 78
Distribution: su
Message-ID: <eqtsai$371$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU>
NNTP-Posting-Host: myth24.stanford.edu
X-Trace: news.Stanford.EDU 1171420306 3297 171.64.15.34 (14 Feb 2007 02:31:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11669

Hi Clay,

My traceroute looks like :

traceroute ucl.ac.uk
traceroute to ucl.ac.uk (144.82.108.183): 1-30 hops, 38 byte packets
 1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.371 ms  0.232 ms  0.360 ms
 2  bbra-rtr.Stanford.EDU (171.64.1.52)  0.983 ms  0.625 ms  0.743 ms
 3  hpr1-rtr.Stanford.EDU (171.64.1.131)  0.746 ms  0.752 ms  0.618 ms
 4  hpr-svl-hpr--stan-ge.cenic.net (137.164.27.161)  1.37 ms  1.25 ms  *
 5  lax-hpr--svl-hpr-10ge.cenic.net (137.164.25.12)  184 ms  10.4 ms
203 ms
 6  nlr-packetnet--hpr-lax-hpr.cenic.net (137.164.26.131)  9.46 ms  9.36
ms  9.11 ms
 7  hous-losa-87.layer3.nlr.net (216.24.186.31)  39.9 ms  40.0 ms  40.1
ms
 8  atla-hous-70.layer3.nlr.net (216.24.186.9)  64.7 ms  64.3 ms  63.9
ms
 9  wash-atla-64.layer3.nlr.net (216.24.186.21)  77.4 ms  77.2 ms  77.3
ms
10  newy-wash-98.layer3.nlr.net (216.24.186.22)  83.8 ms  84.0 ms  84.8
ms
11  216.24.184.86 (216.24.184.86)  82.3 ms (ttl=244!)  82.2 ms
(ttl=244!)  82.3 ms (ttl=244!)
12  so-7-0-0.rt1.ams.nl.geant2.net (62.40.112.133)  169 ms (ttl=243!)
169 ms (ttl=243!)  169 ms (ttl=243!)
13  so-4-0-0.rt2.lon.uk.geant2.net (62.40.112.138)  177 ms (ttl=242!)
237 ms (ttl=242!)  177 ms (ttl=242!)
14  po2-0-0.gn2-gw1.ja.net (62.40.124.198)  177 ms  177 ms  177 ms
15  po1-1.lond-scr3.ja.net (146.97.35.97)  177 ms  177 ms  177 ms
16  so-0-1-0.lond-sbr1.ja.net (146.97.33.133)  178 ms (ttl=239!)  178 ms
(ttl=239!)  178 ms (ttl=239!)
17  LMN-LMN1.site.ja.net (146.97.42.62)  178 ms  178 ms  178 ms
18  ucl.lmn.net.uk (194.83.101.6)  178 ms  178 ms  178 ms
19  128.40.20.189 (128.40.20.189)  178 ms  178 ms  178 ms
20  128.40.20.206 (128.40.20.206)  178 ms  178 ms  178 ms
21  128.40.20.170 (128.40.20.170)  178 ms  178 ms  178 ms
22  *  *  *
23  *  *  *
24  *  *  *
25  *  *  *
26  *  *  *
27  *  *  *
28  *  *  *
29  *  *  *
30  *  *  *

Thanks,
Dinesh
Clay Collier <ccollier@stanford.edu> wrote:
> Hm, it appears that the UCL network has a firewall blocking the UDP 
> probe packets.  I would take a look at the IP addresses that you get 
> from traceroute before the hosts stop responding; remember, the question 
> is how many hops to UCL, not to a particular UCL host.

> Furthermore, if you think it's necessary information, I can tell you 
> that there is only one more hop in the traceroute and that its RTT is 
> ~179 ms on average.

> Plus, the first person to tell me how I know this to be the case wins a 
> No Prize.

> Clay

> Dinesh Gupta wrote:
> Riju Kallivalappil wrote:
> > When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
> > hops. Is anyone else facing this problem? 
> > 
> > 

> > I have the same issue....
> > 
> > Riju Kallivalappil <riju@stanford.edu> wrote:
> >> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
> >> hops. Is anyone else facing this problem? 
> > 
> > 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problem Set 2 question 8
Date: Tue, 13 Feb 2007 19:49:22 -0800
Lines: 6
Distribution: su
Message-ID: <equ0ru$7up$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171424958 8153 128.12.194.72 (14 Feb 2007 03:49:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11670

I've looked through the command line options for traceroute, and I can't 
find the one that suppresses RTT calculation for intermediate routers.

Is there such an option? Am I just not looking hard enough?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 19:50:35 -0800
Lines: 21
Distribution: su
Message-ID: <equ1b2$8bl$1@news.Stanford.EDU>
References: <eqt4v7$a6r$1@news.Stanford.EDU> <eqtolb$6c$1@news.Stanford.EDU> <eqts37$32j$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171425442 8565 171.64.74.54 (14 Feb 2007 03:57:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqts37$32j$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11671

Stick with gates-rtr.  It's easier to access directly from all the 
cluster machines- sweet-rtr is positioned behind a number of intervening 
routers from the cluster nodes.

Clay
Yangfan Wang wrote:
> Would Sweet-rtr be acceptable? That still seems to be around.
> 
> -Yangfan
> 
> Clay Collier wrote:
>> Just use Gates-rtr for this one- there were some significant changes 
>> to the setup of the clusters since the assignment was written (the 
>> clusters are no longer in Sweet Hall, for instance).
>>
>> Clay
>>
>> Riju Kallivalappil wrote:
>>
>>> What's the IP address (or name) of  "the Sweet Hall router"?
>>>
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 20:00:09 -0800
Lines: 29
Distribution: su
Message-ID: <equ1g5$8el$1@news.Stanford.EDU>
References: <eqt4v7$a6r$1@news.Stanford.EDU> <eqtolb$6c$1@news.Stanford.EDU> <eqts37$32j$1@news.Stanford.EDU> <equ1b2$8bl$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171425605 8661 128.12.194.72 (14 Feb 2007 04:00:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <equ1b2$8bl$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11672

Well, considering the problem at hand (maximum transmission unit), I 
don't believe it matters.

-Yangfan

Clay Collier wrote:
> Stick with gates-rtr.  It's easier to access directly from all the 
> cluster machines- sweet-rtr is positioned behind a number of intervening 
> routers from the cluster nodes.
> 
> Clay
> Yangfan Wang wrote:
> 
>> Would Sweet-rtr be acceptable? That still seems to be around.
>>
>> -Yangfan
>>
>> Clay Collier wrote:
>>
>>> Just use Gates-rtr for this one- there were some significant changes 
>>> to the setup of the clusters since the assignment was written (the 
>>> clusters are no longer in Sweet Hall, for instance).
>>>
>>> Clay
>>>
>>> Riju Kallivalappil wrote:
>>>
>>>> What's the IP address (or name) of  "the Sweet Hall router"?
>>>>
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(f)
Date: Tue, 13 Feb 2007 20:01:44 -0800
Lines: 27
Distribution: su
Message-ID: <equ200$8pi$1@news.Stanford.EDU>
References: <eqt4v7$a6r$1@news.Stanford.EDU> <eqtolb$6c$1@news.Stanford.EDU> <eqts37$32j$1@news.Stanford.EDU> <equ1b2$8bl$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171426115 9010 171.64.74.54 (14 Feb 2007 04:08:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <equ1b2$8bl$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11673

It's potentially an issue if the router between you and the one you're 
interested in has a smaller MTU.

Clay

Clay Collier wrote:
> Stick with gates-rtr.  It's easier to access directly from all the 
> cluster machines- sweet-rtr is positioned behind a number of intervening 
> routers from the cluster nodes.
> 
> Clay
> Yangfan Wang wrote:
>> Would Sweet-rtr be acceptable? That still seems to be around.
>>
>> -Yangfan
>>
>> Clay Collier wrote:
>>> Just use Gates-rtr for this one- there were some significant changes 
>>> to the setup of the clusters since the assignment was written (the 
>>> clusters are no longer in Sweet Hall, for instance).
>>>
>>> Clay
>>>
>>> Riju Kallivalappil wrote:
>>>
>>>> What's the IP address (or name) of  "the Sweet Hall router"?
>>>>
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Tue, 13 Feb 2007 20:04:26 -0800
Lines: 14
Distribution: su
Message-ID: <equ252$8pi$2@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171426275 9010 171.64.74.54 (14 Feb 2007 04:11:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <equ0ru$7up$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11674

The option that you want is in the man pages, but it's not obvious. 
You're not looking for a literal 'don't calculate intermediate TTL' 
flag; rather, you're looking for an option that will have the effect of 
not having any intermediate TTLs calculated other than the TTL for the 
host you're interested in.

Clay
Yangfan Wang wrote:
> I've looked through the command line options for traceroute, and I can't 
> find the one that suppresses RTT calculation for intermediate routers.
> 
> Is there such an option? Am I just not looking hard enough?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Tue, 13 Feb 2007 20:12:55 -0800
Lines: 41
Distribution: su
Message-ID: <equ288$91a$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab422151.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171426376 9258 171.66.33.81 (14 Feb 2007 04:12:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11675

Hi Clay--

I'm not sure how you know this. Netcraft indicates that the UCL www 
server is running FreeBSD, which by default sets TTL values to 64. Yet, 
when I receive packets from www.ucl.ac.uk, they have a TTL of 39. That 
would suggest that there are 25 hops between us and them, which is four 
more than traceroute finds. Maybe I'm off by one, but it suggests that 
there are three more hops behind the firewall... am I missing something?

Cheers,
Peter

On 2007-02-13 17:42:06 -0800, Clay Collier <ccollier@stanford.edu> said:

> Hm, it appears that the UCL network has a firewall blocking the UDP 
> probe packets.  I would take a look at the IP addresses that you get 
> from traceroute before the hosts stop responding; remember, the 
> question is how many hops to UCL, not to a particular UCL host.
> 
> Furthermore, if you think it's necessary information, I can tell you 
> that there is only one more hop in the traceroute and that its RTT is 
> ~179 ms on average.
> 
> Plus, the first person to tell me how I know this to be the case wins a 
> No Prize.
> 
> Clay
> 
> Dinesh Gupta wrote:
> Riju Kallivalappil wrote:
>> When I did a traceroute from myth22 to UCL, the traceroute failed after 
>> 21 hops. Is anyone else facing this problem?
>> 
> 
>> I have the same issue....
>> 
>> Riju Kallivalappil <riju@stanford.edu> wrote:
>>> When I did a traceroute from myth22 to UCL, the traceroute failed after 
>>> 21 hops. Is anyone else facing this problem?


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Tue, 13 Feb 2007 21:22:28 -0800
Lines: 53
Distribution: su
Message-ID: <equ6ng$c28$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU> <equ288$91a$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171430961 12360 171.64.74.54 (14 Feb 2007 05:29:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <equ288$91a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11676

I may have misspoke earlier- when I said one more hop, I meant that 
there  is a total of 22 hops- forgot that the 21st isn't really visible. 
  Both have a mean RTT around 179 ms.

Where is that TTL of 39 coming from?  It's quite possible that the 
initial TTL is being set to something other than 64- and 60 is one 
common alternate value.  Still sticking with that 22 hops, as I do have 
some additional information.

Clay

Peter Pawlowski wrote:
> Hi Clay--
> 
> I'm not sure how you know this. Netcraft indicates that the UCL www 
> server is running FreeBSD, which by default sets TTL values to 64. Yet, 
> when I receive packets from www.ucl.ac.uk, they have a TTL of 39. That 
> would suggest that there are 25 hops between us and them, which is four 
> more than traceroute finds. Maybe I'm off by one, but it suggests that 
> there are three more hops behind the firewall... am I missing something?
> 
> Cheers,
> Peter
> 
> On 2007-02-13 17:42:06 -0800, Clay Collier <ccollier@stanford.edu> said:
> 
>> Hm, it appears that the UCL network has a firewall blocking the UDP 
>> probe packets.  I would take a look at the IP addresses that you get 
>> from traceroute before the hosts stop responding; remember, the 
>> question is how many hops to UCL, not to a particular UCL host.
>>
>> Furthermore, if you think it's necessary information, I can tell you 
>> that there is only one more hop in the traceroute and that its RTT is 
>> ~179 ms on average.
>>
>> Plus, the first person to tell me how I know this to be the case wins 
>> a No Prize.
>>
>> Clay
>>
>> Dinesh Gupta wrote:
>> Riju Kallivalappil wrote:
>>> When I did a traceroute from myth22 to UCL, the traceroute failed 
>>> after 21 hops. Is anyone else facing this problem?
>>>
>>
>>> I have the same issue....
>>>
>>> Riju Kallivalappil <riju@stanford.edu> wrote:
>>>> When I did a traceroute from myth22 to UCL, the traceroute failed 
>>>> after 21 hops. Is anyone else facing this problem?
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Tue, 13 Feb 2007 21:34:43 -0800
Lines: 86
Distribution: su
Message-ID: <equ7eg$cju$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU> <eqtsai$371$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171431697 12926 171.64.74.54 (14 Feb 2007 05:41:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eqtsai$371$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11677

Yes, this is what the basic traceroute output looks like for everyone. 
There is one more hop in the tracerout with a mean RTT of 179 ms. 
However, if you read the question closely, I believe that you have 
enough information to answer the question with what you have.  Take a 
look at WHOIS if you need more info.

Clay

Dinesh Gupta wrote:
> Hi Clay,
> 
> My traceroute looks like :
> 
> traceroute ucl.ac.uk
> traceroute to ucl.ac.uk (144.82.108.183): 1-30 hops, 38 byte packets
>  1  Gates-rtr.Stanford.EDU (171.64.15.1)  0.371 ms  0.232 ms  0.360 ms
>  2  bbra-rtr.Stanford.EDU (171.64.1.52)  0.983 ms  0.625 ms  0.743 ms
>  3  hpr1-rtr.Stanford.EDU (171.64.1.131)  0.746 ms  0.752 ms  0.618 ms
>  4  hpr-svl-hpr--stan-ge.cenic.net (137.164.27.161)  1.37 ms  1.25 ms  *
>  5  lax-hpr--svl-hpr-10ge.cenic.net (137.164.25.12)  184 ms  10.4 ms
> 203 ms
>  6  nlr-packetnet--hpr-lax-hpr.cenic.net (137.164.26.131)  9.46 ms  9.36
> ms  9.11 ms
>  7  hous-losa-87.layer3.nlr.net (216.24.186.31)  39.9 ms  40.0 ms  40.1
> ms
>  8  atla-hous-70.layer3.nlr.net (216.24.186.9)  64.7 ms  64.3 ms  63.9
> ms
>  9  wash-atla-64.layer3.nlr.net (216.24.186.21)  77.4 ms  77.2 ms  77.3
> ms
> 10  newy-wash-98.layer3.nlr.net (216.24.186.22)  83.8 ms  84.0 ms  84.8
> ms
> 11  216.24.184.86 (216.24.184.86)  82.3 ms (ttl=244!)  82.2 ms
> (ttl=244!)  82.3 ms (ttl=244!)
> 12  so-7-0-0.rt1.ams.nl.geant2.net (62.40.112.133)  169 ms (ttl=243!)
> 169 ms (ttl=243!)  169 ms (ttl=243!)
> 13  so-4-0-0.rt2.lon.uk.geant2.net (62.40.112.138)  177 ms (ttl=242!)
> 237 ms (ttl=242!)  177 ms (ttl=242!)
> 14  po2-0-0.gn2-gw1.ja.net (62.40.124.198)  177 ms  177 ms  177 ms
> 15  po1-1.lond-scr3.ja.net (146.97.35.97)  177 ms  177 ms  177 ms
> 16  so-0-1-0.lond-sbr1.ja.net (146.97.33.133)  178 ms (ttl=239!)  178 ms
> (ttl=239!)  178 ms (ttl=239!)
> 17  LMN-LMN1.site.ja.net (146.97.42.62)  178 ms  178 ms  178 ms
> 18  ucl.lmn.net.uk (194.83.101.6)  178 ms  178 ms  178 ms
> 19  128.40.20.189 (128.40.20.189)  178 ms  178 ms  178 ms
> 20  128.40.20.206 (128.40.20.206)  178 ms  178 ms  178 ms
> 21  128.40.20.170 (128.40.20.170)  178 ms  178 ms  178 ms
> 22  *  *  *
> 23  *  *  *
> 24  *  *  *
> 25  *  *  *
> 26  *  *  *
> 27  *  *  *
> 28  *  *  *
> 29  *  *  *
> 30  *  *  *
> 
> Thanks,
> Dinesh
> Clay Collier <ccollier@stanford.edu> wrote:
>> Hm, it appears that the UCL network has a firewall blocking the UDP 
>> probe packets.  I would take a look at the IP addresses that you get 
>> from traceroute before the hosts stop responding; remember, the question 
>> is how many hops to UCL, not to a particular UCL host.
> 
>> Furthermore, if you think it's necessary information, I can tell you 
>> that there is only one more hop in the traceroute and that its RTT is 
>> ~179 ms on average.
> 
>> Plus, the first person to tell me how I know this to be the case wins a 
>> No Prize.
> 
>> Clay
> 
>> Dinesh Gupta wrote:
>> Riju Kallivalappil wrote:
>>> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
>>> hops. Is anyone else facing this problem? 
>>>
>>>
> 
>>> I have the same issue....
>>>
>>> Riju Kallivalappil <riju@stanford.edu> wrote:
>>>> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
>>>> hops. Is anyone else facing this problem? 
>>>
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Wed, 14 Feb 2007 00:13:25 -0800
Lines: 14
Distribution: su
Message-ID: <equgat$m50$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU> <equ288$91a$1@news.Stanford.EDU> <equ6ng$c28$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171440797 22688 127.0.0.1 (14 Feb 2007 08:13:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <equ6ng$c28$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11678

Clay Collier wrote:
> I may have misspoke earlier- when I said one more hop, I meant that 
> there  is a total of 22 hops- forgot that the 21st isn't really visible. 
>  Both have a mean RTT around 179 ms.
> 
> Where is that TTL of 39 coming from?  It's quite possible that the 
> initial TTL is being set to something other than 64- and 60 is one 
> common alternate value.  Still sticking with that 22 hops, as I do have 
> some additional information.
> 

They still haven't detected your zombie cluster there yet? Suckers.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Q9
Date: Wed, 14 Feb 2007 23:35:42 -0800
Lines: 12
Distribution: su
Message-ID: <er12gf$rv1$1@news.Stanford.EDU>
References: <eqt7l0$cfh$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171524943 28641 127.0.0.1 (15 Feb 2007 07:35:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eqt7l0$cfh$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11679

Mohammad Asif wrote:
> Can we consider a path having some loopbacks and at the end reach the 
> destination.
> 
> My question is that can we consider that path as the longest path ? 
> 
> 

I believe the path should be loop free, otherwise there is some 
seriously messed up routing in place.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Thu, 15 Feb 2007 05:12:48 -0500
Lines: 24
Distribution: su
Message-ID: <er1bnb$8gs$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU> <eqtlve$qof$1@news.Stanford.EDU> <eqtpqa$16r$1@news.Stanford.EDU> <equ288$91a$1@news.Stanford.EDU> <equ6ng$c28$1@news.Stanford.EDU> <equgat$m50$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171534380 8732 127.0.0.1 (15 Feb 2007 10:13:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11680

Is the part about calculating the distance across the Atlantic supposed to 
mean that we need to calculate just he distance across the Atlantic or the 
distance from Stanford (i.e. myth22) to London?

-Seth

"David Erickson" <derickso@stanford.edu> wrote in message 
news:equgat$m50$1@news.Stanford.EDU...
> Clay Collier wrote:
>> I may have misspoke earlier- when I said one more hop, I meant that there 
>> is a total of 22 hops- forgot that the 21st isn't really visible. Both 
>> have a mean RTT around 179 ms.
>>
>> Where is that TTL of 39 coming from?  It's quite possible that the 
>> initial TTL is being set to something other than 64- and 60 is one common 
>> alternate value.  Still sticking with that 22 hops, as I do have some 
>> additional information.
>>
>
> They still haven't detected your zombie cluster there yet? Suckers.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: Ben Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(d)
Date: Thu, 15 Feb 2007 07:40:55 -0800
Lines: 15
Distribution: su
Message-ID: <er1uuj$qsp$1@news.Stanford.EDU>
References: <eqt55v$abt$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171554067 27545 128.12.94.22 (15 Feb 2007 15:41:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
In-Reply-To: <eqt55v$abt$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11681

Also, when answering this question, do we consider only the number of 
hops, or can we also use other info in the traceroute output (e.g. 
average RTT) to calculate the distance between two endpoints?

Also, whitehouse.gov doesn't look close at all--for me, taking 19 hops 
to get there. Am I supposed to be hitting an Akamai cache nearby or 
something?

Ben

Riju Kallivalappil wrote:
> When I did a traceroute from myth22 to UCL, the traceroute failed after 21 
> hops. Is anyone else facing this problem? 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2 and Midterm Logistics
Date: Thu, 15 Feb 2007 14:35:06 -0800
Lines: 23
Distribution: su
Message-ID: <C1FA201A.8634%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171578910 18400 127.0.0.1 (15 Feb 2007 22:35:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS2 and Midterm Logistics
Thread-Index: AcdRUYptyNhoAL1EEdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11682

As you all know, the second problem set is due tomorrow at noon.  To aid
your studying, we are going to publish the solutions tomorrow afternoon.
Because of this, we are going to set an absolute deadline of 5PM.  This
means that you will get charged a late day if you turn in the assignment
between noon and 5PM, and we won't be able to accept submissions after this.

For the midterm, remember that you can bring one sheet of 8.5x11-inch paper
with writing on one side.  Make sure to keep it, since you will be able to
fill in both sides on the final exam.  Also, you should bring a calculator,
since you'll be doing some number crunching on the exam.

SCPD students in the area are expected to take the exam in class.  If you
are too far away to take the exam, you must email me by Monday.  At the time
of the exam, we will email you a URL to download it.  You and your exam
proctor can do the exam anytime within a 24-hour period.  However, you
should not download or look at the exam until you are ready to take it, and
you will need to follow the same time constraints as those taking the exam
in class.

Good luck!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: calculating distance from RTT times
Date: Thu, 15 Feb 2007 17:58:40 -0800
Lines: 8
Distribution: su
Message-ID: <er3349$s6f$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171591113 28879 171.64.74.36 (16 Feb 2007 01:58:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11683

Hi,

Are we just supposed to do time * propagation speed through optical
fiber. And time is just RTT/2? That doesn't take into account any delays
through the routers.

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(g)
Date: Thu, 15 Feb 2007 18:34:00 -0800
Lines: 16
Distribution: su
Message-ID: <er356g$uk$1@news.Stanford.EDU>
References: <eqt4t4$a5m$1@news.Stanford.EDU> <eqt6nl$bod$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171593232 980 171.64.74.36 (16 Feb 2007 02:33:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
In-Reply-To: <eqt6nl$bod$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11684

I'm getting a lot of drops every time I run traceroute, and and the
delays are varying too much to be able to tell if it's just from DNS
lookups. Is there a way around this?

Thanks,
Jad.

Clay Collier wrote:
> Take a look at man 1 time.
> 
> Clay
> Riju Kallivalappil wrote:
>> What are the commands in unix that'd give the time taken for a command
>> like traceroute to complete? I tried using date and times. Saw no
>> difference in the time taken for traceroute with and without '-n' option.
>>
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: How to write Recursive Makefile.
Date: Thu, 15 Feb 2007 19:58:29 -0800
Lines: 37
Distribution: su
Message-ID: <er3a57$49a$1@news.Stanford.EDU>
NNTP-Posting-Host: zeus2.stanford.edu
X-Trace: news.Stanford.EDU 1171598311 4394 128.12.137.163 (16 Feb 2007 03:58:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11685

Hi,

This question is slightly unrelated to cs244a. However, I had this small 
problem with Makefile and I was hoping that some of you guys can help me out 
on this

After writing 2 programming assignments, I have come to realize that there 
are few things which I keep using all the time. This especially incudes my C 
files for list manipulation.

For example, the source directory for pa1 woud look like this:

$ls pa1
Makefile proxy.c proxy.h lib/

$ cd pa1

$ ls lib
list.c list.h types.h

As you would have observed, the lib directory, which is nested within the 
pa1 directory, contains all the list manipulation files. From code 
reusability, I would like to carry on this lib directory from one 
programming assignment to the next.

The question is then how can I write a recursive makefile, such that when I 
call make, in the pa1 directory, it would cd into the lib directory, call 
make, hence generating list.o, which I can link later-on with the proxy.o to 
produce the final executable.

I google'd and tried few things. But, somehow I can't figure this thing out. 
Any help or pointers would be really appreciated.

Manju.



.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: How to write Recursive Makefile.
Date: Thu, 15 Feb 2007 21:22:57 -0800
Lines: 55
Distribution: su
Message-ID: <er3f3t$7i8$1@news.Stanford.EDU>
References: <er3a57$49a$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171603389 7752 128.12.81.44 (16 Feb 2007 05:23:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11686

Hey Manj,

put

$(MAKE) -C ../lib

in the Makefile in the pa1 directory


http://theory.uwinnipeg.ca/gnu/make/make_50.html

-- 
David Gobaud

"manj" <manj@stanford.edu> wrote in message 
news:er3a57$49a$1@news.Stanford.EDU...
> Hi,
>
> This question is slightly unrelated to cs244a. However, I had this small 
> problem with Makefile and I was hoping that some of you guys can help me 
> out on this
>
> After writing 2 programming assignments, I have come to realize that there 
> are few things which I keep using all the time. This especially incudes my 
> C files for list manipulation.
>
> For example, the source directory for pa1 woud look like this:
>
> $ls pa1
> Makefile proxy.c proxy.h lib/
>
> $ cd pa1
>
> $ ls lib
> list.c list.h types.h
>
> As you would have observed, the lib directory, which is nested within the 
> pa1 directory, contains all the list manipulation files. From code 
> reusability, I would like to carry on this lib directory from one 
> programming assignment to the next.
>
> The question is then how can I write a recursive makefile, such that when 
> I call make, in the pa1 directory, it would cd into the lib directory, 
> call make, hence generating list.o, which I can link later-on with the 
> proxy.o to produce the final executable.
>
> I google'd and tried few things. But, somehow I can't figure this thing 
> out. Any help or pointers would be really appreciated.
>
> Manju.
>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Stanford has 2 internet providers?
Date: Thu, 15 Feb 2007 21:50:50 -0800
Lines: 14
Distribution: su
Message-ID: <er3go6$8lj$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171605062 8883 128.12.81.44 (16 Feb 2007 05:51:02 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11687

Hi,

In class a while ago I think Professor McKeown mentioned that Stanford has 
two seperate internet providers - one for academic access to berkeley.edu 
for example and one for everything else but all traceroutes I run go through 
cenic.net. I've tried yahoo.com, berkeley.edu, msn.com, mit.edu, and others. 
Has Stanford changed their ISP setup or maybe the second ISP mentioned for 
Internet 2 traffic?

-- 
Thank you,
David Gobaud


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Stanford has 2 internet providers?
Date: Thu, 15 Feb 2007 22:06:22 -0800
Lines: 45
Distribution: su
Message-ID: <C1FA89DE.8664%jpettit@stanford.edu>
References: <er3go6$8lj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171605983 9393 127.0.0.1 (16 Feb 2007 06:06:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Stanford has 2 internet providers?
Thread-Index: AcdRkJT700vXDr2DEdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11688

Aim a little lower.  ;)  You can try my alma mater:

elaine25> traceroute www.scu.edu
traceroute to www.scu.edu (129.210.2.1): 1-30 hops, 38 byte packets
 1  Gates-rtr.Stanford.EDU (171.64.15.65)  0.673 ms  0.441 ms  0.481 ms
 2  bbra-rtr.Stanford.EDU (171.64.1.52)  1.02 ms  0.866 ms  0.817 ms
 3  border3-rtr.Stanford.EDU (171.64.1.149)  0.856 ms  0.821 ms  0.564 ms
 4  g1.ba21.b003123-1.sfo01.atlas.cogentco.com (66.250.7.137)  1.36 ms  1.87
ms  1.43 ms
 5  p9-0.core02.sfo01.atlas.cogentco.com (66.28.4.233)  3.75 ms  4.20 ms
2.27 ms
 6  t3-3.mpd01.sfo01.atlas.cogentco.com (154.54.3.118)  2.75 ms  2.53 ms
1.93 ms
 7  t2-2.mpd01.sjc01.atlas.cogentco.com (154.54.1.26)  3.28 ms  4.27 ms
5.08 ms
 8  v3490.mpd01.sjc03.atlas.cogentco.com (154.54.6.82)  3.81 ms  3.50 ms
3.94 ms
 9  g0-0-0.core01.sjc03.atlas.cogentco.com (154.54.6.117)  3.89 ms  4.15 ms
5.85 ms
10  uunet.sjc03.atlas.cogentco.com (154.54.13.114)  6.25 ms  4.02 ms  5.49
ms
11  0.so-0-1-0.XL2.SCL2.ALTER.NET (152.63.56.250)  4.20 ms (ttl=244!)  4.25
ms (ttl=244!)  5.05 ms (ttl=244!)
12  0.so-7-0-0.GW2.SCL2.ALTER.NET (152.63.57.1)  4.19 ms (ttl=243!)  4.86 ms
(ttl=243!)  3.97 ms (ttl=243!)
13  scu-gw.customer.alter.net (157.130.193.62)  10.3 ms (ttl=241!)  8.64 ms
(ttl=241!)  8.87 ms (ttl=241!)
14  *  *  *

--Justin


On 2/15/07 9:50 PM, in article er3go6$8lj$1@news.Stanford.EDU, "David
Gobaud" <gobaudd@stanford.edu> wrote:

> Hi,
> 
> In class a while ago I think Professor McKeown mentioned that Stanford has
> two seperate internet providers - one for academic access to berkeley.edu
> for example and one for everything else but all traceroutes I run go through
> cenic.net. I've tried yahoo.com, berkeley.edu, msn.com, mit.edu, and others.
> Has Stanford changed their ISP setup or maybe the second ISP mentioned for
> Internet 2 traffic?


.

Path: shelby.stanford.edu!not-for-mail
From: Ben Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: calculating distance from RTT times
Date: Thu, 15 Feb 2007 22:29:02 -0800
Lines: 15
Distribution: su
Message-ID: <er3ivp$9va$1@news.Stanford.EDU>
References: <er3349$s6f$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171607353 10218 128.12.94.22 (16 Feb 2007 06:29:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
In-Reply-To: <er3349$s6f$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11689

That's what I did. Would like guidance from TAs as to whether we're 
allowed to use the RTT to estimate distance, as opposed to only using 
the # hops to estimate distance.

Ben

Jad Naous wrote:
> Hi,
> 
> Are we just supposed to do time * propagation speed through optical
> fiber. And time is just RTT/2? That doesn't take into account any delays
> through the routers.
> 
> Thanks,
> Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: calculating distance from RTT times
Date: Thu, 15 Feb 2007 23:42:07 -0800
Lines: 20
Distribution: su
Message-ID: <C1FAA04F.866D%jpettit@stanford.edu>
References: <er3349$s6f$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171611729 13121 127.0.0.1 (16 Feb 2007 07:42:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: calculating distance from RTT times
Thread-Index: AcdRnfVEM5ewTr2REdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11690

Yes, this is fine for the purposes of the question.  You can assume the
speed of light is 2.0 x 10^8 m/s.  Make sure to explain why this may or may
not be a good way of measuring the distance.

--Justin


On 2/15/07 5:58 PM, in article er3349$s6f$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> Hi,
> 
> Are we just supposed to do time * propagation speed through optical
> fiber. And time is just RTT/2? That doesn't take into account any delays
> through the routers.
> 
> Thanks,
> Jad.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2: Q 7(g)
Date: Thu, 15 Feb 2007 23:46:30 -0800
Lines: 30
Distribution: su
Message-ID: <C1FAA156.866F%jpettit@stanford.edu>
References: <eqt4t4$a5m$1@news.Stanford.EDU> <eqt6nl$bod$1@news.Stanford.EDU> <er356g$uk$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171612001 13777 127.0.0.1 (16 Feb 2007 07:46:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS2: Q 7(g)
Thread-Index: AcdRnpIH0KaVV72REdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11691

Not really.  Keep in mind that caching comes into play, so multiple runs
back-to-back (even from other students on the same box!) are going to wreak
havoc with your timing results.  If you can't get the second query to run
faster than the first, then just take a stab at describing why it would in
theory.

--Justin


On 2/15/07 6:34 PM, in article er356g$uk$1@news.Stanford.EDU, "Jad Naous"
<jnaous@stanford.edu> wrote:

> I'm getting a lot of drops every time I run traceroute, and and the
> delays are varying too much to be able to tell if it's just from DNS
> lookups. Is there a way around this?
> 
> Thanks,
> Jad.
> 
> Clay Collier wrote:
>> Take a look at man 1 time.
>> 
>> Clay
>> Riju Kallivalappil wrote:
>>> What are the commands in unix that'd give the time taken for a command
>>> like traceroute to complete? I tried using date and times. Saw no
>>> difference in the time taken for traceroute with and without '-n' option.
>>> 


.

Path: shelby.stanford.edu!myth4.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: calculating distance from RTT times
Date: Fri, 16 Feb 2007 01:41:20 -0800
Lines: 29
Distribution: su
Message-ID: <Pine.LNX.4.44.0702160139590.28675-100000@myth4.Stanford.EDU>
References: <er3349$s6f$1@news.Stanford.EDU> <C1FAA04F.866D%jpettit@stanford.edu>
NNTP-Posting-Host: myth4.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171618882 21340 171.64.15.185 (16 Feb 2007 09:41:22 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <C1FAA04F.866D%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11692

I believe in class or in a handout or something it mentioned something
about optical fiber is only a faction of the speed of light, I am having
a tough time looking up this "percentage", does anyone have a pointer or
remember? Thanks.

On Thu, 15 Feb 2007, Justin Pettit wrote:

> Yes, this is fine for the purposes of the question.  You can assume the
> speed of light is 2.0 x 10^8 m/s.  Make sure to explain why this may or may
> not be a good way of measuring the distance.
>
> --Justin
>
>
> On 2/15/07 5:58 PM, in article er3349$s6f$1@news.Stanford.EDU, "Jad Naous"
> <jnaous@stanford.edu> wrote:
>
> > Hi,
> >
> > Are we just supposed to do time * propagation speed through optical
> > fiber. And time is just RTT/2? That doesn't take into account any delays
> > through the routers.
> >
> > Thanks,
> > Jad.
>
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: calculating distance from RTT times
Date: Fri, 16 Feb 2007 01:55:11 -0800
Lines: 43
Distribution: su
Message-ID: <C1FABF7F.8686%jpettit@stanford.edu>
References: <er3349$s6f$1@news.Stanford.EDU> <C1FAA04F.866D%jpettit@stanford.edu> <Pine.LNX.4.44.0702160139590.28675-100000@myth4.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171619712 21709 127.0.0.1 (16 Feb 2007 09:55:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: calculating distance from RTT times
Thread-Index: AcdRsIwayrHUjb2jEdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11693

I don't remember that, but I haven't been present for every second of
lecture.  Professor McKeown did mention that data travels over fiber optic
cables slightly slower than it does over electrical wires.  However, if
someone has better information, please share it!

--Justin


On 2/16/07 1:41 AM, in article
Pine.LNX.4.44.0702160139590.28675-100000@myth4.Stanford.EDU, "Ryan Chen"
<ryanchen@stanford.edu> wrote:

> I believe in class or in a handout or something it mentioned something
> about optical fiber is only a faction of the speed of light, I am having
> a tough time looking up this "percentage", does anyone have a pointer or
> remember? Thanks.
> 
> On Thu, 15 Feb 2007, Justin Pettit wrote:
> 
>> Yes, this is fine for the purposes of the question.  You can assume the
>> speed of light is 2.0 x 10^8 m/s.  Make sure to explain why this may or may
>> not be a good way of measuring the distance.
>> 
>> --Justin
>> 
>> 
>> On 2/15/07 5:58 PM, in article er3349$s6f$1@news.Stanford.EDU, "Jad Naous"
>> <jnaous@stanford.edu> wrote:
>> 
>>> Hi,
>>> 
>>> Are we just supposed to do time * propagation speed through optical
>>> fiber. And time is just RTT/2? That doesn't take into account any delays
>>> through the routers.
>>> 
>>> Thanks,
>>> Jad.
>> 
>> 
>> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: calculating distance from RTT times
Date: Fri, 16 Feb 2007 03:03:04 -0800
Lines: 48
Distribution: su
Message-ID: <er4318$ni8$1@news.Stanford.EDU>
References: <er3349$s6f$1@news.Stanford.EDU> <C1FAA04F.866D%jpettit@stanford.edu> <Pine.LNX.4.44.0702160139590.28675-100000@myth4.Stanford.EDU> <C1FABF7F.8686%jpettit@stanford.edu>
NNTP-Posting-Host: dnab423b0f.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171623784 24136 171.66.59.15 (16 Feb 2007 11:03:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
In-Reply-To: <C1FABF7F.8686%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11694

This may sound like a cheat, but there is a paper that discusses this 
issue. Here is a link:

http://arxiv.org/pdf/physics/0208087


Justin Pettit wrote:
> I don't remember that, but I haven't been present for every second of
> lecture.  Professor McKeown did mention that data travels over fiber optic
> cables slightly slower than it does over electrical wires.  However, if
> someone has better information, please share it!
> 
> --Justin
> 
> 
> On 2/16/07 1:41 AM, in article
> Pine.LNX.4.44.0702160139590.28675-100000@myth4.Stanford.EDU, "Ryan Chen"
> <ryanchen@stanford.edu> wrote:
> 
>> I believe in class or in a handout or something it mentioned something
>> about optical fiber is only a faction of the speed of light, I am having
>> a tough time looking up this "percentage", does anyone have a pointer or
>> remember? Thanks.
>>
>> On Thu, 15 Feb 2007, Justin Pettit wrote:
>>
>>> Yes, this is fine for the purposes of the question.  You can assume the
>>> speed of light is 2.0 x 10^8 m/s.  Make sure to explain why this may or may
>>> not be a good way of measuring the distance.
>>>
>>> --Justin
>>>
>>>
>>> On 2/15/07 5:58 PM, in article er3349$s6f$1@news.Stanford.EDU, "Jad Naous"
>>> <jnaous@stanford.edu> wrote:
>>>
>>>> Hi,
>>>>
>>>> Are we just supposed to do time * propagation speed through optical
>>>> fiber. And time is just RTT/2? That doesn't take into account any delays
>>>> through the routers.
>>>>
>>>> Thanks,
>>>> Jad.
>>>
>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2 Q 7 (d)
Date: Fri, 16 Feb 2007 04:17:14 -0800
Lines: 9
Distribution: su
Message-ID: <er47cb$s1o$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab423b0f.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171628235 28728 171.66.59.15 (16 Feb 2007 12:17:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11695

Hi,

I skimmed through chapter 7 and found about the CDNs, but it seems like 
the book describes it only in the context of large multimedia contents. 
Can it be the case for a host to designate its entire server to CDNs or 
am I just on the wrong track?

Thanks,
Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 10:46:26 -0800
Lines: 17
Distribution: su
Message-ID: <er4u2j$gh4$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171651476 16932 128.12.81.44 (16 Feb 2007 18:44:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11696

I can't find it either...

-- 


David Gobaud

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:equ0ru$7up$1@news.Stanford.EDU...
> I've looked through the command line options for traceroute, and I can't 
> find the one that suppresses RTT calculation for intermediate routers.
>
> Is there such an option? Am I just not looking hard enough?
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 10:51:42 -0800
Lines: 28
Distribution: su
Message-ID: <er4ucf$gs3$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU> <er4u2j$gh4$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171651791 17283 128.12.81.44 (16 Feb 2007 18:49:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11697

Heh I actually I figured it out.That is tricky :)

-- 


David Gobaud

"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:er4u2j$gh4$1@news.Stanford.EDU...
>I can't find it either...
>
> -- 
>
>
> David Gobaud
>
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:equ0ru$7up$1@news.Stanford.EDU...
>> I've looked through the command line options for traceroute, and I can't 
>> find the one that suppresses RTT calculation for intermediate routers.
>>
>> Is there such an option? Am I just not looking hard enough?
>>
>> -Yangfan
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 10:54:11 -0800
Lines: 39
Distribution: su
Message-ID: <er4uh4$h3a$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU> <er4u2j$gh4$1@news.Stanford.EDU> <er4ucf$gs3$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171651940 17514 128.12.81.44 (16 Feb 2007 18:52:20 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11698

Actually I was wrong. I still don't see how to do it...

-- 


David Gobaud

"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:er4ucf$gs3$1@news.Stanford.EDU...
> Heh I actually I figured it out.That is tricky :)
>
> -- 
>
>
> David Gobaud
>
> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
> news:er4u2j$gh4$1@news.Stanford.EDU...
>>I can't find it either...
>>
>> -- 
>>
>>
>> David Gobaud
>>
>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>> news:equ0ru$7up$1@news.Stanford.EDU...
>>> I've looked through the command line options for traceroute, and I can't 
>>> find the one that suppresses RTT calculation for intermediate routers.
>>>
>>> Is there such an option? Am I just not looking hard enough?
>>>
>>> -Yangfan
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA3&4, where's the source?  (and a few of other questions)
Date: Fri, 16 Feb 2007 12:01:57 -0800
Lines: 54
Distribution: su
Message-ID: <er52i2$k7l$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171656066 20725 127.0.0.1 (16 Feb 2007 20:01:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11699

Regarding PA3:
Q1: Where is the source code?
I got an old version before the web page was updated, but I want to make 
sure I have the latest code...  Old code should be able to hold me over for 
a little bit, though.  (In connection with this, what is the ftpd_tcp.debug 
file in the source directory?  Was that supposed to give us (if we were 
doing the ftp assignment) enough info for a bt in gdb?)

Q2: (Just making sure) For PA3.c milestone, is there no penalty for using 
the reference web proxy?  Where can I find it?
I used select for my base implementation, and my code is tied tightly to 
some assumptions I can make based off of the select model, and I have _no_ 
desire to write a less-useful proxy and handle corner cases that did not 
happen because I used select.  The assignment was somewhat vague about what 
it means to fulfill part c with the reference proxy, or what the penalty 
was.

Q3: From the Retransmissions part:
"If the timeout for a segment is reached, the segment is examined. If it has 
been sent a total of 6 times (once from the original send plus 5 
retransmissions), then the network is assumed to have failed and the network 
terminated."
Is this supposed to say, "... connection terminated"?  As I understand from 
below, this just means our function returns.

Q4: The FAQ says we do not have to deal with error checking the checksum. 
Does that mean it was verified before it was passed to us?  Sending an ACK 
for a TCP packet with a bad checksum seems unwise.

From PA4:
Q5: There are still many references to the FTP server of last year.  While 
in most places, I can see where the web proxy fits in, this is a 
particularly obtuse part:
" Secondly, if you used the PORT method for establishing a communication 
path with the server, you may need to change the method in which you get the 
local IP address. The easiest way to do this is to use the method uint32_t 
mylocalip(uint32_t peer_addr) which is defined in the library we provide. 
This is a MUST if you are using gethostbyname() on the hostname to get the 
local IP address. Getting the local IP address is problematic because your 
"host" is really a user space application running on a real host (e.g. one 
of the elaines) therefore, gethostbyname(gethostname()) consequently will 
return the IP of the local host and not the IP of the virtual host in the 
VNS."

AIR, PORT is an FTP command, and has no analogy to the web proxy.  We do use 
gethostbyname(), but it seems like that should not be a problem because we 
are never getting our own host IpAddr?

TIA,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3&4, where's the source?  (and a few of other questions)
Date: Fri, 16 Feb 2007 12:39:22 -0800
Lines: 19
Distribution: su
Message-ID: <er54o7$lro$1@news.Stanford.EDU>
References: <er52i2$k7l$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171658311 22392 127.0.0.1 (16 Feb 2007 20:38:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11700

For instance, I would be interested in code that did not bail on cygwin.  I 
can _probably_ provide corrected code, if they have not been done yet, and 
there is an interest.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:er52i2$k7l$1@news.Stanford.EDU...
> Regarding PA3:
> Q1: Where is the source code?
> I got an old version before the web page was updated, but I want to make 
> sure I have the latest code...  Old code should be able to hold me over 
> for a little bit, though.  (In connection with this, what is the 
> ftpd_tcp.debug file in the source directory?  Was that supposed to give us 
> (if we were doing the ftp assignment) enough info for a bt in gdb?)


.

Path: shelby.stanford.edu!myth25.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Parking for Remote students
Date: Fri, 16 Feb 2007 17:21:01 -0800
Lines: 10
Distribution: su
Message-ID: <Pine.LNX.4.44.0702161719050.1354-100000@myth25.Stanford.EDU>
NNTP-Posting-Host: myth25.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171675263 4990 171.64.15.40 (17 Feb 2007 01:21:03 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11701

Hi,

I was wondering if any one of you have some insight on where the remote
students coming to campus for the midterm can park without too much
trouble.


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 18:20:13 -0800
Lines: 53
Distribution: su
Message-ID: <er5ol4$6uo$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU> <er4u2j$gh4$1@news.Stanford.EDU> <er4ucf$gs3$1@news.Stanford.EDU> <er4uh4$h3a$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171678692 7128 128.12.81.44 (17 Feb 2007 02:18:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11702

haha

-i initial_ttl
I saw initial_ttl and din't read the rest of it... thinking it just set the 
initial TTL on the outgoing packets.

-- 
David Gobaud

"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:er4uh4$h3a$1@news.Stanford.EDU...
> Actually I was wrong. I still don't see how to do it...
>
> -- 
>
>
> David Gobaud
>
> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
> news:er4ucf$gs3$1@news.Stanford.EDU...
>> Heh I actually I figured it out.That is tricky :)
>>
>> -- 
>>
>>
>> David Gobaud
>>
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:er4u2j$gh4$1@news.Stanford.EDU...
>>>I can't find it either...
>>>
>>> -- 
>>>
>>>
>>> David Gobaud
>>>
>>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>>> news:equ0ru$7up$1@news.Stanford.EDU...
>>>> I've looked through the command line options for traceroute, and I 
>>>> can't find the one that suppresses RTT calculation for intermediate 
>>>> routers.
>>>>
>>>> Is there such an option? Am I just not looking hard enough?
>>>>
>>>> -Yangfan
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 18:25:00 -0800
Lines: 62
Distribution: su
Message-ID: <er5ou3$75r$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU> <er4u2j$gh4$1@news.Stanford.EDU> <er4ucf$gs3$1@news.Stanford.EDU> <er4uh4$h3a$1@news.Stanford.EDU> <er5ol4$6uo$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1171678979 7355 128.12.81.44 (17 Feb 2007 02:22:59 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11703

Oh boy and now I realize that is what it does...

-- 
David Gobaud

"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:er5ol4$6uo$1@news.Stanford.EDU...
> haha
>
> -i initial_ttl
> I saw initial_ttl and din't read the rest of it... thinking it just set 
> the initial TTL on the outgoing packets.
>
> -- 
> David Gobaud
>
> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
> news:er4uh4$h3a$1@news.Stanford.EDU...
>> Actually I was wrong. I still don't see how to do it...
>>
>> -- 
>>
>>
>> David Gobaud
>>
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:er4ucf$gs3$1@news.Stanford.EDU...
>>> Heh I actually I figured it out.That is tricky :)
>>>
>>> -- 
>>>
>>>
>>> David Gobaud
>>>
>>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>>> news:er4u2j$gh4$1@news.Stanford.EDU...
>>>>I can't find it either...
>>>>
>>>> -- 
>>>>
>>>>
>>>> David Gobaud
>>>>
>>>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>>>> news:equ0ru$7up$1@news.Stanford.EDU...
>>>>> I've looked through the command line options for traceroute, and I 
>>>>> can't find the one that suppresses RTT calculation for intermediate 
>>>>> routers.
>>>>>
>>>>> Is there such an option? Am I just not looking hard enough?
>>>>>
>>>>> -Yangfan
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Jin Wang" <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: starting PA 3?
Date: Fri, 16 Feb 2007 23:59:39 -0500
Lines: 7
Distribution: su
Message-ID: <er626u$c72$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171688479 12514 127.0.0.1 (17 Feb 2007 05:01:19 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Xref: shelby.stanford.edu su.class.cs244a:11704

Is it recommended that we start Programming Assignment 3 now?  Or should we
hold off until a new revision of the code has been posted?

Thanks,
Jin


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problem Set 2 question 8
Date: Fri, 16 Feb 2007 21:35:41 -0800
Lines: 11
Distribution: su
Message-ID: <er6476$d54$1@news.Stanford.EDU>
References: <equ0ru$7up$1@news.Stanford.EDU> <er4u2j$gh4$1@news.Stanford.EDU> <er4ucf$gs3$1@news.Stanford.EDU> <er4uh4$h3a$1@news.Stanford.EDU> <er5ol4$6uo$1@news.Stanford.EDU> <er5ou3$75r$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171690535 13476 128.12.194.72 (17 Feb 2007 05:35:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <er5ou3$75r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11705

Yeah. I had to read the documentation *very carefully*. I guess it 
serves us right to skim our readings, you know, like normal college 
students...

Yeah, I don't know where I'm going with this. :p

-Yangfan

David Gobaud wrote:
> Oh boy and now I realize that is what it does...
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Stanford has 2 internet providers?
Date: Fri, 16 Feb 2007 21:38:24 -0800
Lines: 53
Distribution: su
Message-ID: <er64ca$d54$2@news.Stanford.EDU>
References: <er3go6$8lj$1@news.Stanford.EDU> <C1FA89DE.8664%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171690698 13476 128.12.194.72 (17 Feb 2007 05:38:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C1FA89DE.8664%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11706

Okay, now that's just totaly confusing. We have academic traffic going 
over Cogentco.com. :)

-Yangfan

Justin Pettit wrote:
> Aim a little lower.  ;)  You can try my alma mater:
> 
> elaine25> traceroute www.scu.edu
> traceroute to www.scu.edu (129.210.2.1): 1-30 hops, 38 byte packets
>  1  Gates-rtr.Stanford.EDU (171.64.15.65)  0.673 ms  0.441 ms  0.481 ms
>  2  bbra-rtr.Stanford.EDU (171.64.1.52)  1.02 ms  0.866 ms  0.817 ms
>  3  border3-rtr.Stanford.EDU (171.64.1.149)  0.856 ms  0.821 ms  0.564 ms
>  4  g1.ba21.b003123-1.sfo01.atlas.cogentco.com (66.250.7.137)  1.36 ms  1.87
> ms  1.43 ms
>  5  p9-0.core02.sfo01.atlas.cogentco.com (66.28.4.233)  3.75 ms  4.20 ms
> 2.27 ms
>  6  t3-3.mpd01.sfo01.atlas.cogentco.com (154.54.3.118)  2.75 ms  2.53 ms
> 1.93 ms
>  7  t2-2.mpd01.sjc01.atlas.cogentco.com (154.54.1.26)  3.28 ms  4.27 ms
> 5.08 ms
>  8  v3490.mpd01.sjc03.atlas.cogentco.com (154.54.6.82)  3.81 ms  3.50 ms
> 3.94 ms
>  9  g0-0-0.core01.sjc03.atlas.cogentco.com (154.54.6.117)  3.89 ms  4.15 ms
> 5.85 ms
> 10  uunet.sjc03.atlas.cogentco.com (154.54.13.114)  6.25 ms  4.02 ms  5.49
> ms
> 11  0.so-0-1-0.XL2.SCL2.ALTER.NET (152.63.56.250)  4.20 ms (ttl=244!)  4.25
> ms (ttl=244!)  5.05 ms (ttl=244!)
> 12  0.so-7-0-0.GW2.SCL2.ALTER.NET (152.63.57.1)  4.19 ms (ttl=243!)  4.86 ms
> (ttl=243!)  3.97 ms (ttl=243!)
> 13  scu-gw.customer.alter.net (157.130.193.62)  10.3 ms (ttl=241!)  8.64 ms
> (ttl=241!)  8.87 ms (ttl=241!)
> 14  *  *  *
> 
> --Justin
> 
> 
> On 2/15/07 9:50 PM, in article er3go6$8lj$1@news.Stanford.EDU, "David
> Gobaud" <gobaudd@stanford.edu> wrote:
> 
> 
>>Hi,
>>
>>In class a while ago I think Professor McKeown mentioned that Stanford has
>>two seperate internet providers - one for academic access to berkeley.edu
>>for example and one for everything else but all traceroutes I run go through
>>cenic.net. I've tried yahoo.com, berkeley.edu, msn.com, mit.edu, and others.
>>Has Stanford changed their ISP setup or maybe the second ISP mentioned for
>>Internet 2 traffic?
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Stanford has 2 internet providers?
Date: Fri, 16 Feb 2007 22:45:59 -0800
Lines: 9
Distribution: su
Message-ID: <er68b6$fe4$1@news.Stanford.EDU>
References: <er3go6$8lj$1@news.Stanford.EDU> <C1FA89DE.8664%jpettit@stanford.edu> <er64ca$d54$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171694758 15812 127.0.0.1 (17 Feb 2007 06:45:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <er64ca$d54$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11707

Yangfan Wang wrote:
> Okay, now that's just totaly confusing. We have academic traffic going 
> over Cogentco.com. :)
> 
> -Yangfan

They likely aren't hooked up on I2.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Parking for Remote students
Date: Sat, 17 Feb 2007 00:09:15 -0800
Lines: 26
Distribution: su
Message-ID: <C1FBF82B.87A6%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0702161719050.1354-100000@myth25.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171699760 21960 127.0.0.1 (17 Feb 2007 08:09:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Parking for Remote students
Thread-Index: AcdSauoLKNxFaL5eEdu1rQARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11708

I'd recommend the metered parking in the lower level of the lot called
"Parking Struct 1" in spot E-7 of the following map:

    http://transportation.stanford.edu/images/06-07_Parking-Map.pdf

Bring lots of quarters, since it costs $1.50 per hour.

--Justin


On 2/16/07 5:21 PM, in article
Pine.LNX.4.44.0702161719050.1354-100000@myth25.Stanford.EDU, "Seung Hoon
Choi" <shchoi@stanford.edu> wrote:

> Hi,
> 
> I was wondering if any one of you have some insight on where the remote
> students coming to campus for the midterm can park without too much
> trouble.
> 
> 
> Thanks,
> -Seung
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PS2 sol q6
Date: Sat, 17 Feb 2007 18:17:10 +0000 (UTC)
Lines: 8
Distribution: su
Message-ID: <er7gr6$hjk$1@news.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
X-Trace: news.Stanford.EDU 1171736230 18036 171.64.15.38 (17 Feb 2007 18:17:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11709

Hi,

Question asked for min dist from R8 but solution has min dist from R7.
Also direct path from R7 to R2 is 13 not 4 as mentioned in solution.
Please explain.

Thanks,
Dinesh
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2 sol q6
Date: Sat, 17 Feb 2007 11:17:12 -0800
Lines: 12
Distribution: su
Message-ID: <C1FC94B8.87C5%jpettit@stanford.edu>
References: <er7gr6$hjk$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171739838 20372 127.0.0.1 (17 Feb 2007 19:17:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS2 sol q6
Thread-Index: AcdSyDnMeCj47767EduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11710

> Question asked for min dist from R8 but solution has min dist from R7.

Your are correct that it is supposed to be R8.  We'll get an updated
solution out today.  Sorry about that.

> Also direct path from R7 to R2 is 13 not 4 as mentioned in solution.

I think this is correct in the solution.  You want to go from R2 to R7,
which is 4, right?

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Past exams
Date: Sat, 17 Feb 2007 12:05:31 -0800
Lines: 6
Distribution: su
Message-ID: <er7n30$lcp$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171742624 21913 128.12.134.140 (17 Feb 2007 20:03:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11711

Hi,

Are there any poast exams somewhere? Where do we find them?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Past exams
Date: Sat, 17 Feb 2007 12:08:48 -0800
Lines: 11
Distribution: su
Message-ID: <er7nce$lh1$1@news.Stanford.EDU>
References: <er7n30$lcp$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171742926 22049 127.0.0.1 (17 Feb 2007 20:08:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <er7n30$lcp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11712

Jad Naous wrote:
> Hi,
> 
> Are there any poast exams somewhere? Where do we find them?
> 
> Thanks,
> Jad.

Check the link off the front page in announcements, it has last years.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: PS2 sol q6
Date: Sat, 17 Feb 2007 23:26:57 +0000 (UTC)
Lines: 23
Distribution: su
Message-ID: <er8301$sgm$1@news.Stanford.EDU>
References: <er7gr6$hjk$1@news.Stanford.EDU> <C1FC94B8.87C5%jpettit@stanford.edu>
NNTP-Posting-Host: myth25.stanford.edu
X-Trace: news.Stanford.EDU 1171754817 29206 171.64.15.40 (17 Feb 2007 23:26:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11713

Justin Pettit <jpettit@stanford.edu> wrote:
> > Question asked for min dist from R8 but solution has min dist from R7.

> Your are correct that it is supposed to be R8.  We'll get an updated
> solution out today.  Sorry about that.

No problem.
> > Also direct path from R7 to R2 is 13 not 4 as mentioned in solution.

> I think this is correct in the solution.  You want to go from R2 to R7,
> which is 4, right?

But not in the first iteration.

> --Justin

Also for question 7(d), It was asking if number of hops is a good
criteria in terms of estimating distance why the solution talks about
RTT ?

Thanks,
Dinesh

.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: REPOST: When to start PA3 ?
Date: Sat, 17 Feb 2007 19:29:20 -0500
Lines: 5
Distribution: su
Message-ID: <er86nt$1bt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171758653 1405 127.0.0.1 (18 Feb 2007 00:30:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:11714

Is it recommended that we start Programming Assignment 3 now?  Or should 
we hold off until a new revision of the code has been posted?

Thanks,
Jin
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: REPOST: When to start PA3 ?
Date: Sat, 17 Feb 2007 17:58:09 -0800
Lines: 16
Distribution: su
Message-ID: <C1FCF2B1.87F0%jpettit@stanford.edu>
References: <er86nt$1bt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171763889 5029 127.0.0.1 (18 Feb 2007 01:58:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: REPOST: When to start PA3 ?
Thread-Index: AcdTADzje6AdoL7zEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11715

Don't bother reposting unless it's been more than 24 hours during the week
or 48 hours on the weekend.

--Justin


On 2/17/07 4:29 PM, in article er86nt$1bt$1@news.Stanford.EDU, "Jin Wang"
<jinwang@stanford.edu> wrote:

> Is it recommended that we start Programming Assignment 3 now?  Or should
> we hold off until a new revision of the code has been posted?
> 
> Thanks,
> Jin


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3&4, where's the source?  (and a few of other questions)
Date: Sat, 17 Feb 2007 18:28:22 -0800
Lines: 64
Distribution: su
Message-ID: <C1FCF9C6.87F3%jpettit@stanford.edu>
References: <er52i2$k7l$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171765705 6119 127.0.0.1 (18 Feb 2007 02:28:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA3&4, where's the source?  (and a few of other questions)
Thread-Index: AcdTBHWFs9OTiL73EduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11716

> Regarding PA3:
> Q1: Where is the source code?
> I got an old version before the web page was updated, but I want to make
> sure I have the latest code...  Old code should be able to hold me over for
> a little bit, though.  (In connection with this, what is the ftpd_tcp.debug
> file in the source directory?  Was that supposed to give us (if we were
> doing the ftp assignment) enough info for a bt in gdb?)

This was the tarball from last year's PA3 assignment.  We'll post a new one
tomorrow that contains almost everything.  We still need to get our STCP
wget application and the reference web proxy ready.  Those will be available
by midweek.

> Q2: (Just making sure) For PA3.c milestone, is there no penalty for using
> the reference web proxy?  Where can I find it?

No, there's no penalty.  Keep in mind that you will be stuck with the
reference implentation for PA4, which means you can't swap out any other
pieces without a penalty.  As mentioned above, that will be available
midweek.

> Q3: From the Retransmissions part:
> "If the timeout for a segment is reached, the segment is examined. If it has
> been sent a total of 6 times (once from the original send plus 5
> retransmissions), then the network is assumed to have failed and the network
> terminated."
> Is this supposed to say, "... connection terminated"?  As I understand from
> below, this just means our function returns.

Yes, your suggestion makes more sense.  Just kill the connection that is
experiencing the problem.

> Q4: The FAQ says we do not have to deal with error checking the checksum.
> Does that mean it was verified before it was passed to us?  Sending an ACK
> for a TCP packet with a bad checksum seems unwise.

The underlying transport that carries your traffic is TCP, so the traffic
shouldn't have any errors.  However, you can feel free to check the checksum
if you like!  Make sure you generate a valid checksum, though.

> From PA4:
> Q5: There are still many references to the FTP server of last year.  While
> in most places, I can see where the web proxy fits in, this is a
> particularly obtuse part:
> " Secondly, if you used the PORT method for establishing a communication
> path with the server, you may need to change the method in which you get the
> local IP address. The easiest way to do this is to use the method uint32_t
> mylocalip(uint32_t peer_addr) which is defined in the library we provide.
> This is a MUST if you are using gethostbyname() on the hostname to get the
> local IP address. Getting the local IP address is problematic because your
> "host" is really a user space application running on a real host (e.g. one
> of the elaines) therefore, gethostbyname(gethostname()) consequently will
> return the IP of the local host and not the IP of the virtual host in the
> VNS."
>
> AIR, PORT is an FTP command, and has no analogy to the web proxy.  We do use
> gethostbyname(), but it seems like that should not be a problem because we
> are never getting our own host IpAddr?

I don't think you need to worry about this.  Obviously, we need to clean up
the description for PA4.  We'll have that done this week.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: starting PA 3?
Date: Sat, 17 Feb 2007 18:47:23 -0800
Lines: 18
Distribution: su
Message-ID: <C1FCFE3B.87F7%jpettit@stanford.edu>
References: <er626u$c72$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171766842 6812 127.0.0.1 (18 Feb 2007 02:47:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: starting PA 3?
Thread-Index: AcdTBx2cW+R5Rr76EduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11717

We'll post new, better behaving code tomorrow.  I'll send out an update to
the newsgroup once it's been posted.

--Justin


On 2/16/07 8:59 PM, in article er626u$c72$1@news.Stanford.EDU, "Jin Wang"
<jinwang@stanford.edu> wrote:

> Is it recommended that we start Programming Assignment 3 now?  Or should we
> hold off until a new revision of the code has been posted?
> 
> Thanks,
> Jin
> 
> 


.

Path: shelby.stanford.edu!myth22.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Exact coverage of the midterm.
Date: Sat, 17 Feb 2007 18:57:34 -0800
Lines: 9
Distribution: su
Message-ID: <Pine.LNX.4.44.0702171857001.4989-100000@myth22.Stanford.EDU>
NNTP-Posting-Host: myth22.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1171767456 7170 171.64.15.36 (18 Feb 2007 02:57:36 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:11718


Hi,

what's the coverage of the midterm?


Thanks,
-Seung

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2 sol q6
Date: Sat, 17 Feb 2007 23:28:25 -0800
Lines: 72
Distribution: su
Message-ID: <C1FD4019.87FE%jpettit@stanford.edu>
References: <er7gr6$hjk$1@news.Stanford.EDU> <C1FC94B8.87C5%jpettit@stanford.edu> <er8301$sgm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1171783709 16387 127.0.0.1 (18 Feb 2007 07:28:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS2 sol q6
Thread-Index: AcdTLmAlntCQdL8hEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11719

>>> Question asked for min dist from R8 but solution has min dist from R7.
> 
>> Your are correct that it is supposed to be R8.  We'll get an updated
>> solution out today.  Sorry about that.
> 
> No problem.

Okay, so the correct solution looks like the following:
 
  Time:   0   1   2   3   4   5   6
  R1   ~   4, R3   4, R3   4, R3   4, R3   4, R3   4, R3
  R2   ~   5, R5   5, R5   5, R5   5, R5   5, R5   5, R5
  R3   1, R3   1, R3   1, R3   1, R3   1, R3   1, R3   1, R3
  R4   ~   ~   4, R7   4, R7   4, R7   4, R7   4, R7
  R5   1, R5   1, R5   1, R5   1, R5   1, R5   1, R5   1, R5
  R6   ~   3, R3   3, R3   3, R3   3, R3   3, R3   3, R3
  R7   ~   3, R3   3, R3   3, R3   3, R3   3, R3   3, R3

An updated problem set has been posted, which has this in a proper table.
It's much easier to read.

>>> Also direct path from R7 to R2 is 13 not 4 as mentioned in solution.
> 
>> I think this is correct in the solution.  You want to go from R2 to R7,
>> which is 4, right?
> 
> But not in the first iteration.

Sorry, I was looking at PA2 from last year when I wrote down "4".  Given
this year's graph, the traffic will have a weight of 3 from R2 to R7.  It is
13 going to R2 from R7.  We want the reverse.

> Also for question 7(d), It was asking if number of hops is a good
> criteria in terms of estimating distance why the solution talks about
> RTT ?

Sorry, a portion got chopped out.  Here's the way the text should have
looked:

---------------------
There are 21 hops with an average RTT of 178ms.  A very naive way to measure
the distance would be to do it entirely based on hop count.  There are nine
hops from the Myths to Foothill College, which is roughly five miles away.
This equates to around two hops for every mile.  Applying this math to the
University College London (21 hops) would yield a distance of about 10
miles.  Obviously the number of hops has almost zero correlation to distance
because there are no standards on router placement.  A better measure would
be to use the speed of light and the RTT time to calculate distance.
 
A possible way to measure the distance is to use the speed of light and the
RTT time to calculate distance.  An RTT of 154 ms means that the time it
takes for one direction is 178/2 = 89 ms.  The speed of light in a fiber
optic cable (making the assumption that most of the time the data is
traveling through fiber) is 2.0 x 108 m/s:
 
2.0 x 108 m/s * 89 x 10-3 s = 17800000/ 1600 meters in a mile = 11,125 miles
 
This is a rather poor way to measure geographic distance because it assumes
that the packet spends 0 time queued in the router.  Any delay spent in the
router is interpreted as extra distance traveled and due to the fact that
light is so fast, even a few milliseconds of delay can invalidate the
results.  Also, this assumes that the path in the Internet is a
straight-line distance between two points (which it obviously isn¹t).
---------------------

This is also in the updated version of the solution set.

I've put the date of the update in the top of the first page to help
distinguish it from the original one.  Sorry about the problems, everyone!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS2 sol q6
Date: Sat, 17 Feb 2007 23:29:51 -0800
Lines: 7
Distribution: su
Message-ID: <C1FD406F.8800%jpettit@stanford.edu>
References: <er7gr6$hjk$1@news.Stanford.EDU> <C1FC94B8.87C5%jpettit@stanford.edu> <er8301$sgm$1@news.Stanford.EDU> <C1FD4019.87FE%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171783795 16446 127.0.0.1 (18 Feb 2007 07:29:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS2 sol q6
Thread-Index: AcdTLmAlntCQdL8hEduDtgARJDbi7gAADNCA
Xref: shelby.stanford.edu su.class.cs244a:11720

> An updated problem set has been posted, which has this in a proper table.
> It's much easier to read.

That should read an "updated solution set has been posted."

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Next Hop in Bellman-Ford
Date: Sat, 17 Feb 2007 23:38:48 -0800
Lines: 9
Distribution: su
Message-ID: <C1FD4288.8805%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171784330 16778 127.0.0.1 (18 Feb 2007 07:38:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Next Hop in Bellman-Ford
Thread-Index: AcdTL9N7EcsIzb8jEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11721

I was asked whether the next hop should be written in the table when working
through the Bellman-Ford algorithm like it was in the solution set.  You are
not required to do this.  It was done just to make it clearer for you to
read.  However, it's probably not a bad idea to do that if you have time on
the midterm, since if you make a mistake, it'll be easier to give you
partial credit if we know where it went wrong.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: starting PA 3?
Date: Sun, 18 Feb 2007 13:07:23 -0800
Lines: 25
Distribution: su
Message-ID: <eraf6f$naa$1@news.Stanford.EDU>
References: <er626u$c72$1@news.Stanford.EDU> <C1FCFE3B.87F7%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1171832847 23882 127.0.0.1 (18 Feb 2007 21:07:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11722

Does this mean that the assignment submission deadlines will change :)

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1FCFE3B.87F7%jpettit@stanford.edu...
> We'll post new, better behaving code tomorrow.  I'll send out an update to
> the newsgroup once it's been posted.
>
> --Justin
>
>
> On 2/16/07 8:59 PM, in article er626u$c72$1@news.Stanford.EDU, "Jin Wang"
> <jinwang@stanford.edu> wrote:
>
>> Is it recommended that we start Programming Assignment 3 now?  Or should 
>> we
>> hold off until a new revision of the code has been posted?
>>
>> Thanks,
>> Jin
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS2: Q1 (b)
Date: Sun, 18 Feb 2007 16:26:10 -0800
Lines: 4
Distribution: su
Message-ID: <eraqr4$3pa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171844772 3882 127.0.0.1 (19 Feb 2007 00:26:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11723

In the solution posted, the netmask for 171.64.1.134 and 191.64.1.131 is 
given as FF.FF.FF.F0. I think this should be FF.FF.FF.F8 instead. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Q1 (b)
Date: Sun, 18 Feb 2007 16:27:05 -0800
Lines: 9
Distribution: su
Message-ID: <eraqst$3qe$1@news.Stanford.EDU>
References: <eraqr4$3pa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171844829 3918 127.0.0.1 (19 Feb 2007 00:27:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11724

I meant 171.64.1.134 and 171.64.1.131...

"Riju Kallivalappil" <riju@stanford.edu> wrote in message 
news:eraqr4$3pa$1@news.Stanford.EDU...
> In the solution posted, the netmask for 171.64.1.134 and 191.64.1.131 is 
> given as FF.FF.FF.F0. I think this should be FF.FF.FF.F8 instead.
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: question about last year's midterm
Date: Sun, 18 Feb 2007 22:23:55 -0800
Lines: 8
Distribution: su
Message-ID: <erbfps$joe$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171866236 20238 128.12.194.72 (19 Feb 2007 06:23:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11725

In the solutions to last year's midterm, it is mentioned that in problem 
      16)d)ii that a RST packet is 60 bytes long. Considering that both 
a TCP packet header and an IP packet header are 20 bytes each, wouldn't 
40 bytes be sufficient? Or if we're taking into account the packet 
header at the link level, isn't that dependent on what link layer 
protocol we use?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA3 Starter Code Posted
Date: Mon, 19 Feb 2007 01:02:32 -0800
Lines: 13
Distribution: su
Message-ID: <C1FEA7A8.883D%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171875765 755 127.0.0.1 (19 Feb 2007 09:02:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA3 Starter Code Posted
Thread-Index: AcdUBLBu7reimr/3EduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11726

The starter code for PA3 has been posted and linked to on the assignment
page.  Here's a direct link to it:

    http://www.stanford.edu/class/cs244a/hw3/pa3.tar.gz

We're sorry about the delay, but there were a few issues porting the code
from the Elaines to the Myths.  We are still working on an STCP version of
wget and a reference version of the web proxy.  You won't need those until
the third part of the assignment, but we'll get them to you this week.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Ray <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 Starter Code Posted
Date: Mon, 19 Feb 2007 01:17:57 -0800
Lines: 17
Distribution: su
Message-ID: <erbq06$1ch$1@news.Stanford.EDU>
References: <C1FEA7A8.883D%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171876678 1425 127.0.0.1 (19 Feb 2007 09:17:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <C1FEA7A8.883D%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11727

I'm getting a "Page not found" error when attempting to d/l this file...  any 
ideas what's going on?

Justin Pettit wrote:
> The starter code for PA3 has been posted and linked to on the assignment
> page.  Here's a direct link to it:
> 
>     http://www.stanford.edu/class/cs244a/hw3/pa3.tar.gz
> 
> We're sorry about the delay, but there were a few issues porting the code
> from the Elaines to the Myths.  We are still working on an STCP version of
> wget and a reference version of the web proxy.  You won't need those until
> the third part of the assignment, but we'll get them to you this week.
> 
> --Justin
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 Starter Code Posted
Date: Mon, 19 Feb 2007 03:18:23 -0800
Lines: 24
Distribution: su
Message-ID: <erc124$6dq$1@news.Stanford.EDU>
References: <C1FEA7A8.883D%jpettit@stanford.edu> <erbq06$1ch$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171883908 6586 128.12.133.106 (19 Feb 2007 11:18:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erbq06$1ch$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11728

Sorry about that.

http://www.stanford.edu/class/cs244a/hw3/pa3.tgz

Ray wrote:
> I'm getting a "Page not found" error when attempting to d/l this 
> file...  any ideas what's going on?
> 
> Justin Pettit wrote:
>> The starter code for PA3 has been posted and linked to on the assignment
>> page.  Here's a direct link to it:
>>
>>     http://www.stanford.edu/class/cs244a/hw3/pa3.tar.gz
>>
>> We're sorry about the delay, but there were a few issues porting the code
>> from the Elaines to the Myths.  We are still working on an STCP 
>> version of
>> wget and a reference version of the web proxy.  You won't need those 
>> until
>> the third part of the assignment, but we'll get them to you this week.
>>
>> --Justin
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: HW2, 7e,8a solution; just curious
Date: Mon, 19 Feb 2007 15:50:44 -0800
Lines: 31
Distribution: su
Message-ID: <erdehp$d4q$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1171930489 13466 127.0.0.1 (20 Feb 2007 00:14:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11729

//7e----------------------------------
I see now that the first line of the traceroute output was:
traceroute to a1289.g.akamai.net (198.189.255.81): 1-30 hops, 38 byte 
packets

However, the last line was:
8 198.189.255.81 (198.189.255.81) 3.82 ms (ttl=58!) 3.86 ms (ttl=58!) 3.61 
ms (ttl=58!)

Any ideas why the DNS name was not filled in at the end?

//8a-----------------------------------------------

The solution used:

traceroute -i 20 -c 1 q 100 www.mit.edu

From a previous question, we know that www.mit.edu is 19 hops away. 
Certainly '-i 20' will work, but why use more than '-i 19'?  (Interestingly, 
I had a steady delay of about 3ms less than the solution set, but traceroute 
ended without going to another hop.)

Sincerely,

Randy Jennings



The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA3
Date: Tue, 20 Feb 2007 04:11:40 +0000 (UTC)
Organization: Your Company
Lines: 7
Distribution: su
Message-ID: <Xns98DCCD6E968F5chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1171944700 22924 128.12.22.217 (20 Feb 2007 04:11:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11730

Is milestone 1 graded? and is the deadline a hard deadline? In other words, 
if I submit something that doesn't work too well, can I change it for the 
final submission?

thanks,

chunkai
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: lelandquota
Date: Mon, 19 Feb 2007 22:41:30 -0800
Lines: 15
Distribution: su
Message-ID: <ere572$sj9$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1171953698 29289 171.64.75.59 (20 Feb 2007 06:41:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:11731


Dear TAs,

It seems like I did not get any disk space
for the course. I only have the default 200MB
in my leland account. I am officially taking this course.

I remember Yangfan posting about this before.
Could you please check if the students all got their
additional 500MB of disk space?

Thanks,
Steven


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3
Date: Mon, 19 Feb 2007 23:23:39 -0800
Lines: 13
Distribution: su
Message-ID: <ere7lm$sm$1@news.Stanford.EDU>
References: <Xns98DCCD6E968F5chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171956214 918 127.0.0.1 (20 Feb 2007 07:23:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98DCCD6E968F5chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11732

Chun Kai Wang wrote:
> Is milestone 1 graded? and is the deadline a hard deadline? In other words, 
> if I submit something that doesn't work too well, can I change it for the 
> final submission?
> 
> thanks,
> 
> chunkai

You can definitely change it for the final submission.  As to the 
question of it being graded or not, do you really want to risk it?

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: lelandquota
Date: Mon, 19 Feb 2007 23:25:18 -0800
Lines: 20
Distribution: su
Message-ID: <ere7op$sm$2@news.Stanford.EDU>
References: <ere572$sj9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171956313 918 127.0.0.1 (20 Feb 2007 07:25:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ere572$sj9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11733

Euijong Whang wrote:
> Dear TAs,
> 
> It seems like I did not get any disk space
> for the course. I only have the default 200MB
> in my leland account. I am officially taking this course.
> 
> I remember Yangfan posting about this before.
> Could you please check if the students all got their
> additional 500MB of disk space?
> 
> Thanks,
> Steven
> 
> 

I believe we emailed them about this but have not heard anything back, 
its a general problem.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW2, 7e,8a solution; just curious
Date: Tue, 20 Feb 2007 00:15:26 -0800
Lines: 49
Distribution: su
Message-ID: <C1FFEE1E.8874%jpettit@stanford.edu>
References: <erdehp$d4q$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171959330 6324 127.0.0.1 (20 Feb 2007 08:15:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: HW2, 7e,8a solution; just curious
Thread-Index: AcdUx0ZrhL8ECsC6EduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11734

> //7e----------------------------------
> I see now that the first line of the traceroute output was:
> traceroute to a1289.g.akamai.net (198.189.255.81): 1-30 hops, 38 byte
> packets
> 
> However, the last line was:
> 8 198.189.255.81 (198.189.255.81) 3.82 ms (ttl=58!) 3.86 ms (ttl=58!) 3.61
> ms (ttl=58!)
> 
> Any ideas why the DNS name was not filled in at the end?
 
Well, the obvious answer is that there isn't a reverse DNS entry.  But I
don't think you that's the answer you were looking for.  ;)  Akamai uses the
web server at that address to host many web sites.  If you connect there and
do an HTTP/1.0 request, it will tell you that it is an invalid request.  If
you connect there and do an HTTP/1.1 request with "Host:
www.whitehouse.gov", you'll get the White House's web site.  If you connect
and do an HTTP/1.1 request with "Host: www.apple.com", you'll get an Apple
page.  You can try for yourself and see.  So, the reverse DNS entry can't
contain the name of the site, since it maps to many hosts.  Incidentally,
this is the reason that the "Host: " parameter was added to HTTP/1.1, so
that a single web server can host many sites.

Currently, when I do a DNS lookup for "www.whitehouse.gov", I get a reverse
lookup that maps to "a204-102-114-48.deploy.akamaitechnologies.com".  So,
clearly they've got some mappings set, but not others.

> //8a-----------------------------------------------
> 
> The solution used:
> 
> traceroute -i 20 -c 1 q 100 www.mit.edu
> 
> From a previous question, we know that www.mit.edu is 19 hops away.
> Certainly '-i 20' will work, but why use more than '-i 19'?  (Interestingly,
> I had a steady delay of about 3ms less than the solution set, but traceroute
> ended without going to another hop.)

You have an eagle eye!  This is because I was lazy when I prepared the
solution set.  The question didn't change from last year, but the elaines
moved from Sweet Hall.  They used to have to jump through an additional
router on their way to the Internet.  I didn't feel like running a hundred
traceroutes and plotting their times, since the answers are not
substantially different with the move.  So, I reused last year's solution.
You caught me!

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: question about last year's midterm
Date: Tue, 20 Feb 2007 01:03:03 -0800
Lines: 12
Distribution: su
Message-ID: <eredgc$81l$1@news.Stanford.EDU>
References: <erbfps$joe$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1171962188 8245 128.12.133.106 (20 Feb 2007 09:03:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erbfps$joe$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11735

For this question we accepted all reasonable packet sizes. Most people 
assumed we were using an Ethernet link but you weren't penalized if you 
argued your own packet size correctly.

Yangfan Wang wrote:
> In the solutions to last year's midterm, it is mentioned that in problem 
>      16)d)ii that a RST packet is 60 bytes long. Considering that both a 
> TCP packet header and an IP packet header are 20 bytes each, wouldn't 40 
> bytes be sufficient? Or if we're taking into account the packet header 
> at the link level, isn't that dependent on what link layer protocol we use?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Sanjay Jeyakumar <sjeyakum@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PA2 scoring script
Date: Wed, 21 Feb 2007 04:09:36 +0000 (UTC)
Lines: 9
Distribution: su
Message-ID: <erggm0$2si$1@news.Stanford.EDU>
NNTP-Posting-Host: myth6.stanford.edu
X-Trace: news.Stanford.EDU 1172030976 2962 171.64.15.51 (21 Feb 2007 04:09:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11736

Hello,

Apologies if this has already been asked, but I was wondering if the
TA's are making available the scoring script for PA2. I'd like to
understand the source of some of my errors. 

Thanks,
Sanjay

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Mapping between port numbers and socket IDs.
Date: Tue, 20 Feb 2007 20:47:54 -0800
Lines: 3
Distribution: su
Message-ID: <ergitn$49a$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172033271 4394 128.12.194.72 (21 Feb 2007 04:47:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11737

How do I map between port numbers and socket IDs?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Mapping between port numbers and socket IDs.
Date: Wed, 21 Feb 2007 03:25:07 -0800
Lines: 8
Distribution: su
Message-ID: <erha6d$n7o$1@news.Stanford.EDU>
References: <ergitn$49a$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172057101 23800 128.12.194.72 (21 Feb 2007 11:25:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <ergitn$49a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11738

Disregard this question, please. Me dumb. :p

-Yangfan

Yangfan Wang wrote:
> How do I map between port numbers and socket IDs?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on testing our code.
Date: Wed, 21 Feb 2007 03:33:17 -0800
Lines: 16
Distribution: su
Message-ID: <erhaln$nuj$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172057591 24531 128.12.194.72 (21 Feb 2007 11:33:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11739

1. The assignment mentions that testing our code against the provided 
sample client and server will not be sufficent. Is there anything else 
that we can test against? I'm guessing the wget and the web proxy that 
the TAs will provide us?

2. How much should we test for the first checkpoint?

3. I'm not sure about the proper usage of the sample client and server. 
Knowing the names of the files that I can download off the server would 
be nice.

4. dprintf is not printing anything to screen, for me at least. This 
might be due to the fact that DEBUG is not defined in transport.h. Is 
this intentional?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Wed, 21 Feb 2007 10:18:32 -0800
Lines: 28
Distribution: su
Message-ID: <eri2dg$dd7$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172081904 13735 127.0.0.1 (21 Feb 2007 18:18:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erhaln$nuj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11740

Yangfan Wang wrote:
> 1. The assignment mentions that testing our code against the provided 
> sample client and server will not be sufficent. Is there anything else 
> that we can test against? I'm guessing the wget and the web proxy that 
> the TAs will provide us?

wget and the webserver definitely.


> 2. How much should we test for the first checkpoint?

Make sure the required functionality.. is well, functional.


> 3. I'm not sure about the proper usage of the sample client and server. 
> Knowing the names of the files that I can download off the server would 
> be nice.

I'll have Paul reply.

> 4. dprintf is not printing anything to screen, for me at least. This 
> might be due to the fact that DEBUG is not defined in transport.h. Is 
> this intentional?

I had problems with this as well, I advise you make your own printf 
methods to assist with debugging.

-David
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Establishing a TCP Connection
Date: Wed, 21 Feb 2007 14:14:35 -0800
Lines: 21
Distribution: su
Message-ID: <paun-B4766A.14143521022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172096078 25454 128.12.135.184 (21 Feb 2007 22:14:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11741


  When implementing the "three-way handshake", what are appropriate time 
values to wait after the active side has sent the first SYN packet?

  Also, say we have set the above value to x.  After a timeout of x 
seconds, do we wait again another larger amount before we return a 
ETIMEDOUT error, or do we do it immediately?

  In the case that we do wait a larger amount of time, do we resend the 
SYN packet, or do we just wait.  I am thinking we resend a duplicate SYN 
packet, this packet would have the same seq # since we are forced to 
start at 1.  Which begs the question what happens if two SYN-ACK come 
back one for each SYN packet we have sent, we just disregard the second 
one?

  Same question on the passive side, how long do we wait for the ACK on 
our SYN-ACK packet?  If we time out, do we wait some more and send a 
duplicate SYN-ACK packet?  

Thank you in advance for your response.
Filip
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Establishing a TCP Connection
Date: Wed, 21 Feb 2007 20:04:51 -0800
Lines: 31
Distribution: su
Message-ID: <erj4oq$dsu$1@news.Stanford.EDU>
References: <paun-B4766A.14143521022007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172117083 14238 127.0.0.1 (22 Feb 2007 04:04:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <paun-B4766A.14143521022007@nntp.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11742

Filip Paun wrote:
>   When implementing the "three-way handshake", what are appropriate time 
> values to wait after the active side has sent the first SYN packet?

This will be implementation specific, but as is mentioned in the handout 
you should use round trip time, which you cannot use on the first syn 
obviously.. so pick a value you think is realistic, then for later 
timeouts use the rtt.

>   Also, say we have set the above value to x.  After a timeout of x 
> seconds, do we wait again another larger amount before we return a 
> ETIMEDOUT error, or do we do it immediately?

You should retransmit rather than bombing immediately.

>   In the case that we do wait a larger amount of time, do we resend the 
> SYN packet, or do we just wait.  I am thinking we resend a duplicate SYN 
> packet, this packet would have the same seq # since we are forced to 
> start at 1.  Which begs the question what happens if two SYN-ACK come 
> back one for each SYN packet we have sent, we just disregard the second 
> one?

Yes.

>   Same question on the passive side, how long do we wait for the ACK on 
> our SYN-ACK packet?  If we time out, do we wait some more and send a 
> duplicate SYN-ACK packet?  

Resend.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Wed, 21 Feb 2007 23:32:07 -0800
Lines: 22
Distribution: su
Message-ID: <erjgtf$mh2$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172129519 23074 128.12.194.72 (22 Feb 2007 07:31:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eri2dg$dd7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11743

David Erickson wrote:

>> 3. I'm not sure about the proper usage of the sample client and 
>> server. Knowing the names of the files that I can download off the 
>> server would be nice.
> 
> 
> I'll have Paul reply.
> 

Thanks. Also, knowing what the expected behavior is when I download a 
file from the sample server would be nice. For example, does the server 
terminate the connection after the file has been sent? Does the client 
terminate the connection afterward?

Otherwise, it's impossible to tell whether my code is doing the right 
thing or not, since I can't even get it to execute.

-Yangfan



.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Wed, 21 Feb 2007 23:48:08 -0800
Lines: 28
Distribution: su
Message-ID: <erjhro$nim$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172130488 24150 127.0.0.1 (22 Feb 2007 07:48:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erjgtf$mh2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11744

Yangfan Wang wrote:
> David Erickson wrote:
> 
>>> 3. I'm not sure about the proper usage of the sample client and 
>>> server. Knowing the names of the files that I can download off the 
>>> server would be nice.
>>
>>
>> I'll have Paul reply.
>>
> 
> Thanks. Also, knowing what the expected behavior is when I download a 
> file from the sample server would be nice. For example, does the server 
> terminate the connection after the file has been sent? Does the client 
> terminate the connection afterward?
> 
> Otherwise, it's impossible to tell whether my code is doing the right 
> thing or not, since I can't even get it to execute.
> 
> -Yangfan
> 
> 
> 

See if you can elicit a response from Paul, I believe he is writing that 
code.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Max stcp payload size
Date: Thu, 22 Feb 2007 00:58:03 -0700
Lines: 14
Distribution: su
Message-ID: <erjiec$pvb$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172131084 26603 127.0.0.1 (22 Feb 2007 07:58:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11745

What is the significance of the maximum stcp packet payload size being 536 
bytes?

It appears stcp_network_send will take up to 1500 bytes (although it appears 
it would crash if you offered it more than that).  And it lools like 
stcp_network_recv could return more than 536 bytes.

When we compile stcp into our proxy, won't we then be dealing with real tcp 
packets that aren't subject to a maximum size of 536 bytes?

Thanks,
Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA3.A
Date: Thu, 22 Feb 2007 09:13:01 +0000 (UTC)
Organization: Your Company
Lines: 4
Distribution: su
Message-ID: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172135581 5 128.12.22.217 (22 Feb 2007 09:13:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11746

has anyone finished 3.A? how long did it take? does anyone know how long 
this assignment (3.A) is suppose to take? 10 hours? 20? 30? 40?

thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3.A
Date: Thu, 22 Feb 2007 01:35:16 -0800
Lines: 12
Distribution: su
Message-ID: <erjo4b$11p$1@news.Stanford.EDU>
References: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172136907 1081 128.12.194.72 (22 Feb 2007 09:35:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11747

It's hard to tell. I'm tentatively in "debugging" phase for 3.A, but 
with no concrete way of testing my code, I don't know if I missed any 
important implementation details or not. I could only be half-done for 
all I know.

-Yangfan

Chun Kai Wang wrote:
> has anyone finished 3.A? how long did it take? does anyone know how long 
> this assignment (3.A) is suppose to take? 10 hours? 20? 30? 40?
> 
> thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3.A
Date: Thu, 22 Feb 2007 09:46:25 +0000 (UTC)
Organization: Your Company
Lines: 24
Distribution: su
Message-ID: <Xns98DF120C1BBF6chunkaiwstanfordedu@171.64.14.103>
References: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103> <erjo4b$11p$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172137585 1587 128.12.22.217 (22 Feb 2007 09:46:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11748

how long have u worked on it?






Yangfan Wang <yfw@stanford.edu> wrote in
news:erjo4b$11p$1@news.Stanford.EDU: 

> It's hard to tell. I'm tentatively in "debugging" phase for 3.A, but 
> with no concrete way of testing my code, I don't know if I missed any 
> important implementation details or not. I could only be half-done for
> all I know.
> 
> -Yangfan
> 
> Chun Kai Wang wrote:
>> has anyone finished 3.A? how long did it take? does anyone know how
>> long this assignment (3.A) is suppose to take? 10 hours? 20? 30? 40?
>> 
>> thanks.
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Thu, 22 Feb 2007 01:47:21 -0800
Lines: 12
Distribution: su
Message-ID: <erjora$1fa$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172137642 1514 128.12.133.106 (22 Feb 2007 09:47:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erjhro$nim$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11749

>> Thanks. Also, knowing what the expected behavior is when I download a 
>> file from the sample server would be nice. For example, does the 
>> server terminate the connection after the file has been sent? Does the 
>> client terminate the connection afterward?
>>

Your code is the TCP layer. Just implement the TCP semantics. Who cares 
what the client does? All they do is get to call your socket methods. 
Just initiate the TCP connection when you are initialized and tear it 
down when asked to. The client and server will use your TCP like any 
application should use TCP (since for assignment 4 you're going to use 
your own proxy over your own tcp through your own router).
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3.A
Date: Thu, 22 Feb 2007 01:49:43 -0800
Lines: 17
Distribution: su
Message-ID: <erjovo$1fa$2@news.Stanford.EDU>
References: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103> <erjo4b$11p$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172137784 1514 128.12.133.106 (22 Feb 2007 09:49:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erjo4b$11p$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11750

Yangfan Wang wrote:
> It's hard to tell. I'm tentatively in "debugging" phase for 3.A, but 
> with no concrete way of testing my code, I don't know if I missed any 
> important implementation details or not. I could only be half-done for 
> all I know.
> 
> -Yangfan
> 
> Chun Kai Wang wrote:
>> has anyone finished 3.A? how long did it take? does anyone know how 
>> long this assignment (3.A) is suppose to take? 10 hours? 20? 30? 40?
>>
>> thanks.

Last year, when I did this, I think it took me about 5 hours to get 
something working, and then an untold number of hours debugging. But 
that was for all 3 parts.
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Thu, 22 Feb 2007 11:30:24 -0800
Lines: 15
Distribution: su
Message-ID: <erkqur$n5$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172172571 741 127.0.0.1 (22 Feb 2007 19:29:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11751

> Your code is the TCP layer. Just implement the TCP semantics. Who cares 
> what the client does? All they do is get to call your socket methods. Just 
> initiate the TCP connection when you are initialized and tear it down when 
> asked to. The client and server will use your TCP like any application 
> should use TCP (since for assignment 4 you're going to use your own proxy 
> over your own tcp through your own router).
We care.  In order to test for correctness, we need to know if the 
application is acting as expected.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Final exam date
Date: Thu, 22 Feb 2007 16:24:55 -0700
Lines: 3
Distribution: su
Message-ID: <erl8o8$dj9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172186697 13929 127.0.0.1 (22 Feb 2007 23:24:57 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11752

What will be the date for our final exam?


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Receive buffer clarification
Date: Thu, 22 Feb 2007 16:47:06 -0700
Lines: 10
Distribution: su
Message-ID: <erla1u$eh7$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172188030 14887 127.0.0.1 (22 Feb 2007 23:47:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11753

In the "sliding windows" section, the handout says received data having a 
sequence number higher than that of the last byte of the receiver window is 
discarded.  In the "retransmissions" section, it says the receiver must 
buffer any data it receives, even if it arrives out of order.  Can we 
reconcile these statements by saying the receiver must buffer only received 
bytes that fall somewhere within the receiver window?

--Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3.A
Date: Thu, 22 Feb 2007 17:32:24 -0800
Lines: 41
Distribution: su
Message-ID: <erlg6v$k5d$1@news.Stanford.EDU>
References: <Xns98DFC626F00Bchunkaiwstanfordedu@171.64.14.103> <erjo4b$11p$1@news.Stanford.EDU> <Xns98DF120C1BBF6chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172194335 20653 128.12.194.72 (23 Feb 2007 01:32:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <Xns98DF120C1BBF6chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11754

Like Paul, it took me around 5 hours to get something that "looks like" 
it works, assuming a reliable link.

I have no idea whether it works or not though. And since I have no clue 
what the expected behavior of the sample server and client are, I can't 
test my code. They don't seem to be calling the teardown code, for 
starters. That doesn't look right to me.

To make matters worse, I'm afraid to make any drastic changes to the 
code for part B, since I don't want to break any of the part A code that 
I have now.

-Yangfan

Chun Kai Wang wrote:
> how long have u worked on it?
> 
> 
> 
> 
> 
> 
> Yangfan Wang <yfw@stanford.edu> wrote in
> news:erjo4b$11p$1@news.Stanford.EDU: 
> 
> 
>>It's hard to tell. I'm tentatively in "debugging" phase for 3.A, but 
>>with no concrete way of testing my code, I don't know if I missed any 
>>important implementation details or not. I could only be half-done for
>>all I know.
>>
>>-Yangfan
>>
>>Chun Kai Wang wrote:
>>
>>>has anyone finished 3.A? how long did it take? does anyone know how
>>>long this assignment (3.A) is suppose to take? 10 hours? 20? 30? 40?
>>>
>>>thanks.
>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Thu, 22 Feb 2007 17:35:03 -0800
Lines: 19
Distribution: su
Message-ID: <erlgbt$k5d$2@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172194493 20653 128.12.194.72 (23 Feb 2007 01:34:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erjora$1fa$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11755

Paul Tarjan (TA) wrote:
>>> Thanks. Also, knowing what the expected behavior is when I download a 
>>> file from the sample server would be nice. For example, does the 
>>> server terminate the connection after the file has been sent? Does 
>>> the client terminate the connection afterward?
>>>
> 
> Your code is the TCP layer. Just implement the TCP semantics. Who cares 
> what the client does? All they do is get to call your socket methods. 
> Just initiate the TCP connection when you are initialized and tear it 
> down when asked to. The client and server will use your TCP like any 
> application should use TCP (since for assignment 4 you're going to use 
> your own proxy over your own tcp through your own router).

That's just the thing. They're NOT calling my socket methods. I need to 
know what they do so that I can get them to call my methods. I can't 
test code if I don't even know how to trigger its execution, man.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: STCP timers
Date: Thu, 22 Feb 2007 18:08:28 -0800
Lines: 19
Distribution: su
Message-ID: <erliai$lo5$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172196498 22277 128.12.194.72 (23 Feb 2007 02:08:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11756

It seems to me that stcp_wait_for_event only implements one timer for 
you. In order to re-transmit packets for part B, it seems to me that we 
would need, at least conceptually, one timer per transmitted packet. The 
textbook hinted at the fact that multiple timers may be implemented in 
one timer. Is this what we're supposed to do here? If so, how? 
Otherwise, will multiple calls to stcp_wait_for_event generate multiple, 
independent timed waits?

For example, if I call stcp_wait_for_event with time = 3 seconds, gets 
interrupted 1 second later with something other than a time out, is the 
timer stopped? Restarted? Is it still running? Do I have any control 
over this?

I'm also unsure on how to associate context/state with each timer. We 
would need associate each timer with a packet or a range of sequence 
numbers, at least. It seems that we have a global context per connection 
and that's it.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: New PA3 Tarball Available
Date: Thu, 22 Feb 2007 18:15:57 -0800
Lines: 17
Distribution: su
Message-ID: <C2038E5D.89FC%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172196958 22574 127.0.0.1 (23 Feb 2007 02:15:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: New PA3 Tarball Available
Thread-Index: AcdW8I2IzE4oGMLjEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11757

A new version of the tarball is available.  This one contains:

    - proxyget: A simple wget-like program that works over STCP

    - proxy.a: A reference implementation of the web proxy assignment.  The
code was generously donated by David Gobaud.

    - A new makefile that will compile the above two programs.

You can download the new tarball at the following location:

    http://www.stanford.edu/class/cs244a/hw3/pa3.tgz

Let me know if you have any issues.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP timers
Date: Thu, 22 Feb 2007 20:46:45 -0800
Lines: 33
Distribution: su
Message-ID: <erlri1$sht$1@news.Stanford.EDU>
References: <erliai$lo5$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172205953 29245 127.0.0.1 (23 Feb 2007 04:45:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11758

> It seems to me that stcp_wait_for_event only implements one timer for you. 
> In order to re-transmit packets for part B, it seems to me that we would 
> need, at least conceptually, one timer per transmitted packet. The 
> textbook hinted at the fact that multiple timers may be implemented in one 
> timer. Is this what we're supposed to do here? If so, how? Otherwise, will 
> multiple calls to stcp_wait_for_event generate multiple, independent timed 
> waits?
Think about what you did for multiple outstanding ARP requests.  I suspect 
you did not spawn a thread for each ARP request you sent out (if you did, 
that is bad coding, hmm... kindof like the STCP threading model (oops, I 
should be more selective with what I say; they might give us signals 
instead)).

> For example, if I call stcp_wait_for_event with time = 3 seconds, gets 
> interrupted 1 second later with something other than a time out, is the 
> timer stopped? Restarted? Is it still running? Do I have any control over 
> this?
See FAQ: Q9. What is the meaning of 'absolute time' in 
stcp_wait_for_event()?

> I'm also unsure on how to associate context/state with each timer. We 
> would need associate each timer with a packet or a range of sequence 
> numbers, at least. It seems that we have a global context per connection 
> and that's it.
I would suggest thinking of the timer as an Interval subtraction :-).  You 
are given Dates not Seconds

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: max payload size
Date: Fri, 23 Feb 2007 05:29:19 +0000 (UTC)
Organization: Your Company
Lines: 4
Distribution: su
Message-ID: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172208559 930 128.12.22.217 (23 Feb 2007 05:29:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11759

wat does 536 bytes for max payload size mean? does this include the TCP 
header? or just the data?

also, it seems like the window size is fixed at 3072... is this true?
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Final exam date
Date: Thu, 22 Feb 2007 22:13:21 -0800
Lines: 17
Distribution: su
Message-ID: <erm0ij$2kh$1@news.Stanford.EDU>
References: <erl8o8$dj9$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1172211091 2705 128.12.81.44 (23 Feb 2007 06:11:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11760

Hey Kevin,

The final exam schedule is at 
http://registrar.stanford.edu/students/courses/exams_1074.htm

Looks like 3/19 @ 3:30 PM - 6:30 PM

-- 
David Gobaud

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:erl8o8$dj9$1@news.Stanford.EDU...
> What will be the date for our final exam?
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: invalid checksum
Date: Fri, 23 Feb 2007 06:33:09 +0000 (UTC)
Organization: Your Company
Lines: 2
Distribution: su
Message-ID: <Xns98DFE56BABF6Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172212389 3555 128.12.22.217 (23 Feb 2007 06:33:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11761

when i get a packet with invalid check sum, i just drop it right? no need 
to send any ack's etc.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: invalid checksum
Date: Thu, 22 Feb 2007 22:55:33 -0800
Lines: 16
Distribution: su
Message-ID: <C203CFE5.8A16%jpettit@stanford.edu>
References: <Xns98DFE56BABF6Echunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172213736 4520 127.0.0.1 (23 Feb 2007 06:55:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: invalid checksum
Thread-Index: AcdXF5zO2zQlg8MKEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11762

This is covered in the FAQ; you do not need to verify the checksum.
However, if you do, then you would just drop the packet.  There's no way to
indicate to the other side that you received it, but that there was a
problem.

--Justin
 

On 2/22/07 10:33 PM, in article
Xns98DFE56BABF6Echunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> when i get a packet with invalid check sum, i just drop it right? no need
> to send any ack's etc.


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Max stcp payload size
Date: Thu, 22 Feb 2007 23:10:02 -0800
Lines: 17
Distribution: su
Message-ID: <C203D34A.8A1A%jpettit@stanford.edu>
References: <erjiec$pvb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172214605 5270 127.0.0.1 (23 Feb 2007 07:10:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Max stcp payload size
Thread-Index: AcdXGaLF4UHw0sMMEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11763

> What is the significance of the maximum stcp packet payload size being 536
> bytes?

This is the default for TCP.

> It appears stcp_network_send will take up to 1500 bytes (although it appears
> it would crash if you offered it more than that).  And it lools like
> stcp_network_recv could return more than 536 bytes.

It's possible, but you

> When we compile stcp into our proxy, won't we then be dealing with real tcp
> packets that aren't subject to a maximum size of 536 bytes?

It has to be 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Max stcp payload size
Date: Thu, 22 Feb 2007 23:15:35 -0800
Lines: 27
Distribution: su
Message-ID: <C203D497.8A1F%jpettit@stanford.edu>
References: <erjiec$pvb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172214939 5501 127.0.0.1 (23 Feb 2007 07:15:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Max stcp payload size
Thread-Index: AcdXGmlBp9Fj3sMNEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11764

Sorry about that last post.  My key-mappings seem to have gotten messed up.

> What is the significance of the maximum stcp packet payload size being 536
> bytes?

This is the default for TCP.

> It appears stcp_network_send will take up to 1500 bytes (although it appears
> it would crash if you offered it more than that).  And it lools like
> stcp_network_recv could return more than 536 bytes.

Yes, it's possible, but both sides would need to agree to use a larger MSS.

> When we compile stcp into our proxy, won't we then be dealing with real tcp
> packets that aren't subject to a maximum size of 536 bytes?

If you use Wireshark to sniff a web connection, you will most likely see
that both sides announce an MSS of 1460 in their TCP options.  Since STCP
will not do that (unless you want to add it!), you don't need to worry about
it.

You can read all about this in the following RFC:

    http://www.faqs.org/rfcs/rfc879.html

--Justin

.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: On the server side
Date: Thu, 22 Feb 2007 23:23:55 -0800
Lines: 12
Distribution: su
Message-ID: <paun-349905.23235522022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172215439 5888 128.12.135.184 (23 Feb 2007 07:23:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11765


When we run server, it prints out something of the form:
   Server's address is myth7.Stanford.EDU:54460

The 54460 is the port number we need to specify for the option 
server:port when we run client, correct?

Also, when we run server, server does get to call transport_init with 
the bool is_active set to false, is this correct?

Thank you.
Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Thu, 22 Feb 2007 23:33:05 -0800
Lines: 11
Distribution: su
Message-ID: <C203D8B1.8A2B%jpettit@stanford.edu>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172215988 6427 127.0.0.1 (23 Feb 2007 07:33:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: max payload size
Thread-Index: AcdXHNsaGWnjfMMQEduDtgARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11766

> wat does 536 bytes for max payload size mean? does this include the TCP
> header? or just the data?

The payload is the data that STCP carries, so it's just the data.
 
> also, it seems like the window size is fixed at 3072... is this true?

Please read through the assignment.  This is clearly discussed.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP timers
Date: Thu, 22 Feb 2007 23:44:19 -0800
Lines: 53
Distribution: su
Message-ID: <erm609$6qr$1@news.Stanford.EDU>
References: <erliai$lo5$1@news.Stanford.EDU> <erlri1$sht$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172216649 7003 128.12.194.72 (23 Feb 2007 07:44:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erlri1$sht$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11767

Randy Jennings wrote:

>>It seems to me that stcp_wait_for_event only implements one timer for you. 
>>In order to re-transmit packets for part B, it seems to me that we would 
>>need, at least conceptually, one timer per transmitted packet. The 
>>textbook hinted at the fact that multiple timers may be implemented in one 
>>timer. Is this what we're supposed to do here? If so, how? Otherwise, will 
>>multiple calls to stcp_wait_for_event generate multiple, independent timed 
>>waits?
>>    
>>
>Think about what you did for multiple outstanding ARP requests.  I suspect 
>you did not spawn a thread for each ARP request you sent out (if you did, 
>that is bad coding, hmm... kindof like the STCP threading model (oops, I 
>should be more selective with what I say; they might give us signals 
>instead)).
>
>  
>
>>For example, if I call stcp_wait_for_event with time = 3 seconds, gets 
>>interrupted 1 second later with something other than a time out, is the 
>>timer stopped? Restarted? Is it still running? Do I have any control over 
>>this?
>>    
>>
>See FAQ: Q9. What is the meaning of 'absolute time' in 
>stcp_wait_for_event()?
>
>  
>
>>I'm also unsure on how to associate context/state with each timer. We 
>>would need associate each timer with a packet or a range of sequence 
>>numbers, at least. It seems that we have a global context per connection 
>>and that's it.
>>    
>>
>I would suggest thinking of the timer as an Interval subtraction :-).  You 
>are given Dates not Seconds
>
>Sincerely,
>Randy Jennings
>
>The squirrels are your friends! 
>
>
>  
>
Actually, I did spawn a new thread each time an ARP came in. I'd do it 
here, but we're only supposed to call functions from stcp_api, right?

Please enlighten me on better ways of doing it. :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 08:42:06 +0000 (UTC)
Organization: Your Company
Lines: 22
Distribution: su
Message-ID: <Xns98E0724CEECCchunkaiwstanfordedu@171.64.14.103>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172220126 12614 128.12.22.217 (23 Feb 2007 08:42:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11768

for the window size, 3072, i guess my question is more on the lines that 
since our STCP is suppose to communicate with other servers and is 
compatible with TCP, i guess i can just ignore those window sizes then 
right?



Justin Pettit <jpettit@stanford.edu> wrote in news:C203D8B1.8A2B%
jpettit@stanford.edu:

>> wat does 536 bytes for max payload size mean? does this include the TCP
>> header? or just the data?
> 
> The payload is the data that STCP carries, so it's just the data.
>  
>> also, it seems like the window size is fixed at 3072... is this true?
> 
> Please read through the assignment.  This is clearly discussed.
> 
> --Justin
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 03:51:22 -0500
Lines: 41
Distribution: su
Message-ID: <erm9ud$ctq$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <Xns98E0724CEECCchunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1172220686 13242 127.0.0.1 (23 Feb 2007 08:51:26 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11769

It's my understanding (please someone correct me if I'm wrong) but that we 
should be advertising the 3072 byte window as the local receiver window, but 
then the window for the other end of the connection is that which is 
described in the datagrams received.  (then calculate the sending window on 
the lesser of the congestion window and the remote receive window).  I guess 
all the fixed sizes buy is is that we don't have to worry about changing the 
size of our local receive window based on any internal buffers and we don't 
have to do tcp congestion control (I guess we're one of those rogue 
implementations that ignores it).

My .02 - I'd love to hear from a TA where I'm wrong as I'm just starting 
this part myself.

-Seth

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98E0724CEECCchunkaiwstanfordedu@171.64.14.103...
> for the window size, 3072, i guess my question is more on the lines that
> since our STCP is suppose to communicate with other servers and is
> compatible with TCP, i guess i can just ignore those window sizes then
> right?
>
>
>
> Justin Pettit <jpettit@stanford.edu> wrote in news:C203D8B1.8A2B%
> jpettit@stanford.edu:
>
>>> wat does 536 bytes for max payload size mean? does this include the TCP
>>> header? or just the data?
>>
>> The payload is the data that STCP carries, so it's just the data.
>>
>>> also, it seems like the window size is fixed at 3072... is this true?
>>
>> Please read through the assignment.  This is clearly discussed.
>>
>> --Justin
>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: stcp wait for event
Date: Fri, 23 Feb 2007 10:18:37 +0000 (UTC)
Organization: Your Company
Lines: 10
Distribution: su
Message-ID: <Xns98E0178214B2Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172225917 16515 128.12.22.217 (23 Feb 2007 10:18:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11770

im confused when to wait for a time in:



unsigned int stcp_wait_for_event(mysocket_t             sd,
                                 unsigned int           wait_flags,
                                 const struct timespec *abstime);


when should i pass NULL for abstime and when not to?
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp wait for event
Date: Fri, 23 Feb 2007 10:20:42 +0000 (UTC)
Organization: Your Company
Lines: 28
Distribution: su
Message-ID: <Xns98E017DC84ED4chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E0178214B2Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172226042 16515 128.12.22.217 (23 Feb 2007 10:20:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11771

sorry bad question:

re-phrase:

for PA3.A, i can pass NULL right? it's only in part B where we implement 
timeout this is needed right?


thanks.




Chun Kai Wang <chunkaiw@stanford.edu> wrote in 
news:Xns98E0178214B2Echunkaiwstanfordedu@171.64.14.103:

> im confused when to wait for a time in:
> 
> 
> 
> unsigned int stcp_wait_for_event(mysocket_t             sd,
>                                  unsigned int           wait_flags,
>                                  const struct timespec *abstime);
> 
> 
> when should i pass NULL for abstime and when not to?
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: behavior of stcp
Date: Fri, 23 Feb 2007 11:32:30 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98E024088D61Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172230350 20178 128.12.22.217 (23 Feb 2007 11:32:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11772

i'm confused about what stcp is suppose to do.


say i send a syn packet, so i'm expecting a syn-ack, but i get a packet 
that is neither syn nor ack, what happens?

do i terminate the connection? or just drop that packet?

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP timers
Date: Fri, 23 Feb 2007 08:11:41 -0800
Lines: 19
Distribution: su
Message-ID: <ern3m8$7su$1@news.Stanford.EDU>
References: <erliai$lo5$1@news.Stanford.EDU> <erlri1$sht$1@news.Stanford.EDU> <erm609$6qr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172247049 8094 127.0.0.1 (23 Feb 2007 16:10:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11773

> Actually, I did spawn a new thread each time an ARP came in. I'd do it 
> here, but we're only supposed to call functions from stcp_api, right?
I think that restriction is only for non-<standard> files (yes, I am going 
to get to cut and paste my queue implementation into transport.c; what joy). 
I presume we can call gettimeofday and memcpy and stuff.  If someone so 
chose to call pthread_create, I don't think that would have grading 
ramifications (provided pthread was already linked in.)

> Please enlighten me on better ways of doing it. :)
Think of Activities in your discrete event simulator for CS249.  How many 
threads did you have there?  One, I hope.  How did you move from one event 
to the next?  How did you wait for the next event to come due?

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: readings in textbook
Date: Fri, 23 Feb 2007 08:16:40 -0800
Lines: 7
Distribution: su
Message-ID: <ern3vj$85o$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172247347 8376 127.0.0.1 (23 Feb 2007 16:15:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11774

Chapter 5 was added to the reading list (and I anticipated that one).  Will 
any of chapters 6-9 be assigned before the end of the quarter?

Sincerely,
Randy Jennings 


.

Path: shelby.stanford.edu!not-for-mail
From: Paolo Bezoari <paolob@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: New PA3 Tarball Available
Date: Fri, 23 Feb 2007 10:33:27 -0800
Lines: 20
Distribution: su
Message-ID: <ernc1n$fmi$1@news.Stanford.EDU>
References: <C2038E5D.89FC%jpettit@stanford.edu>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172255607 16082 171.64.15.38 (23 Feb 2007 18:33:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2
X-Accept-Language: en
In-Reply-To: <C2038E5D.89FC%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11775

Justin Pettit wrote:
> A new version of the tarball is available.  This one contains:
> 
>     - proxyget: A simple wget-like program that works over STCP
> 
>     - proxy.a: A reference implementation of the web proxy assignment.  The
> code was generously donated by David Gobaud.
> 
>     - A new makefile that will compile the above two programs.
> 
> You can download the new tarball at the following location:
> 
>     http://www.stanford.edu/class/cs244a/hw3/pa3.tgz
> 
> Let me know if you have any issues.
> 
> --Justin
> 

There doesn't seem to be any proxy.a ...
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: pa3: sequence number wrap around
Date: Fri, 23 Feb 2007 12:07:38 -0800
Lines: 19
Distribution: su
Message-ID: <ernhgn$lnr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172261207 22267 127.0.0.1 (23 Feb 2007 20:06:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11776

From the FAQ:

Q11. Do I need to deal with the case that sequence number wrapps around 
(goes over 2^32 and starts from 0 again)?

A11. No. This does add some complexity into the assignment. You're not 
required to deal with it. We're not going to test your programs to transfer 
4 gigabytes of data :-) But keep in mind this happens in real TCP.

Does this mean we have to handle the sequence numbers wrapping around from 
the other side of the connection?  (IOW, our Acks.)  I understood that we 
would be hooking up to real TCP in pa4.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: pa3: data during connection establishment
Date: Fri, 23 Feb 2007 12:27:00 -0800
Lines: 20
Distribution: su
Message-ID: <ernil0$mtq$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172262368 23482 127.0.0.1 (23 Feb 2007 20:26:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11777

From pg 30, rfc 793, it states that data may be sent during connection 
establishment, although it must not be sent up to user space until reaching 
connection establishment.

I think that means that the sender of SYN,ACK can send data (although I have 
not seen this on Ethernet traces I have seen).  Do we have to support 
receiving that data?  I would rather not, but it seems reasonable to require 
us to do so.

However, I would rather not support receiving data on a SYN (no ACK) packet. 
It seems like that would be unwise from a security standpoint, and it would 
complicate the code (delaying sending it up to the ACK before receiving the 
ACK of my SYN,ACK packet).  May we just drop data in this case?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 12:36:47 -0800
Lines: 14
Distribution: su
Message-ID: <ernj7b$nfg$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172262955 24048 127.0.0.1 (23 Feb 2007 20:35:55 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11778

>> wat does 536 bytes for max payload size mean? does this include the TCP
>> header? or just the data?
>
> The payload is the data that STCP carries, so it's just the data.
Hmm... that is annoying.  That means we do not have a known bound on the 
packet size (TCP options).  Is there a particular size of option fields you 
would prefer we support, or just over-provision.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: ANSI Requirement Update
Date: Fri, 23 Feb 2007 14:53:30 -0700
Lines: 19
Distribution: su
Message-ID: <ernnp2$rsm$1@news.Stanford.EDU>
References: <C1EE7AA0.8217%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172267618 28566 127.0.0.1 (23 Feb 2007 21:53:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11779

So we can use //--- comments in pa3 and p4, right?  I noticed the Makefile 
still compiles using -ansi, but since it's using g++ instead of gcc, 
the -ansi flag doesn't seem to mind the //--- comments.

--Kevin

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C1EE7AA0.8217%jpettit@stanford.edu...
>I spoke with the other TAs, and we're lifting the "-ansi" requirement.  It
> seems like it has outlived its usefulness.  We'd like to see everything be
> C99-compliant, but we won't go out of our way enforcing it.  Please don't 
> do
> anything too weird.  You still need to follow the other coding guidelines
> and make everything compile cleanly with "-Wall".
>
> --Justin
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: stcp network send
Date: Fri, 23 Feb 2007 22:35:45 +0000 (UTC)
Organization: Your Company
Lines: 2
Distribution: su
Message-ID: <Xns98E0947BC5A9Cchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172270145 978 128.12.22.217 (23 Feb 2007 22:35:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11780

if stcp network send fails for some reason, what should i do? tear down the 
connection?????
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ANSI Requirement Update
Date: Fri, 23 Feb 2007 15:03:49 -0800
Lines: 31
Distribution: su
Message-ID: <C204B2D5.8A7B%jpettit@stanford.edu>
References: <C1EE7AA0.8217%jpettit@stanford.edu> <ernnp2$rsm$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172271836 2410 127.0.0.1 (23 Feb 2007 23:03:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: ANSI Requirement Update
Thread-Index: AcdXnuC4H2fV1MOSEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11781

You can remove the "-ansi" flag from the Makefile and use C++ style
comments.  Just make sure that you compile with "-Wall" and that you don't
generate any warnings.

--Justin


On 2/23/07 1:53 PM, in article ernnp2$rsm$1@news.Stanford.EDU, "Kevin Hart"
<kevin.hart@hp.com> wrote:

> So we can use //--- comments in pa3 and p4, right?  I noticed the Makefile
> still compiles using -ansi, but since it's using g++ instead of gcc,
> the -ansi flag doesn't seem to mind the //--- comments.
> 
> --Kevin
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C1EE7AA0.8217%jpettit@stanford.edu...
>> I spoke with the other TAs, and we're lifting the "-ansi" requirement.  It
>> seems like it has outlived its usefulness.  We'd like to see everything be
>> C99-compliant, but we won't go out of our way enforcing it.  Please don't
>> do
>> anything too weird.  You still need to follow the other coding guidelines
>> and make everything compile cleanly with "-Wall".
>> 
>> --Justin
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Receive buffer clarification
Date: Fri, 23 Feb 2007 15:40:41 -0800
Lines: 12
Distribution: su
Message-ID: <C204BB79.8A86%jpettit@stanford.edu>
References: <erla1u$eh7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172274046 4324 127.0.0.1 (23 Feb 2007 23:40:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Receive buffer clarification
Thread-Index: AcdXpActRd6vvMOXEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11782

> In the "sliding windows" section, the handout says received data having a
> sequence number higher than that of the last byte of the receiver window is
> discarded.  In the "retransmissions" section, it says the receiver must
> buffer any data it receives, even if it arrives out of order.  Can we
> reconcile these statements by saying the receiver must buffer only received
> bytes that fall somewhere within the receiver window?

Exactly!

--Justin 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Fri, 23 Feb 2007 15:58:38 -0800
Lines: 18
Distribution: su
Message-ID: <C204BFAE.8A8C%jpettit@stanford.edu>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU> <erlgbt$k5d$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172275124 5020 127.0.0.1 (23 Feb 2007 23:58:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Question on testing our code.
Thread-Index: AcdXpokex9ziXMOZEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11783

>> Your code is the TCP layer. Just implement the TCP semantics. Who cares
>> what the client does? All they do is get to call your socket methods.
>> Just initiate the TCP connection when you are initialized and tear it
>> down when asked to. The client and server will use your TCP like any
>> application should use TCP (since for assignment 4 you're going to use
>> your own proxy over your own tcp through your own router).
> 
> That's just the thing. They're NOT calling my socket methods. I need to
> know what they do so that I can get them to call my methods. I can't
> test code if I don't even know how to trigger its execution, man.

What do you mean?  All the source code is in server.c and client.c; you
should be able figure out what's going on.  The code you write in
transport.c is going to be called by the various my* socket functions.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 16:57:59 -0800
Lines: 20
Distribution: su
Message-ID: <ero2h4$7v1$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172278628 8161 127.0.0.1 (24 Feb 2007 00:57:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11784

>>> wat does 536 bytes for max payload size mean? does this include the TCP
>>> header? or just the data?
>>
>> The payload is the data that STCP carries, so it's just the data.
> Hmm... that is annoying.  That means we do not have a known bound on the 
> packet size (TCP options).  Is there a particular size of option fields 
> you would prefer we support, or just over-provision.
Justin, from the assignment page, I read

> STCP Packet Format
> An STCP packet has a maximum size of 536 bytes.

Is the webpage in error?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Fri, 23 Feb 2007 17:41:12 -0800
Lines: 71
Distribution: su
Message-ID: <ero53c$aiq$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU> <erlgbt$k5d$2@news.Stanford.EDU> <C204BFAE.8A8C%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172281260 10842 128.12.194.72 (24 Feb 2007 01:41:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C204BFAE.8A8C%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11785

Justin Pettit wrote:
>>>Your code is the TCP layer. Just implement the TCP semantics. Who cares
>>>what the client does? All they do is get to call your socket methods.
>>>Just initiate the TCP connection when you are initialized and tear it
>>>down when asked to. The client and server will use your TCP like any
>>>application should use TCP (since for assignment 4 you're going to use
>>>your own proxy over your own tcp through your own router).
>>
>>That's just the thing. They're NOT calling my socket methods. I need to
>>know what they do so that I can get them to call my methods. I can't
>>test code if I don't even know how to trigger its execution, man.
> 
> 
> What do you mean?  All the source code is in server.c and client.c; you
> should be able figure out what's going on.  The code you write in
> transport.c is going to be called by the various my* socket functions.
> 
> --Justin
> 
> 
That's reasonable, but what about the case where the information is not 
in the source code, for example, I have yet to figure out a case where 
the data request to the sample server actually succeeds:

myth25:~/CS244A/hw3/pa3> ./client -f foo myth25.Stanford.EDU:52219
transport_init called with sd=0, active=1
sd=0: SYN sent.
sd=0: SYNACK received.
sd=0: ACK sent.
sd=0: Sent 5 bytes of data to the network.
sd=0: ACK received.
sd=0: Delivered 45 bytes of data to the application.
server: foo,-1,File does not exist or access denied
sd=0: ACK sent.
sd=0: FIN sent.
sd=0: ACK received.
sd=0: FIN received.
sd=0: ACK sent.

Okay, so there is no file named foo, as expected, but what about:

myth25:~/CS244A/hw3/pa3> ./proxyget myth25.Stanford.EDU:52124 
www.stanford.edu
Connecting to myth25.Stanford.EDU on port 52124
transport_init called with sd=0, active=1
sd=0: SYN sent.
sd=0: SYNACK received.
sd=0: ACK sent.
Sending request GET www.stanford.edu HTTP/1.0
Receiving data
sd=0: Sent 33 bytes of data to the network.
sd=0: ACK received.
sd=0: Delivered 71 bytes of data to the application.
GET www.stanford.edu HTTP/1.0,-1,File does not exist or access denied
sd=0: ACK sent.
sd=0: FIN received.
sd=0: ACK sent.
sd=0: FIN sent.
sd=0: ACK received.

That doesn't look right at all. The proxyget is failing on 
www.stanford.edu. I will assume that the proxy works as intended, so 
something is wrong with my code. However, it also looks like the server 
is getting a valid HTTP request, so it must be an interface invariant 
that I don't know about. I'm passing the data in a way that I believe to 
be correct, but the server (or the proxy!) disagrees.

I can look at the server code all day, but it doesn't tell me much about 
the program's expectations and invariants.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: On the server side
Date: Fri, 23 Feb 2007 18:17:36 -0800
Lines: 13
Distribution: su
Message-ID: <C204E040.8A9C%jpettit@stanford.edu>
References: <paun-349905.23235522022007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172283458 12713 127.0.0.1 (24 Feb 2007 02:17:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: On the server side
Thread-Index: AcdXufL0MTtAqcOtEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11786

> The 54460 is the port number we need to specify for the option
> server:port when we run client, correct?

Yes.
 
> Also, when we run server, server does get to call transport_init with
> the bool is_active set to false, is this correct?

Yes, the server-side call to transport_init() has the is_active argument set
to false.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: simultaneous Connection Synchronization
Date: Fri, 23 Feb 2007 18:18:57 -0800
Lines: 6
Distribution: su
Message-ID: <ero7am$cge$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-98337.stanford.edu
X-Trace: news.Stanford.EDU 1172283542 12814 128.12.159.69 (24 Feb 2007 02:19:02 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11787

Do we need to handle Simultaneous connection sycn ?

 If yes, then how we can test our implementation that it works properly for 
simultaneous conn test ? 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 18:20:43 -0800
Lines: 51
Distribution: su
Message-ID: <C204E0FB.8A9D%jpettit@stanford.edu>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <Xns98E0724CEECCchunkaiwstanfordedu@171.64.14.103> <erm9ud$ctq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172283653 12997 127.0.0.1 (24 Feb 2007 02:20:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: max payload size
Thread-Index: AcdXumJqoQ/iAsOtEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11788

That is correct.  Thanks for saving me some typing!

--Justin


On 2/23/07 12:51 AM, in article erm9ud$ctq$1@news.Stanford.EDU, "Seth
Wright" <orion@cs.stanford.edu> wrote:

> It's my understanding (please someone correct me if I'm wrong) but that we
> should be advertising the 3072 byte window as the local receiver window, but
> then the window for the other end of the connection is that which is
> described in the datagrams received.  (then calculate the sending window on
> the lesser of the congestion window and the remote receive window).  I guess
> all the fixed sizes buy is is that we don't have to worry about changing the
> size of our local receive window based on any internal buffers and we don't
> have to do tcp congestion control (I guess we're one of those rogue
> implementations that ignores it).
> 
> My .02 - I'd love to hear from a TA where I'm wrong as I'm just starting
> this part myself.
> 
> -Seth
> 
> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message
> news:Xns98E0724CEECCchunkaiwstanfordedu@171.64.14.103...
>> for the window size, 3072, i guess my question is more on the lines that
>> since our STCP is suppose to communicate with other servers and is
>> compatible with TCP, i guess i can just ignore those window sizes then
>> right?
>> 
>> 
>> 
>> Justin Pettit <jpettit@stanford.edu> wrote in news:C203D8B1.8A2B%
>> jpettit@stanford.edu:
>> 
>>>> wat does 536 bytes for max payload size mean? does this include the TCP
>>>> header? or just the data?
>>> 
>>> The payload is the data that STCP carries, so it's just the data.
>>> 
>>>> also, it seems like the window size is fixed at 3072... is this true?
>>> 
>>> Please read through the assignment.  This is clearly discussed.
>>> 
>>> --Justin
>>> 
>> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: question on ctx->done
Date: Fri, 23 Feb 2007 18:28:41 -0800
Lines: 3
Distribution: su
Message-ID: <ero7sd$csi$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172284109 13202 128.12.194.72 (24 Feb 2007 02:28:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11789

Should we be writing to ctx->done or is the client code doing it for us?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 18:29:35 -0800
Lines: 22
Distribution: su
Message-ID: <C204E30F.8AA5%jpettit@stanford.edu>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172284179 13334 127.0.0.1 (24 Feb 2007 02:29:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: max payload size
Thread-Index: AcdXu5+C3cqh/MOuEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11790

>>>> wat does 536 bytes for max payload size mean? does this include the TCP
>>>> header? or just the data?
>>> 
>>> The payload is the data that STCP carries, so it's just the data.
>> Hmm... that is annoying.  That means we do not have a known bound on the
>> packet size (TCP options).  Is there a particular size of option fields
>> you would prefer we support, or just over-provision.
> Justin, from the assignment page, I read
> 
>> STCP Packet Format
>> An STCP packet has a maximum size of 536 bytes.
> 
> Is the webpage in error?

I'm either confused or I injected confusion into this discussion.  TCP and
STCP use an MSS of 536 bytes.  If you want to have an MSS greater than 536
bytes in TCP, you use a TCP option.  STCP ignores TCP/STCP options (but must
be able to ignore them gracefully!), so it will never have an MSS greater
than 536 bytes.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp wait for event
Date: Fri, 23 Feb 2007 18:31:27 -0800
Lines: 41
Distribution: su
Message-ID: <C204E37F.8AA6%jpettit@stanford.edu>
References: <Xns98E0178214B2Echunkaiwstanfordedu@171.64.14.103> <Xns98E017DC84ED4chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172284290 13473 127.0.0.1 (24 Feb 2007 02:31:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: stcp wait for event
Thread-Index: AcdXu+JEIOfBOMOvEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11791

From the project description for milestone A:  "Thus, you need not worry
about dropped packets, reordering, retransmissions, timeouts in the code for
this milestone."

--Justin


On 2/23/07 2:20 AM, in article
Xns98E017DC84ED4chunkaiwstanfordedu@171.64.14.103, "Chun Kai Wang"
<chunkaiw@stanford.edu> wrote:

> sorry bad question:
> 
> re-phrase:
> 
> for PA3.A, i can pass NULL right? it's only in part B where we implement
> timeout this is needed right?
> 
> 
> thanks.
> 
> 
> 
> 
> Chun Kai Wang <chunkaiw@stanford.edu> wrote in
> news:Xns98E0178214B2Echunkaiwstanfordedu@171.64.14.103:
> 
>> im confused when to wait for a time in:
>> 
>> 
>> 
>> unsigned int stcp_wait_for_event(mysocket_t             sd,
>>                                  unsigned int           wait_flags,
>>                                  const struct timespec *abstime);
>> 
>> 
>> when should i pass NULL for abstime and when not to?
>> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: behavior of stcp
Date: Fri, 23 Feb 2007 18:33:09 -0800
Lines: 11
Distribution: su
Message-ID: <C204E3E5.8AA7%jpettit@stanford.edu>
References: <Xns98E024088D61Echunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172284392 13511 127.0.0.1 (24 Feb 2007 02:33:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: behavior of stcp
Thread-Index: AcdXvB8QXbWbTsOvEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11792

> say i send a syn packet, so i'm expecting a syn-ack, but i get a packet
> that is neither syn nor ack, what happens?
> 
> do i terminate the connection? or just drop that packet?

Drop the packet.  TCP/STCP will always have the ACK bit set unless it's the
first SYN packet.

--Justin 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: pa3: sequence number wrap around
Date: Fri, 23 Feb 2007 18:36:55 -0800
Lines: 18
Distribution: su
Message-ID: <C204E4C7.8AAA%jpettit@stanford.edu>
References: <ernhgn$lnr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172284619 13599 127.0.0.1 (24 Feb 2007 02:36:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: pa3: sequence number wrap around
Thread-Index: AcdXvKXF5HxcasOvEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11793

> Q11. Do I need to deal with the case that sequence number wrapps around
> (goes over 2^32 and starts from 0 again)?
> 
> A11. No. This does add some complexity into the assignment. You're not
> required to deal with it. We're not going to test your programs to transfer
> 4 gigabytes of data :-) But keep in mind this happens in real TCP.
> 
> Does this mean we have to handle the sequence numbers wrapping around from
> the other side of the connection?  (IOW, our Acks.)  I understood that we
> would be hooking up to real TCP in pa4.

Of course, for completeness you would, but I wouldn't bother for the
purposes of this project.  The chances of this happening in our testing are
pretty minimal, and you can always ask for a regrade.  :)

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: pa3: data during connection establishment
Date: Fri, 23 Feb 2007 18:44:09 -0800
Lines: 18
Distribution: su
Message-ID: <C204E679.8AAC%jpettit@stanford.edu>
References: <ernil0$mtq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172285053 13911 127.0.0.1 (24 Feb 2007 02:44:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: pa3: data during connection establishment
Thread-Index: AcdXvah05zt2qMOwEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11794

> From pg 30, rfc 793, it states that data may be sent during connection
> establishment, although it must not be sent up to user space until reaching
> connection establishment.
> 
> I think that means that the sender of SYN,ACK can send data (although I have
> not seen this on Ethernet traces I have seen).  Do we have to support
> receiving that data?  I would rather not, but it seems reasonable to require
> us to do so.
> 
> However, I would rather not support receiving data on a SYN (no ACK) packet.
> It seems like that would be unwise from a security standpoint, and it would
> complicate the code (delaying sending it up to the ACK before receiving the
> ACK of my SYN,ACK packet).  May we just drop data in this case?
 
Yes, you may ignore data that is in a packet that has the SYN bit set.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp network send
Date: Fri, 23 Feb 2007 18:49:27 -0800
Lines: 9
Distribution: su
Message-ID: <C204E7B7.8AAE%jpettit@stanford.edu>
References: <Xns98E0947BC5A9Cchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172285372 14130 127.0.0.1 (24 Feb 2007 02:49:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: stcp network send
Thread-Index: AcdXvmX/pMSzVsOxEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11795

> if stcp network send fails for some reason, what should i do? tear down the
> connection?????

This shouldn't happen in our testing.  Looking at my implementation from
last year, it looks like I just freed whatever packet I was working on and
went back to work. 

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: question on ctx->done
Date: Fri, 23 Feb 2007 18:50:46 -0800
Lines: 6
Distribution: su
Message-ID: <C204E806.8AB6%jpettit@stanford.edu>
References: <ero7sd$csi$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172285447 14130 127.0.0.1 (24 Feb 2007 02:50:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: question on ctx->done
Thread-Index: AcdXvpUW0+O/dMOxEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11796

> Should we be writing to ctx->done or is the client code doing it for us?

You should do it.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: simultaneous Connection Synchronization
Date: Fri, 23 Feb 2007 18:52:41 -0800
Lines: 10
Distribution: su
Message-ID: <C204E879.8AB9%jpettit@stanford.edu>
References: <ero7am$cge$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172285565 14338 127.0.0.1 (24 Feb 2007 02:52:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: simultaneous Connection Synchronization
Thread-Index: AcdXvtmhGEU45MOyEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11797

> Do we need to handle Simultaneous connection sycn ?
> 
>  If yes, then how we can test our implementation that it works properly for
> simultaneous conn test ?

What is a simultaneous connection sync?

--Justin 


.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Are we allowed to edit transport.h?
Date: Fri, 23 Feb 2007 19:35:32 -0800
Lines: 9
Distribution: su
Message-ID: <erobq4$fus$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172288132 16348 128.12.104.61 (24 Feb 2007 03:35:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11798

In the description for the assignment it states that the *only* file we 
are allowed to modify is transport.c? This would imply that we aren't 
even allowed to add new functions to transport.c. That seems slightly 
Draconian. Moreover, why aren't we allowed to use list manipulation 
code, etc? It seems like implementing the send/recv buffers would be 
much easier if we were allowed to do so.

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Fri, 23 Feb 2007 19:42:21 -0800
Lines: 40
Distribution: su
Message-ID: <eroc5b$g8g$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172288491 16656 127.0.0.1 (24 Feb 2007 03:41:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11799

>>>>> wat does 536 bytes for max payload size mean? does this include the 
>>>>> TCP
>>>>> header? or just the data?
>>>>
>>>> The payload is the data that STCP carries, so it's just the data.
>>> Hmm... that is annoying.  That means we do not have a known bound on the
>>> packet size (TCP options).  Is there a particular size of option fields
>>> you would prefer we support, or just over-provision.
>> Justin, from the assignment page, I read
>>
>>> STCP Packet Format
>>> An STCP packet has a maximum size of 536 bytes.
>>
>> Is the webpage in error?
>
> I'm either confused or I injected confusion into this discussion.  TCP and
> STCP use an MSS of 536 bytes.  If you want to have an MSS greater than 536
> bytes in TCP, you use a TCP option.  STCP ignores TCP/STCP options (but 
> must
> be able to ignore them gracefully!), so it will never have an MSS greater
> than 536 bytes.
The question is over whether the 536 bytes includes the TCP header 
(including options).  If it does not, that makes sizing the receive buffer 
interesting (options)...

You seem to be saying that the 536 bytes do not include the header and 
options.

I quoted a portion of the assignment that says that the header and options 
are included in the 536 bytes.

I am really not sure which one is the correct one.  I hope that it is the 
assignment, but this is one of those details that is easy to get wrong...

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Fri, 23 Feb 2007 19:49:00 -0800
Lines: 18
Distribution: su
Message-ID: <erochp$gfj$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU> <erlgbt$k5d$2@news.Stanford.EDU> <C204BFAE.8A8C%jpettit@stanford.edu> <ero53c$aiq$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172288890 16883 127.0.0.1 (24 Feb 2007 03:48:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11800

> Sending request GET www.stanford.edu HTTP/1.0
> GET www.stanford.edu HTTP/1.0,-1,File does not exist or access denied
Is this message coming from 'server' or 'proxy'?  'proxyget' requests web 
pages from 'proxy'.  'client' requests _files_ from (the current directory 
'server' is running in?).

(If it helps: 'proxy' and 'proxyget' are not the same thing.  'proxyget' is 
a takeoff of 'wget'.  I am not sure why it is called '_proxy_get' at all, 
except that it is supposed to specifically talk to our proxy application.)

I have not run them yet, so I am not sure, but that is my understanding.

HTH,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: simultaneous Connection Synchronization
Date: Fri, 23 Feb 2007 19:57:09 -0800
Lines: 28
Distribution: su
Message-ID: <erod13$goc$1@news.Stanford.EDU>
References: <ero7am$cge$1@news.Stanford.EDU> <C204E879.8AB9%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172289379 17164 127.0.0.1 (24 Feb 2007 03:56:19 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11801

>> Do we need to handle Simultaneous connection sycn ?
>>
>>  If yes, then how we can test our implementation that it works properly 
>> for
>> simultaneous conn test ?
>
> What is a simultaneous connection sync?
It is that straight line between SYN SENT and SYN RCVD.  I am coding to 
handle it, but like many of these boundary cases, I will probably not test 
it.  You have to ask yourself what applications would be trying to initiate 
connections on both ends with the port being known on both ends...  I 
suppose they are out there, but I imagine they are rare.

If you wanted to test it, you could run your stack in a debugger at both 
ends of the connection.  Set a breakpoint right before sending the SYN 
packet and seeing if you ended up in ESTABLISHED.  Of course, that would be 
too clients talking to each other, and they probably would shortly after get 
upset with each other.  This kind of testing works for many of the corner 
cases, but it is extremely man-hour intensive.

Yeah, I am not planning on testing it.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: question on ctx->done
Date: Fri, 23 Feb 2007 19:59:40 -0800
Lines: 13
Distribution: su
Message-ID: <erod5p$grj$1@news.Stanford.EDU>
References: <ero7sd$csi$1@news.Stanford.EDU> <C204E806.8AB6%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172289529 17267 127.0.0.1 (24 Feb 2007 03:58:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11802

>> Should we be writing to ctx->done or is the client code doing it for us?
>
> You should do it.
Do we have to?  Who checks it?  I know I have to deal with 
initial_sequence_number (a whole variable in the state structure that is 
used once!); however, I was planning on mostly ignoring the other two.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Are we allowed to edit transport.h?
Date: Fri, 23 Feb 2007 20:04:54 -0800
Lines: 21
Distribution: su
Message-ID: <erodfj$h2g$1@news.Stanford.EDU>
References: <erobq4$fus$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172289843 17488 127.0.0.1 (24 Feb 2007 04:04:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11803

> In the description for the assignment it states that the *only* file we 
> are allowed to modify is transport.c?
Draconian, but for different reasons.

> This would imply that we aren't  even allowed to add new functions to 
> transport.c.
Huh?  Do you know what #include "" does?  You can declare functions 
whereever you want (or skip declaring them all together if you prefer 
(although that is a bit trickier)).

> Moreover, why aren't we allowed to use list manipulation code, etc?
My queue code is already cut and pasted in there.  It would take quite a bit 
more time that we have to write 50k line files and commit all the rest of 
the sins of industry for this project.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: simultaneous Connection Synchronization
Date: Fri, 23 Feb 2007 20:05:31 -0800
Lines: 22
Distribution: su
Message-ID: <erodii$h3f$1@news.Stanford.EDU>
References: <ero7am$cge$1@news.Stanford.EDU> <C204E879.8AB9%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-98337.stanford.edu
X-Trace: news.Stanford.EDU 1172289938 17519 128.12.159.69 (24 Feb 2007 04:05:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11804

It is  one case of three way handshake, in which both the peers 
simultaniously act in an active mode. It is mentioned in RFC but not in the 
assignment.

 I am just wondering if it is the requirement or not.


"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C204E879.8AB9%jpettit@stanford.edu...
>> Do we need to handle Simultaneous connection sycn ?
>>
>>  If yes, then how we can test our implementation that it works properly 
>> for
>> simultaneous conn test ?
>
> What is a simultaneous connection sync?
>
> --Justin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Mohammad Asif" <mak@slac.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: simultaneous Connection Synchronization
Date: Fri, 23 Feb 2007 20:08:49 -0800
Lines: 36
Distribution: su
Message-ID: <erodoo$h71$1@news.Stanford.EDU>
References: <ero7am$cge$1@news.Stanford.EDU> <C204E879.8AB9%jpettit@stanford.edu> <erod13$goc$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-98337.stanford.edu
X-Trace: news.Stanford.EDU 1172290136 17633 128.12.159.69 (24 Feb 2007 04:08:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11805


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:erod13$goc$1@news.Stanford.EDU...
>>> Do we need to handle Simultaneous connection sycn ?
>>>
>>>  If yes, then how we can test our implementation that it works properly 
>>> for
>>> simultaneous conn test ?
>>
>> What is a simultaneous connection sync?
> It is that straight line between SYN SENT and SYN RCVD.  I am coding to 
> handle it, but like many of these boundary cases, I will probably not test 
> it.  You have to ask yourself what applications would be trying to 
> initiate connections on both ends with the port being known on both 
> ends...  I suppose they are out there, but I imagine they are rare.
>
> If you wanted to test it, you could run your stack in a debugger at both 
> ends of the connection.  Set a breakpoint right before sending the SYN 
> packet and seeing if you ended up in ESTABLISHED.  Of course, that would 
> be too clients talking to each other, and they probably would shortly 
> after get upset with each other.  This kind of testing works for many of 
> the corner cases, but it is extremely man-hour intensive.
>
> Yeah, I am not planning on testing it.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!

thanks Randy,

best regards..
Asif 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on testing our code.
Date: Fri, 23 Feb 2007 20:30:21 -0800
Lines: 26
Distribution: su
Message-ID: <erof0h$i2g$1@news.Stanford.EDU>
References: <erhaln$nuj$1@news.Stanford.EDU> <eri2dg$dd7$1@news.Stanford.EDU> <erjgtf$mh2$1@news.Stanford.EDU> <erjhro$nim$1@news.Stanford.EDU> <erjora$1fa$1@news.Stanford.EDU> <erlgbt$k5d$2@news.Stanford.EDU> <C204BFAE.8A8C%jpettit@stanford.edu> <ero53c$aiq$1@news.Stanford.EDU> <erochp$gfj$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172291409 18512 128.12.194.72 (24 Feb 2007 04:30:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erochp$gfj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11806

.... Doh!

Thanks Randy. :)

-Yangfan

Randy Jennings wrote:
>>Sending request GET www.stanford.edu HTTP/1.0
>>GET www.stanford.edu HTTP/1.0,-1,File does not exist or access denied
> 
> Is this message coming from 'server' or 'proxy'?  'proxyget' requests web 
> pages from 'proxy'.  'client' requests _files_ from (the current directory 
> 'server' is running in?).
> 
> (If it helps: 'proxy' and 'proxyget' are not the same thing.  'proxyget' is 
> a takeoff of 'wget'.  I am not sure why it is called '_proxy_get' at all, 
> except that it is supposed to specifically talk to our proxy application.)
> 
> I have not run them yet, so I am not sure, but that is my understanding.
> 
> HTH,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: More questions on timer.
Date: Fri, 23 Feb 2007 20:32:54 -0800
Lines: 10
Distribution: su
Message-ID: <erof5a$i2g$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172291562 18512 128.12.194.72 (24 Feb 2007 04:32:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11807

1. What is the internal structure of struct timespec? I cannot find a 
description of it in the man pages.

2. What would happen if wait_for_event is called with a time that has 
already passed? Would it: crash? time out immediately? or never time 
out? (As for why I can't just test this myself, please see question 1.)

Thank you.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Are we allowed to edit transport.h?
Date: Fri, 23 Feb 2007 20:34:17 -0800
Lines: 12
Distribution: su
Message-ID: <erof7t$i2g$3@news.Stanford.EDU>
References: <erobq4$fus$1@news.Stanford.EDU> <erodfj$h2g$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172291645 18512 128.12.194.72 (24 Feb 2007 04:34:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erodfj$h2g$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11808

Randy Jennings wrote:

> Huh?  Do you know what #include "" does?  You can declare functions 
> whereever you want (or skip declaring them all together if you prefer 
> (although that is a bit trickier)).

I thought that we cannot add new files either, since the TAs will be 
using their own Makefiles. *I could be wrong though.*

In fact, I'm wrong fairly often. :p

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Fri, 23 Feb 2007 21:12:12 -0800
Lines: 15
Distribution: su
Message-ID: <erohdq$jra$1@news.Stanford.EDU>
References: <erof5a$i2g$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172293882 20330 127.0.0.1 (24 Feb 2007 05:11:22 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11809

No help on 2.  sorry.

> 1. What is the internal structure of struct timespec? I cannot find a 
> description of it in the man pages.
Do a man of gettimeofday and clock_gettime.  The difference seems to be an 
annoyance more than anything.  Why we cannot get the time using the 
structure we would pass into the wait is beyond me (and then being so coy 
about it in the assignment and header file...)

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Are we allowed to edit transport.h?
Date: Fri, 23 Feb 2007 21:57:30 -0800
Lines: 9
Distribution: su
Message-ID: <erok2n$ldj$1@news.Stanford.EDU>
References: <erobq4$fus$1@news.Stanford.EDU> <erodfj$h2g$1@news.Stanford.EDU> <erof7t$i2g$3@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172296599 21939 127.0.0.1 (24 Feb 2007 05:56:39 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11810

>> Huh?  Do you know what #include "" does?  You can declare functions 
>> whereever you want (or skip declaring them all together if you prefer 
>> (although that is a bit trickier)).
>
> I thought that we cannot add new files either, since the TAs will be using 
> their own Makefiles. *I could be wrong though.*
No new files.  Plenty of new functions, though. 


.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Are we allowed to edit transport.h?
Date: Fri, 23 Feb 2007 22:18:51 -0800
Lines: 24
Distribution: su
Message-ID: <erolcb$mdk$1@news.Stanford.EDU>
References: <erobq4$fus$1@news.Stanford.EDU> <erodfj$h2g$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172297931 22964 128.12.104.61 (24 Feb 2007 06:18:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
In-Reply-To: <erodfj$h2g$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11811

Randy Jennings wrote:
>> In the description for the assignment it states that the *only* file we 
>> are allowed to modify is transport.c?
> Draconian, but for different reasons.
> 
>> This would imply that we aren't  even allowed to add new functions to 
>> transport.c.
> Huh?  Do you know what #include "" does?  You can declare functions 
> whereever you want (or skip declaring them all together if you prefer 
> (although that is a bit trickier)).
> 
>> Moreover, why aren't we allowed to use list manipulation code, etc?
> My queue code is already cut and pasted in there.  It would take quite a bit 
> more time that we have to write 50k line files and commit all the rest of 
> the sins of industry for this project.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 
Thanks for the pearls of wisdom. Next time I'll put "RANDY, please don't 
  reply in the subject line."
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: More fun with proxys!
Date: Fri, 23 Feb 2007 22:53:03 -0800
Lines: 35
Distribution: su
Message-ID: <eronc6$nr8$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172299974 24424 128.12.194.72 (24 Feb 2007 06:52:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11812

The proxy seems quite happy to re-transmit packets even without the "-u" 
option. The initial RTT estimate is very low. This causes duplicate 
packets to appear on the link even with an reliable link. (Yes I took 
out the memmoves from my code thank you.)

I'm willing to roll with that. But if the proxy is going to assume that 
the link is unreliable (and re-transmit) then it should at least look at 
the ack numbers I'm sending back. :(

sd=0, seq=3055: Delivered 176 bytes of data to the application.
sd=0, ack=3231: ACK sent.
sd=0, seq=3055: Packet received but dropped.  <-- note the duplicate
sd=0, ack=3231: ACK sent.
sd=0, seq=3231: Delivered 17 bytes of data to the application.
sd=0, ack=3248: ACK sent.
sd=0, seq=3248: Delivered 37 bytes of data to the application.
sd=0, ack=3285: ACK sent.
sd=0, seq=3285: Delivered 122 bytes of data to the application.
sd=0, ack=3407: ACK sent.
sd=0, seq=3285: Packet received but dropped.  <-- note the duplicate
sd=0, ack=3407: ACK sent.
sd=0, seq=3429: Packet received but dropped.
sd=0, ack=3407: ACK sent.                     <-- dude I'm telling you I 
need seq=3429!
sd=0, seq=3448: Packet received but dropped.
sd=0, ack=3407: ACK sent.

I know that I'm supposed to cache the data that I receive out of order. 
I did NOT plan on having to implement this for PART A!

What's going on?

 >_<

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Fri, 23 Feb 2007 23:02:19 -0800
Lines: 42
Distribution: su
Message-ID: <eronti$obp$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172300530 24953 128.12.194.72 (24 Feb 2007 07:02:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eronc6$nr8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11813

Yangfan Wang wrote:
> The proxy seems quite happy to re-transmit packets even without the "-u" 
> option. The initial RTT estimate is very low. This causes duplicate 
> packets to appear on the link even with an reliable link. (Yes I took 
> out the memmoves from my code thank you.)
> 
> I'm willing to roll with that. But if the proxy is going to assume that 
> the link is unreliable (and re-transmit) then it should at least look at 
> the ack numbers I'm sending back. :(
> 
> sd=0, seq=3055: Delivered 176 bytes of data to the application.
> sd=0, ack=3231: ACK sent.
> sd=0, seq=3055: Packet received but dropped.  <-- note the duplicate
> sd=0, ack=3231: ACK sent.
> sd=0, seq=3231: Delivered 17 bytes of data to the application.
> sd=0, ack=3248: ACK sent.
> sd=0, seq=3248: Delivered 37 bytes of data to the application.
> sd=0, ack=3285: ACK sent.
> sd=0, seq=3285: Delivered 122 bytes of data to the application.
> sd=0, ack=3407: ACK sent.
> sd=0, seq=3285: Packet received but dropped.  <-- note the duplicate
> sd=0, ack=3407: ACK sent.
> sd=0, seq=3429: Packet received but dropped.
> sd=0, ack=3407: ACK sent.                     <-- dude I'm telling you I 
> need seq=3429!
> sd=0, seq=3448: Packet received but dropped.
> sd=0, ack=3407: ACK sent.
> 
> I know that I'm supposed to cache the data that I receive out of order. 
> I did NOT plan on having to implement this for PART A!
> 
> What's going on?
> 
>  >_<
> 
> -Yangfan

Addendum: I know that it's mainly caused by a bug in my code, but it 
would be nice if the proxy either assumes a reliable host or does not 
make this assumption, rather than assume reliability only sometimes.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Fri, 23 Feb 2007 23:11:11 -0800
Lines: 57
Distribution: su
Message-ID: <erooe6$oph$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172301062 25393 128.12.194.72 (24 Feb 2007 07:11:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eronti$obp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11814

Actually, I just realized that it's running my code, so it's not 
re-transmitting.

Hmm.

For the proxy, the "-U" option makes the link Unreliable, right? Because 
it looks like packets are being duplicated / dropped on the link. This 
might be due to sleep deprivation on my part, but the packets look okay 
when they're being sent out and come back from the link looking not-so-okay.

-Yangfan

Yangfan Wang wrote:
> Yangfan Wang wrote:
> 
>> The proxy seems quite happy to re-transmit packets even without the 
>> "-u" option. The initial RTT estimate is very low. This causes 
>> duplicate packets to appear on the link even with an reliable link. 
>> (Yes I took out the memmoves from my code thank you.)
>>
>> I'm willing to roll with that. But if the proxy is going to assume 
>> that the link is unreliable (and re-transmit) then it should at least 
>> look at the ack numbers I'm sending back. :(
>>
>> sd=0, seq=3055: Delivered 176 bytes of data to the application.
>> sd=0, ack=3231: ACK sent.
>> sd=0, seq=3055: Packet received but dropped.  <-- note the duplicate
>> sd=0, ack=3231: ACK sent.
>> sd=0, seq=3231: Delivered 17 bytes of data to the application.
>> sd=0, ack=3248: ACK sent.
>> sd=0, seq=3248: Delivered 37 bytes of data to the application.
>> sd=0, ack=3285: ACK sent.
>> sd=0, seq=3285: Delivered 122 bytes of data to the application.
>> sd=0, ack=3407: ACK sent.
>> sd=0, seq=3285: Packet received but dropped.  <-- note the duplicate
>> sd=0, ack=3407: ACK sent.
>> sd=0, seq=3429: Packet received but dropped.
>> sd=0, ack=3407: ACK sent.                     <-- dude I'm telling you 
>> I need seq=3429!
>> sd=0, seq=3448: Packet received but dropped.
>> sd=0, ack=3407: ACK sent.
>>
>> I know that I'm supposed to cache the data that I receive out of 
>> order. I did NOT plan on having to implement this for PART A!
>>
>> What's going on?
>>
>>  >_<
>>
>> -Yangfan
> 
> 
> Addendum: I know that it's mainly caused by a bug in my code, but it 
> would be nice if the proxy either assumes a reliable host or does not 
> make this assumption, rather than assume reliability only sometimes.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Fri, 23 Feb 2007 23:17:48 -0800
Lines: 46
Distribution: su
Message-ID: <erooqj$oul$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172301459 25557 128.12.194.72 (24 Feb 2007 07:17:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erooe6$oph$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11815

Here are some print outs (just so this whole thread does not solely 
consist of my ranting like a lunatic):

Proxy:

....
sd=1, seq=3104: Sent 536 bytes of data to the network.
sd=1, seq=3640: Sent 244 bytes of data to the network.
sd=1, ack=1348: ACK received.
sd=1, ack=1884: ACK received.
sd=1, ack=2420: ACK received.
sd=1, ack=2928: ACK received.
sd=1, seq=3884: Sent 492 bytes of data to the network.
sd=1, seq=4376: Sent 536 bytes of data to the network.
sd=1, seq=4912: Sent 536 bytes of data to the network.
sd=1, seq=5448: Sent 376 bytes of data to the network.
sd=1, seq=5824: Sent 176 bytes of data to the network.
....

Client:

sd=0, ack=3104: ACK sent.
sd=0, seq=3104: Delivered 536 bytes of data to the application.
sd=0, ack=3640: ACK sent.
sd=0, seq=3640: Delivered 244 bytes of data to the application.
sd=0, ack=3884: ACK sent.
sd=0, seq=3884: Delivered 492 bytes of data to the application.
sd=0, ack=4376: ACK sent.
sd=0, seq=3884: Packet of size 492 bytes received but dropped. actual 
rcv_base=4376.
sd=0, ack=4376: ACK sent.
sd=0, seq=4912: Packet of size 536 bytes received but dropped. actual 
rcv_base=4376.
sd=0, ack=4376: ACK sent.
sd=0, seq=5448: Packet of size 376 bytes received but dropped. actual 
rcv_base=4376.
sd=0, ack=4376: ACK sent.

The proxy sent packets with beginning sequence numbers 3884, 4376, and 
4912, in order.

The client saw packets with sequence numbers 3884, then 3884 again, and 
then 4912. It looks like the second packet got turned into the first 
packet somehow. Obviously, this very much confuses my program.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Natasha Gude <ngude@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Fri, 23 Feb 2007 23:24:52 -0800
Lines: 50
Distribution: su
Message-ID: <erop85$p6j$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172301893 25811 127.0.0.1 (24 Feb 2007 07:24:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erooqj$oul$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11816

Yangfan Wang wrote:
> Here are some print outs (just so this whole thread does not solely 
> consist of my ranting like a lunatic):
> 
> Proxy:
> 
> ...
> sd=1, seq=3104: Sent 536 bytes of data to the network.
> sd=1, seq=3640: Sent 244 bytes of data to the network.
> sd=1, ack=1348: ACK received.
> sd=1, ack=1884: ACK received.
> sd=1, ack=2420: ACK received.
> sd=1, ack=2928: ACK received.
> sd=1, seq=3884: Sent 492 bytes of data to the network.
> sd=1, seq=4376: Sent 536 bytes of data to the network.
> sd=1, seq=4912: Sent 536 bytes of data to the network.
> sd=1, seq=5448: Sent 376 bytes of data to the network.
> sd=1, seq=5824: Sent 176 bytes of data to the network.
> ...
> 
> Client:
> 
> sd=0, ack=3104: ACK sent.
> sd=0, seq=3104: Delivered 536 bytes of data to the application.
> sd=0, ack=3640: ACK sent.
> sd=0, seq=3640: Delivered 244 bytes of data to the application.
> sd=0, ack=3884: ACK sent.
> sd=0, seq=3884: Delivered 492 bytes of data to the application.
> sd=0, ack=4376: ACK sent.
> sd=0, seq=3884: Packet of size 492 bytes received but dropped. actual 
> rcv_base=4376.
> sd=0, ack=4376: ACK sent.
> sd=0, seq=4912: Packet of size 536 bytes received but dropped. actual 
> rcv_base=4376.
> sd=0, ack=4376: ACK sent.
> sd=0, seq=5448: Packet of size 376 bytes received but dropped. actual 
> rcv_base=4376.
> sd=0, ack=4376: ACK sent.
> 
> The proxy sent packets with beginning sequence numbers 3884, 4376, and 
> 4912, in order.
> 
> The client saw packets with sequence numbers 3884, then 3884 again, and 
> then 4912. It looks like the second packet got turned into the first 
> packet somehow. Obviously, this very much confuses my program.
> 
> -Yangfan

This happened to me too, but when I switched in my own proxy it worked 
fine...
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Fri, 23 Feb 2007 23:26:02 -0800
Lines: 21
Distribution: su
Message-ID: <eropa1$pdk$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172301953 26036 128.12.194.72 (24 Feb 2007 07:25:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erooqj$oul$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11817

....

 From the class website:

"You're going to find it helpful to force the network layer to be 
unreliable. To emulate the behavior of a congested multi-path network, 
setting the  is_reliable parameter to false when creating a socket (use 
the -U flag when running the program) will cause the network layer to 
randomly reorder and drop packets. You'll see an example of how this is 
done in our dummy client/server code."

This information appears to be wrong. For me at least, setting the -U 
flag makes the proxy's network *reliable*. Maybe a typo in the proxy code?

This should teach me a lesson in checking with the source code rather 
than just assuming that the assignment spec is always infallible, only 
the proxy source code isn't available yet. :p

I'm gonna take a break now...

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: outgoing buffer
Date: Sat, 24 Feb 2007 08:31:31 +0000 (UTC)
Organization: Your Company
Lines: 2
Distribution: su
Message-ID: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172305891 1951 128.12.22.217 (24 Feb 2007 08:31:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11818

for part 3.A, we don't really need to implement the outgoing buffer right? 
since we know the packets are in order and no drops.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: application write
Date: Sat, 24 Feb 2007 09:01:08 +0000 (UTC)
Organization: Your Company
Lines: 10
Distribution: su
Message-ID: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172307668 3579 128.12.22.217 (24 Feb 2007 09:01:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11819

say the application does mywrite() with 100 bytes

but my advertised receiver window is only 10 bytes,

thus, my STCp only sends 10 bytes.

what happens to the other 90 bytes? and do i still get "app_data" in the 
next sctp_wait_for_evnt so that i can transfer the next 90 bytes?

how do i ensure i get the ack-packet before the next app_data event??? 
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: gethostbyname_r failing
Date: Sat, 24 Feb 2007 01:36:30 -0800
Lines: 12
Distribution: su
Message-ID: <erp0uv$54d$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172309791 5261 128.12.104.61 (24 Feb 2007 09:36:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11820

I'm trying to test out the sample dummy client/server on own machine but 
the client keeps failing with:

gethostbyname_r: Numerical result out of range

in network_io_socket.c : _network_get_interface_ip()

I'm assuming this is VNS related stuff. What could cause this to happen? 
It appears to behave normally if I test on the myths.

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 05:36:46 -0500
Lines: 78
Distribution: su
Message-ID: <erp4g0$8am$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172313408 8534 127.0.0.1 (24 Feb 2007 10:36:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11821

I have two questions about this, but first some quotes from the assignment:

An STCP packet has a maximum size of 536 bytes. It has the same header 
format as TCP. The header format is defined in transport.h as follows

Also from the assignment:
Options
The following rules apply for handling TCP options:

  a.. STCP does not generate options in the packets it sends.
  b.. STCP ignores options in any packets sent by a peer. It must be capable 
of correctly handling packets that include options.
Which means we have to handle incoming packets that have options set - but 
do not have to abide by what those options are - we can just ignore them.

Now, the TCP header description I find on networksorcery 
(http://www.networksorcery.com/enp/protocol/tcp.htm) says that there are 32 
bits after the header and before the data that are for options and padding. 
What it does say about options is:
Options. 0 to 44 bytes.
Options occupy space at the end of the TCP header. All options are included 
in the checksum. An option may begin on any byte boundary. The TCP header 
must be padded with zeros to make the header length a multiple of 32 bits.

Now, I have two questions:
1) the data offset field in TCP -> that's the offset to the actual data, 
meaning past the options?
2) if there are 44 bytes of options in some random TCP datagram I receive, 
it is still the case that the maximum size of an STCP datagram is 536 bytes 
since that is the maximum MSS, right?


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:eroc5b$g8g$1@news.Stanford.EDU...
>>>>>> wat does 536 bytes for max payload size mean? does this include the 
>>>>>> TCP
>>>>>> header? or just the data?
>>>>>
>>>>> The payload is the data that STCP carries, so it's just the data.
>>>> Hmm... that is annoying.  That means we do not have a known bound on 
>>>> the
>>>> packet size (TCP options).  Is there a particular size of option fields
>>>> you would prefer we support, or just over-provision.
>>> Justin, from the assignment page, I read
>>>
>>>> STCP Packet Format
>>>> An STCP packet has a maximum size of 536 bytes.
>>>
>>> Is the webpage in error?
>>
>> I'm either confused or I injected confusion into this discussion.  TCP 
>> and
>> STCP use an MSS of 536 bytes.  If you want to have an MSS greater than 
>> 536
>> bytes in TCP, you use a TCP option.  STCP ignores TCP/STCP options (but 
>> must
>> be able to ignore them gracefully!), so it will never have an MSS greater
>> than 536 bytes.
> The question is over whether the 536 bytes includes the TCP header 
> (including options).  If it does not, that makes sizing the receive buffer 
> interesting (options)...
>
> You seem to be saying that the 536 bytes do not include the header and 
> options.
>
> I quoted a portion of the assignment that says that the header and options 
> are included in the 536 bytes.
>
> I am really not sure which one is the correct one.  I hope that it is the 
> assignment, but this is one of those details that is easy to get wrong...
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 05:39:40 -0500
Lines: 98
Distribution: su
Message-ID: <erp4ld$8ct$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU> <erp4g0$8am$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172313581 8605 127.0.0.1 (24 Feb 2007 10:39:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11822

Ah, I think I answered the first of my questions myself with the following 
from transport.h:
/* starting byte position of data in TCP packet p */

#define TCP_DATA_START(p) (((STCPHeader *) p)->th_off * sizeof(uint32_t))


/* length of options (in bytes) in TCP packet p */

#define TCP_OPTIONS_LEN(p) (TCP_DATA_START(p) - sizeof(struct tcphdr))



"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:erp4g0$8am$1@news.Stanford.EDU...
>I have two questions about this, but first some quotes from the assignment:
>
> An STCP packet has a maximum size of 536 bytes. It has the same header 
> format as TCP. The header format is defined in transport.h as follows
>
> Also from the assignment:
> Options
> The following rules apply for handling TCP options:
>
>  a.. STCP does not generate options in the packets it sends.
>  b.. STCP ignores options in any packets sent by a peer. It must be 
> capable of correctly handling packets that include options.
> Which means we have to handle incoming packets that have options set - but 
> do not have to abide by what those options are - we can just ignore them.
>
> Now, the TCP header description I find on networksorcery 
> (http://www.networksorcery.com/enp/protocol/tcp.htm) says that there are 
> 32 bits after the header and before the data that are for options and 
> padding. What it does say about options is:
> Options. 0 to 44 bytes.
> Options occupy space at the end of the TCP header. All options are 
> included in the checksum. An option may begin on any byte boundary. The 
> TCP header must be padded with zeros to make the header length a multiple 
> of 32 bits.
>
> Now, I have two questions:
> 1) the data offset field in TCP -> that's the offset to the actual data, 
> meaning past the options?
> 2) if there are 44 bytes of options in some random TCP datagram I receive, 
> it is still the case that the maximum size of an STCP datagram is 536 
> bytes since that is the maximum MSS, right?
>
>
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:eroc5b$g8g$1@news.Stanford.EDU...
>>>>>>> wat does 536 bytes for max payload size mean? does this include the 
>>>>>>> TCP
>>>>>>> header? or just the data?
>>>>>>
>>>>>> The payload is the data that STCP carries, so it's just the data.
>>>>> Hmm... that is annoying.  That means we do not have a known bound on 
>>>>> the
>>>>> packet size (TCP options).  Is there a particular size of option 
>>>>> fields
>>>>> you would prefer we support, or just over-provision.
>>>> Justin, from the assignment page, I read
>>>>
>>>>> STCP Packet Format
>>>>> An STCP packet has a maximum size of 536 bytes.
>>>>
>>>> Is the webpage in error?
>>>
>>> I'm either confused or I injected confusion into this discussion.  TCP 
>>> and
>>> STCP use an MSS of 536 bytes.  If you want to have an MSS greater than 
>>> 536
>>> bytes in TCP, you use a TCP option.  STCP ignores TCP/STCP options (but 
>>> must
>>> be able to ignore them gracefully!), so it will never have an MSS 
>>> greater
>>> than 536 bytes.
>> The question is over whether the 536 bytes includes the TCP header 
>> (including options).  If it does not, that makes sizing the receive 
>> buffer interesting (options)...
>>
>> You seem to be saying that the 536 bytes do not include the header and 
>> options.
>>
>> I quoted a portion of the assignment that says that the header and 
>> options are included in the 536 bytes.
>>
>> I am really not sure which one is the correct one.  I hope that it is the 
>> assignment, but this is one of those details that is easy to get wrong...
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 06:00:38 -0500
Lines: 131
Distribution: su
Message-ID: <erp5sn$9jb$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU> <erp4g0$8am$1@news.Stanford.EDU> <erp4ld$8ct$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172314840 9835 127.0.0.1 (24 Feb 2007 11:00:40 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11823

Okay, here's what I see as the conflicting parts of the assignment 
description:
STCP Packet Format
An STCP packet has a maximum size of 536 bytes. It has the same header 
format as TCP.

AND

Data Packets
The following rules apply to STCP data packets:

  a.. The maximum payload size is 536 bytes.


I'm guessing the actual answer is the latter - the payload size is up to 536 
bytes but it comes back to Randy's question: are the options included as 
part of the header or the payload in making these calculations.  Going back 
to networksorcery, it seems like the TCP spec says they're part of the 
payload.  I say this because both things are colored green in the little 
diagram they have and the rest of the TCP header is white.  :)

Sorry if I've been a bit discombobulated here, but it's late.

Seth


"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:erp4ld$8ct$1@news.Stanford.EDU...
> Ah, I think I answered the first of my questions myself with the following 
> from transport.h:
> /* starting byte position of data in TCP packet p */
>
> #define TCP_DATA_START(p) (((STCPHeader *) p)->th_off * sizeof(uint32_t))
>
>
> /* length of options (in bytes) in TCP packet p */
>
> #define TCP_OPTIONS_LEN(p) (TCP_DATA_START(p) - sizeof(struct tcphdr))
>
>
>
> "Seth Wright" <orion@cs.stanford.edu> wrote in message 
> news:erp4g0$8am$1@news.Stanford.EDU...
>>I have two questions about this, but first some quotes from the 
>>assignment:
>>
>> An STCP packet has a maximum size of 536 bytes. It has the same header 
>> format as TCP. The header format is defined in transport.h as follows
>>
>> Also from the assignment:
>> Options
>> The following rules apply for handling TCP options:
>>
>>  a.. STCP does not generate options in the packets it sends.
>>  b.. STCP ignores options in any packets sent by a peer. It must be 
>> capable of correctly handling packets that include options.
>> Which means we have to handle incoming packets that have options set - 
>> but do not have to abide by what those options are - we can just ignore 
>> them.
>>
>> Now, the TCP header description I find on networksorcery 
>> (http://www.networksorcery.com/enp/protocol/tcp.htm) says that there are 
>> 32 bits after the header and before the data that are for options and 
>> padding. What it does say about options is:
>> Options. 0 to 44 bytes.
>> Options occupy space at the end of the TCP header. All options are 
>> included in the checksum. An option may begin on any byte boundary. The 
>> TCP header must be padded with zeros to make the header length a multiple 
>> of 32 bits.
>>
>> Now, I have two questions:
>> 1) the data offset field in TCP -> that's the offset to the actual data, 
>> meaning past the options?
>> 2) if there are 44 bytes of options in some random TCP datagram I 
>> receive, it is still the case that the maximum size of an STCP datagram 
>> is 536 bytes since that is the maximum MSS, right?
>>
>>
>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
>> news:eroc5b$g8g$1@news.Stanford.EDU...
>>>>>>>> wat does 536 bytes for max payload size mean? does this include the 
>>>>>>>> TCP
>>>>>>>> header? or just the data?
>>>>>>>
>>>>>>> The payload is the data that STCP carries, so it's just the data.
>>>>>> Hmm... that is annoying.  That means we do not have a known bound on 
>>>>>> the
>>>>>> packet size (TCP options).  Is there a particular size of option 
>>>>>> fields
>>>>>> you would prefer we support, or just over-provision.
>>>>> Justin, from the assignment page, I read
>>>>>
>>>>>> STCP Packet Format
>>>>>> An STCP packet has a maximum size of 536 bytes.
>>>>>
>>>>> Is the webpage in error?
>>>>
>>>> I'm either confused or I injected confusion into this discussion.  TCP 
>>>> and
>>>> STCP use an MSS of 536 bytes.  If you want to have an MSS greater than 
>>>> 536
>>>> bytes in TCP, you use a TCP option.  STCP ignores TCP/STCP options (but 
>>>> must
>>>> be able to ignore them gracefully!), so it will never have an MSS 
>>>> greater
>>>> than 536 bytes.
>>> The question is over whether the 536 bytes includes the TCP header 
>>> (including options).  If it does not, that makes sizing the receive 
>>> buffer interesting (options)...
>>>
>>> You seem to be saying that the 536 bytes do not include the header and 
>>> options.
>>>
>>> I quoted a portion of the assignment that says that the header and 
>>> options are included in the 536 bytes.
>>>
>>> I am really not sure which one is the correct one.  I hope that it is 
>>> the assignment, but this is one of those details that is easy to get 
>>> wrong...
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> The squirrels are your friends!
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 04:38:02 -0800
Lines: 11
Distribution: su
Message-ID: <erpbj1$gc4$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU> <erp4g0$8am$1@news.Stanford.EDU> <erp4ld$8ct$1@news.Stanford.EDU> <erp5sn$9jb$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172320673 16772 128.12.194.72 (24 Feb 2007 12:37:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erp5sn$9jb$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11824

Seth,

your confusion might be due the use of the term "max segment size" in 
the assignment. It's (surprise!) not the same thing as the max 
transmission unit.

Please read page 230 of Kurose if you haven't already.

Disclaimer: I'm not a TA.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: question on ctx->done
Date: Sat, 24 Feb 2007 16:22:27 +0000 (UTC)
Lines: 22
Distribution: su
Message-ID: <erpoo3$723$1@news.Stanford.EDU>
References: <ero7sd$csi$1@news.Stanford.EDU> <C204E806.8AB6%jpettit@stanford.edu> <erod5p$grj$1@news.Stanford.EDU>
NNTP-Posting-Host: myth22.stanford.edu
X-Trace: news.Stanford.EDU 1172334147 7235 171.64.15.36 (24 Feb 2007 16:22:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11825

Hi Randy,

If you don't set ctx->done then how else are you planning to come out of the
control_loop.

Thanks,
Dinesh

Randy Jennings <randyj@stanford.edu> wrote:
> >> Should we be writing to ctx->done or is the client code doing it for us?
> >
> > You should do it.
> Do we have to?  Who checks it?  I know I have to deal with 
> initial_sequence_number (a whole variable in the state structure that is 
> used once!); however, I was planning on mostly ignoring the other two.

> Sincerely,
> Randy Jennings

> The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Sat, 24 Feb 2007 13:31:44 -0500
Lines: 25
Distribution: su
Message-ID: <erq0ag$f0h$1@news.Stanford.EDU>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1172341904 15377 127.0.0.1 (24 Feb 2007 18:31:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11826

I'd say look at the signature for the method of app_recv:
/* receive data from the application (sent to us using mywrite()) */

size_t stcp_app_recv(mysocket_t sd, void *dst, size_t max_len);

You can specify the maximum amount of data to read.  Remember how when we 
used write on a socket in the past, we weren't guaranteed that all of the 
data would be consumed?  I think this is how that happens.

Seth

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103...
> say the application does mywrite() with 100 bytes
>
> but my advertised receiver window is only 10 bytes,
>
> thus, my STCp only sends 10 bytes.
>
> what happens to the other 90 bytes? and do i still get "app_data" in the
> next sctp_wait_for_evnt so that i can transfer the next 90 bytes?
>
> how do i ensure i get the ack-packet before the next app_data event??? 


.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: which timeouts to implement for milestone A
Date: Sat, 24 Feb 2007 14:42:30 -0800
Lines: 21
Distribution: su
Message-ID: <pan.2007.02.24.22.42.30.41800@cs.stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172356433 28258 128.12.186.133 (24 Feb 2007 22:33:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11827

Hi,

I am confused about what timeouts we need to deal with for milestone A.

From the milestone description, I interpret that we do not have to deal
with timeouts related to packet retransmissions. In other words, when I
send out a packet, I can always assume that it will get to the destination
and that I will get an ACK back (assuming the packets sequence
number range is in the receiver window) right? This means that I never
need to buffer the data I am sending until I get the ACK right?

When we call the client telling it to connect to an ip:port where a server
is not running, our transport_init is still invoked. Are we expected to
deal with this situation? Since the network_send function will block, it
seems like we would need to start another thread which would kill the
thread trying to send the SYN if it didn't do so before a certain timeout...

Thanks for the clarifications,
Paolo


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Are we allowed to edit transport.h?
Date: Sat, 24 Feb 2007 15:58:46 -0800
Lines: 18
Distribution: su
Message-ID: <C2061136.8B1F%jpettit@stanford.edu>
References: <erobq4$fus$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172361528 2376 127.0.0.1 (24 Feb 2007 23:58:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Are we allowed to edit transport.h?
Thread-Index: AcdYb7hM9pRbfsRiEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11828

> In the description for the assignment it states that the *only* file we
> are allowed to modify is transport.c? This would imply that we aren't
> even allowed to add new functions to transport.c. That seems slightly
> Draconian. Moreover, why aren't we allowed to use list manipulation
> code, etc? It seems like implementing the send/recv buffers would be
> much easier if we were allowed to do so.

As others have mentioned, you can add additional functions and declarations
to your transport.c file.  In fact, you would be docked style points if you
did not break your new code out into different functions!

We just want to be able to drop your transport.c into our own setup.  When I
did the assignment last year, I had an entire linked list library at the
beginning of transport.c.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: outgoing buffer
Date: Sat, 24 Feb 2007 16:11:38 -0800
Lines: 5
Distribution: su
Message-ID: <erqk7r$36o$1@news.Stanford.EDU>
References: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362299 3288 128.12.133.106 (25 Feb 2007 00:11:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11829

Chun Kai Wang wrote:
> for part 3.A, we don't really need to implement the outgoing buffer right? 
> since we know the packets are in order and no drops.

Right. You only will need an incoming buffer.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Sat, 24 Feb 2007 16:13:03 -0800
Lines: 29
Distribution: su
Message-ID: <erqkag$36o$2@news.Stanford.EDU>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103> <erq0ag$f0h$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362384 3288 128.12.133.106 (25 Feb 2007 00:13:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erq0ag$f0h$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11830

Seth Wright wrote:
> I'd say look at the signature for the method of app_recv:
> /* receive data from the application (sent to us using mywrite()) */
> 
> size_t stcp_app_recv(mysocket_t sd, void *dst, size_t max_len);
> 
> You can specify the maximum amount of data to read.  Remember how when we 
> used write on a socket in the past, we weren't guaranteed that all of the 
> data would be consumed?  I think this is how that happens.
> 
> Seth
> 
> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
> news:Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103...
>> say the application does mywrite() with 100 bytes
>>
>> but my advertised receiver window is only 10 bytes,
>>
>> thus, my STCp only sends 10 bytes.
>>
>> what happens to the other 90 bytes? and do i still get "app_data" in the
>> next sctp_wait_for_evnt so that i can transfer the next 90 bytes?
>>
>> how do i ensure i get the ack-packet before the next app_data event??? 
> 
> 

Seth is right. You can choose how much data you pull from the 
application. The rest will be buffered for next time.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: simultaneous Connection Synchronization
Date: Sat, 24 Feb 2007 16:13:06 -0800
Lines: 13
Distribution: su
Message-ID: <C2061492.8B22%jpettit@stanford.edu>
References: <ero7am$cge$1@news.Stanford.EDU> <C204E879.8AB9%jpettit@stanford.edu> <erodii$h3f$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362393 3321 127.0.0.1 (25 Feb 2007 00:13:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: simultaneous Connection Synchronization
Thread-Index: AcdYcbjm95s/psRkEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11831

> It is  one case of three way handshake, in which both the peers
> simultaniously act in an active mode. It is mentioned in RFC but not in the
> assignment.
> 
>  I am just wondering if it is the requirement or not.

Huh, I've never seen that used in practice.  And I've looked at a lot of TCP
handshakes.  Don't worry about it for the assignment.

Thanks for pointing it out, though!

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gethostbyname_r failing
Date: Sat, 24 Feb 2007 16:13:56 -0800
Lines: 16
Distribution: su
Message-ID: <erqkc5$36o$3@news.Stanford.EDU>
References: <erp0uv$54d$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362437 3288 128.12.133.106 (25 Feb 2007 00:13:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erp0uv$54d$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11832

Matt Page wrote:
> I'm trying to test out the sample dummy client/server on own machine but 
> the client keeps failing with:
> 
> gethostbyname_r: Numerical result out of range
> 
> in network_io_socket.c : _network_get_interface_ip()
> 
> I'm assuming this is VNS related stuff. What could cause this to happen? 
> It appears to behave normally if I test on the myths.
> 
> Thanks,
> Matt

What is your machine configuration, and what is gethostbyname_r dieing 
because of? What are the inputs when the method calls aborts?
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: which timeouts to implement for milestone A
Date: Sat, 24 Feb 2007 16:17:48 -0800
Lines: 17
Distribution: su
Message-ID: <erqkjd$3d5$1@news.Stanford.EDU>
References: <pan.2007.02.24.22.42.30.41800@cs.stanford.edu>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362669 3493 128.12.133.106 (25 Feb 2007 00:17:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <pan.2007.02.24.22.42.30.41800@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11833

> From the milestone description, I interpret that we do not have to deal
> with timeouts related to packet retransmissions. In other words, when I
> send out a packet, I can always assume that it will get to the destination
> and that I will get an ACK back (assuming the packets sequence
> number range is in the receiver window) right? This means that I never
> need to buffer the data I am sending until I get the ACK right?
Yes, you are guaranteed that the data will get there. Also, the ACK you 
send back is guaranteed to get back to the sender. So no buffer needed.
> 
> When we call the client telling it to connect to an ip:port where a server
> is not running, our transport_init is still invoked. Are we expected to
> deal with this situation? Since the network_send function will block, it
> seems like we would need to start another thread which would kill the
> thread trying to send the SYN if it didn't do so before a certain timeout...
Are you sure you are invoked? What happens if you try to do a 
network_send? Does it return -1 or something? I don't remember this 
being too big of an issue.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sat, 24 Feb 2007 16:22:22 -0800
Lines: 33
Distribution: su
Message-ID: <erqks0$3lm$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172362944 3766 128.12.133.106 (25 Feb 2007 00:22:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eropa1$pdk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11834

OOPS!! You are entirely correct. There was a typo in the reference 
solution. The -U makes it reliable and without it is unreliable. Don't 
make this mistake!

I've posted an updated tarball. If you don't want the whole tarball, the 
new proxy.a is here:

http://www.stanford.edu/class/cs244a/hw3/proxy.a

Sorry for that. Thanks for noticing!

Yangfan Wang wrote:
> ...
> 
>  From the class website:
> 
> "You're going to find it helpful to force the network layer to be 
> unreliable. To emulate the behavior of a congested multi-path network, 
> setting the  is_reliable parameter to false when creating a socket (use 
> the -U flag when running the program) will cause the network layer to 
> randomly reorder and drop packets. You'll see an example of how this is 
> done in our dummy client/server code."
> 
> This information appears to be wrong. For me at least, setting the -U 
> flag makes the proxy's network *reliable*. Maybe a typo in the proxy code?
> 
> This should teach me a lesson in checking with the source code rather 
> than just assuming that the assignment spec is always infallible, only 
> the proxy source code isn't available yet. :p
> 
> I'm gonna take a break now...
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: which timeouts to implement for milestone A
Date: Sat, 24 Feb 2007 16:47:50 -0800
Lines: 22
Distribution: su
Message-ID: <pan.2007.02.25.00.47.48.398343@cs.stanford.edu>
References: <pan.2007.02.24.22.42.30.41800@cs.stanford.edu> <erqkjd$3d5$1@news.Stanford.EDU>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172363953 4429 128.12.186.133 (25 Feb 2007 00:39:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11835

On Sat, 24 Feb 2007 16:17:48 -0800, Paul Tarjan (TA) wrote:

>> From the milestone description, I interpret that we do not have to deal
>> with timeouts related to packet retransmissions. In other words, when I
>> send out a packet, I can always assume that it will get to the destination
>> and that I will get an ACK back (assuming the packets sequence
>> number range is in the receiver window) right? This means that I never
>> need to buffer the data I am sending until I get the ACK right?
> Yes, you are guaranteed that the data will get there. Also, the ACK you 
> send back is guaranteed to get back to the sender. So no buffer needed.
>> 
>> When we call the client telling it to connect to an ip:port where a server
>> is not running, our transport_init is still invoked. Are we expected to
>> deal with this situation? Since the network_send function will block, it
>> seems like we would need to start another thread which would kill the
>> thread trying to send the SYN if it didn't do so before a certain timeout...
> Are you sure you are invoked? What happens if you try to do a 
> network_send? Does it return -1 or something? I don't remember this 
> being too big of an issue.

network_send will just block

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Peer window size changes
Date: Sat, 24 Feb 2007 17:41:14 -0700
Lines: 14
Distribution: su
Message-ID: <erqlvb$4ii$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172364075 4690 127.0.0.1 (25 Feb 2007 00:41:15 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11836

How tightly do we have to track the size of the peer window?  If it can 
change every time the peer sends a packet, then it really isn't possible to 
always know what it is, since some incoming packets are in flight, some are 
buffered in the network layer, etc.  All we can do is sample it and make a 
decision based on our most recent sample.

In view of that, is it okay for our "send buffer" routine to just sample the 
peer's window size when we start our routine and assume it won't change for 
the duration of the send routine (even though it could)?

Thanks,
Kevin


.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Closing the Connection
Date: Sat, 24 Feb 2007 17:07:51 -0800
Lines: 12
Distribution: su
Message-ID: <paun-7ACA2B.17075124022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172365677 4927 128.12.135.184 (25 Feb 2007 01:07:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11837

I am able to establish the connection, pass the appropriate seq #s, ack 
#s and data from client/server to server/client, the file rcvd gets 
created and is the same as the file on the server side.

The problem is that i never get a call on the server side to close its 
socket, so myclose never gets called, thus I can never send a FIN packet 
since stcp_wait_for_event will never return due to APP_CLOSE_REQUESTED.

Am i missing something?  Once the server is done sending the file, they 
will close their socket correct?  Any help is appreciated.

Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: debugging interaction with real tcp
Date: Sat, 24 Feb 2007 17:17:29 -0800
Lines: 8
Distribution: su
Message-ID: <pan.2007.02.25.01.17.29.320931@cs.stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172365732 5881 128.12.186.133 (25 Feb 2007 01:08:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11838

Hi,

Are there any recommendations on how to debug the interaction with 'real
tcp'? I have converted my proxy to use the mysock interface and the
destination webserver doesn't seem to be reacting to my SYNs.

Thanks,
Paolo
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Closing the Connection
Date: Sat, 24 Feb 2007 17:18:58 -0800
Lines: 17
Distribution: su
Message-ID: <pan.2007.02.25.01.18.55.953793@cs.stanford.edu>
References: <paun-7ACA2B.17075124022007@nntp.stanford.edu>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172365821 5881 128.12.186.133 (25 Feb 2007 01:10:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11839

On Sat, 24 Feb 2007 17:07:51 -0800, Filip Paun wrote:

> I am able to establish the connection, pass the appropriate seq #s, ack 
> #s and data from client/server to server/client, the file rcvd gets 
> created and is the same as the file on the server side.
> 
> The problem is that i never get a call on the server side to close its 
> socket, so myclose never gets called, thus I can never send a FIN packet 
> since stcp_wait_for_event will never return due to APP_CLOSE_REQUESTED.
> 
> Am i missing something?  Once the server is done sending the file, they 
> will close their socket correct?  Any help is appreciated.
> 
> Filip

maybe you are forgetting to call stcp_fin_received ?

.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gethostbyname_r failing
Date: Sat, 24 Feb 2007 17:45:54 -0800
Lines: 29
Distribution: su
Message-ID: <erqpoh$7ap$1@news.Stanford.EDU>
References: <erp0uv$54d$1@news.Stanford.EDU> <erqkc5$36o$3@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172367953 7513 128.12.104.61 (25 Feb 2007 01:45:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
In-Reply-To: <erqkc5$36o$3@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11840

Paul Tarjan (TA) wrote:
> Matt Page wrote:
>> I'm trying to test out the sample dummy client/server on own machine 
>> but the client keeps failing with:
>>
>> gethostbyname_r: Numerical result out of range
>>
>> in network_io_socket.c : _network_get_interface_ip()
>>
>> I'm assuming this is VNS related stuff. What could cause this to 
>> happen? It appears to behave normally if I test on the myths.
>>
>> Thanks,
>> Matt
> 
> What is your machine configuration, and what is gethostbyname_r dieing 
> because of? What are the inputs when the method calls aborts?
It looks like a issue on my end. _network_get_interface_ip first calls
gethostname()(returns "puffin-mp.stanford.edu" correctly) and then calls 
gethostbyname() on the hostname from the previous call. Adding a call to 
herror() reveals that gethostbyname_r is failing because it can't find 
"puffin-mp.stanford.edu".

So, I guess this is failing because my machine isn't properly set up 
with Stanford's DNS? I can probably fix this with the HOSTALIASES 
environment variable but that seems kind of hackish. Any suggestions?

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: stcp_network_recv
Date: Sun, 25 Feb 2007 01:47:18 +0000 (UTC)
Lines: 9
Distribution: su
Message-ID: <erqpr6$6c5$1@news.Stanford.EDU>
NNTP-Posting-Host: myth2.stanford.edu
X-Trace: news.Stanford.EDU 1172368038 6533 171.64.15.175 (25 Feb 2007 01:47:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11841



In stcp_network_recv(sd, dst, max_len) :
the data copied into dst is the packet along with the TCP headers?
In that case do we have to ensure that max_len will be large enough
to accomodate any TCP packet(with options).

Thanks
Dina 
.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: stcp_network_recv
Date: Sun, 25 Feb 2007 01:54:26 +0000 (UTC)
Lines: 14
Distribution: su
Message-ID: <erqq8i$7nv$1@news.Stanford.EDU>
References: <erqpr6$6c5$1@news.Stanford.EDU>
NNTP-Posting-Host: myth2.stanford.edu
X-Trace: news.Stanford.EDU 1172368466 7935 171.64.15.175 (25 Feb 2007 01:54:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11842

Dina Thomas <dinat@stanford.edu> wrote:

Specifically if there is 10bytes available in the receiver 
window and a packet of size 100bytes arrives, then what is the 
expected behaviour?


> In stcp_network_recv(sd, dst, max_len) :
> the data copied into dst is the packet along with the TCP headers?
> In that case do we have to ensure that max_len will be large enough
> to accomodate any TCP packet(with options).

> Thanks
> Dina 
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gethostbyname_r failing
Date: Sat, 24 Feb 2007 17:56:25 -0800
Lines: 22
Distribution: su
Message-ID: <erqqca$7mv$1@news.Stanford.EDU>
References: <erp0uv$54d$1@news.Stanford.EDU> <erqkc5$36o$3@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172368586 7903 128.12.104.61 (25 Feb 2007 01:56:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
In-Reply-To: <erqkc5$36o$3@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11843

Paul Tarjan (TA) wrote:
> Matt Page wrote:
>> I'm trying to test out the sample dummy client/server on own machine 
>> but the client keeps failing with:
>>
>> gethostbyname_r: Numerical result out of range
>>
>> in network_io_socket.c : _network_get_interface_ip()
>>
>> I'm assuming this is VNS related stuff. What could cause this to 
>> happen? It appears to behave normally if I test on the myths.
>>
>> Thanks,
>> Matt
> 
> What is your machine configuration, and what is gethostbyname_r dieing 
> because of? What are the inputs when the method calls aborts?
Adding a static map between my ip and the name returned by gethostname 
fixed the issue. Another thing, nslookup returns multiple ip addresses
for the specified hostname which could cause a problem.

Anyway, all is well!
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 18:18:26 -0800
Lines: 19
Distribution: su
Message-ID: <C20631F2.8B35%jpettit@stanford.edu>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU> <erp4g0$8am$1@news.Stanford.EDU> <erp4ld$8ct$1@news.Stanford.EDU> <erp5sn$9jb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172369909 9085 127.0.0.1 (25 Feb 2007 02:18:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: max payload size
Thread-Index: AcdYgzsreaUWnsR2Edum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11844

>   a.. The maximum payload size is 536 bytes.
> 
> 
> I'm guessing the actual answer is the latter - the payload size is up to 536
> bytes but it comes back to Randy's question: are the options included as
> part of the header or the payload in making these calculations.  Going back
> to networksorcery, it seems like the TCP spec says they're part of the
> payload.  I say this because both things are colored green in the little
> diagram they have and the rest of the TCP header is white.  :)

Correct.  The payload is 536 bytes, not the entire packet.  My reading is
that the options are not included in the MSS.  Here's the relevant part from
Network Sorcery:

    ...if the MSS option is not used, 536 bytes. The size does not
    include the TCP headers and options.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Sat, 24 Feb 2007 18:23:26 -0800
Lines: 14
Distribution: su
Message-ID: <C206331E.8B3A%jpettit@stanford.edu>
References: <erof5a$i2g$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172370209 9382 127.0.0.1 (25 Feb 2007 02:23:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: More questions on timer.
Thread-Index: AcdYg+37LKhlXMR3Edum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11845

> 1. What is the internal structure of struct timespec? I cannot find a
> description of it in the man pages.

You can use Google or look in "/usr/include".  Specifically, you may want to
look at "/usr/include/time.h".

> 2. What would happen if wait_for_event is called with a time that has
> already passed? Would it: crash? time out immediately? or never time
> out? (As for why I can't just test this myself, please see question 1.)

Now that you have the definition, you should be able to try it out...

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Peer window size changes
Date: Sat, 24 Feb 2007 18:24:45 -0800
Lines: 17
Distribution: su
Message-ID: <erqs1e$95m$1@news.Stanford.EDU>
References: <erqlvb$4ii$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172370286 9398 128.12.133.106 (25 Feb 2007 02:24:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erqlvb$4ii$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11846

Kevin Hart wrote:
> How tightly do we have to track the size of the peer window?  If it can 
> change every time the peer sends a packet, then it really isn't possible to 
> always know what it is, since some incoming packets are in flight, some are 
> buffered in the network layer, etc.  All we can do is sample it and make a 
> decision based on our most recent sample.
> 
> In view of that, is it okay for our "send buffer" routine to just sample the 
> peer's window size when we start our routine and assume it won't change for 
> the duration of the send routine (even though it could)?
> 
> Thanks,
> Kevin
> 
> 
I'm confused. Don't you just have a fixed window of size 3072 bytes? 
Thats the max number of bytes that can be in transit at any one time.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: debugging interaction with real tcp
Date: Sat, 24 Feb 2007 18:26:03 -0800
Lines: 15
Distribution: su
Message-ID: <erqs3t$95m$2@news.Stanford.EDU>
References: <pan.2007.02.25.01.17.29.320931@cs.stanford.edu>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172370365 9398 128.12.133.106 (25 Feb 2007 02:26:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <pan.2007.02.25.01.17.29.320931@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11847

Paolo wrote:
> Hi,
> 
> Are there any recommendations on how to debug the interaction with 'real
> tcp'? I have converted my proxy to use the mysock interface and the
> destination webserver doesn't seem to be reacting to my SYNs.
> 
> Thanks,
> Paolo

I don't know how clear we made this.

Your proxy will only be STCP on ONE side of the connection. The side 
that talks to proxyget. The other side should just be normal TCP talking 
to the webserver.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp_network_recv
Date: Sat, 24 Feb 2007 18:28:37 -0800
Lines: 16
Distribution: su
Message-ID: <erqs8m$95m$3@news.Stanford.EDU>
References: <erqpr6$6c5$1@news.Stanford.EDU> <erqq8i$7nv$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172370518 9398 128.12.133.106 (25 Feb 2007 02:28:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erqq8i$7nv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11848

Dina Thomas wrote:
> Dina Thomas <dinat@stanford.edu> wrote:
> 
> Specifically if there is 10bytes available in the receiver 
> window and a packet of size 100bytes arrives, then what is the 
> expected behaviour?
> 

 From the assignment:

Received data which has a sequence number higher than that of the last 
byte of the receiver window is discarded and remains unacknowledged.

Note that received data may cross either end of the current receiver 
window; in this case, the data is split into two parts and each part is 
processed appropriately.
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Peer window size changes
Date: Sat, 24 Feb 2007 20:21:38 -0700
Lines: 31
Distribution: su
Message-ID: <erqvc5$bo9$1@news.Stanford.EDU>
References: <erqlvb$4ii$1@news.Stanford.EDU> <erqs1e$95m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172373701 12041 127.0.0.1 (25 Feb 2007 03:21:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11849

Well, my receive window is fixed at 3072.  And if my communication peer is 
always just another STCP implementation like mine, then I guess the 
advertised peer window will always be 3072 in ever packet I receive.  But 
the protocol spec says you're always supposed to adjust for dynamic peer 
window sizes and not send too much.  I thought you were going to test for 
stuff like that.  No?

--Kevin


"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:erqs1e$95m$1@news.Stanford.EDU...
> Kevin Hart wrote:
>> How tightly do we have to track the size of the peer window?  If it can 
>> change every time the peer sends a packet, then it really isn't possible 
>> to always know what it is, since some incoming packets are in flight, 
>> some are buffered in the network layer, etc.  All we can do is sample it 
>> and make a decision based on our most recent sample.
>>
>> In view of that, is it okay for our "send buffer" routine to just sample 
>> the peer's window size when we start our routine and assume it won't 
>> change for the duration of the send routine (even though it could)?
>>
>> Thanks,
>> Kevin
>>
>>
> I'm confused. Don't you just have a fixed window of size 3072 bytes? Thats 
> the max number of bytes that can be in transit at any one time. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: max payload size
Date: Sat, 24 Feb 2007 19:49:35 -0800
Lines: 12
Distribution: su
Message-ID: <err0ut$cnh$1@news.Stanford.EDU>
References: <Xns98DFDA99391E8chunkaiwstanfordedu@171.64.14.103> <C203D8B1.8A2B%jpettit@stanford.edu> <ernj7b$nfg$1@news.Stanford.EDU> <ero2h4$7v1$1@news.Stanford.EDU> <C204E30F.8AA5%jpettit@stanford.edu> <eroc5b$g8g$1@news.Stanford.EDU> <erp4g0$8am$1@news.Stanford.EDU> <erp4ld$8ct$1@news.Stanford.EDU> <erp5sn$9jb$1@news.Stanford.EDU> <C20631F2.8B35%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172375325 13041 127.0.0.1 (25 Feb 2007 03:48:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11850

Thanks Seth for pointing out the conflicting parts of the assignment (one 
saying the header was included in the MSS, and the other saying it was not).

So we have to pad our packet buffers to make sure we can receive a header 
and 44 bytes of options.  Can do.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: STCP Behaviour
Date: Sat, 24 Feb 2007 20:21:01 -0800
Lines: 83
Distribution: su
Message-ID: <paun-499265.20210124022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172377267 14386 128.12.135.184 (25 Feb 2007 04:21:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11851

TAs PLEASE READ THIS, i have no idea what's going on. 

I have run into very weird behavior of the stub code provided.  I am on 
myth7, i have newest tar ball provided.  My transport.c file has the 
lines of code given with the following added lines:


/* ADDED BY ME */
#define FOO \
  printf("FOO");
int establish_active_connection(mysocket_t sd, context_t *ctx);
/***************/

void transport_init(mysocket_t sd, bool_t is_active)
{
    context_t *ctx;
    ctx = (context_t *) calloc(1, sizeof(context_t));
    assert(ctx);

    generate_initial_seq_num(ctx);

    /* ADDED BY ME */
    if(is_active) {
        errno = establish_active_connection(sd, ctx);
    }
    /****************/

    ctx->connection_state = CSTATE_ESTABLISHED;
    stcp_unblock_application(sd);

    control_loop(sd, ctx);

    /* do any cleanup here */
    free(ctx);
}
 

/* ADDED BY ME */
int establish_active_connection(mysocket_t sd, context_t *ctx) {
   printf("BEFORE\n"); 
   stcp_network_send(sd, "fooo", 20); 
   printf("AFTER\n");
  return 0;
}
/***************/

  When i run this, the client spits out the following error:
BEFORE
client: stcp_api.c:212: ssize_t stcp_network_send(mysocket_t, const 
void*, size_t, ...): Assertion `packet_len + next_len <= sizeof(packet)' 
failed.
Abort

thus i can not send data across the network, what's happening is that 
the stcp_network_send fails to see that there is only one buffer sent to 
it, and it thinks there several more such buffers (i.e. it thinks it got 
call as stcp_network_send(sd, buf1, len1, buf2, len2 ...) instead of 
(sd, buf1, len1).

  The craziest thing is that when i add the following line:
FOO  (i.e. it's predfine to just print out to the screen 'foo')
in the function transport_init as follows:

if(is_active) {
        FOO;
        errno = establish_active_connection(sd, ctx);
}

   i get the following output from client:
FOO
BEFORE
AFTER

thus it has been able to send the data.



I am not doing anything else, i haven't added any other lines then as 
specified above, i haven't changed any files, etc.     

Any information on this would be very helpful.
Thank you in advance.
Filip
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP Behaviour
Date: Sat, 24 Feb 2007 20:37:20 -0800
Lines: 93
Distribution: su
Message-ID: <paun-9D77C0.20372024022007@nntp.stanford.edu>
References: <paun-499265.20210124022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172378245 14878 128.12.135.184 (25 Feb 2007 04:37:25 GMT)
X-Complaints-To: news@news.stanford.edu
Posted-And-Mailed: yes
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11852

Nevermind, i misunderstood the api for stcp_network_send, the last 
argument to the procedure has to be null terminated.





In article <paun-499265.20210124022007@nntp.stanford.edu>,
 Filip Paun <paun@stanford.edu> wrote:

> TAs PLEASE READ THIS, i have no idea what's going on. 
> 
> I have run into very weird behavior of the stub code provided.  I am on 
> myth7, i have newest tar ball provided.  My transport.c file has the 
> lines of code given with the following added lines:
> 
> 
> /* ADDED BY ME */
> #define FOO \
>   printf("FOO");
> int establish_active_connection(mysocket_t sd, context_t *ctx);
> /***************/
> 
> void transport_init(mysocket_t sd, bool_t is_active)
> {
>     context_t *ctx;
>     ctx = (context_t *) calloc(1, sizeof(context_t));
>     assert(ctx);
> 
>     generate_initial_seq_num(ctx);
> 
>     /* ADDED BY ME */
>     if(is_active) {
>         errno = establish_active_connection(sd, ctx);
>     }
>     /****************/
> 
>     ctx->connection_state = CSTATE_ESTABLISHED;
>     stcp_unblock_application(sd);
> 
>     control_loop(sd, ctx);
> 
>     /* do any cleanup here */
>     free(ctx);
> }
>  
> 
> /* ADDED BY ME */
> int establish_active_connection(mysocket_t sd, context_t *ctx) {
>    printf("BEFORE\n"); 
>    stcp_network_send(sd, "fooo", 20); 
>    printf("AFTER\n");
>   return 0;
> }
> /***************/
> 
>   When i run this, the client spits out the following error:
> BEFORE
> client: stcp_api.c:212: ssize_t stcp_network_send(mysocket_t, const 
> void*, size_t, ...): Assertion `packet_len + next_len <= sizeof(packet)' 
> failed.
> Abort
> 
> thus i can not send data across the network, what's happening is that 
> the stcp_network_send fails to see that there is only one buffer sent to 
> it, and it thinks there several more such buffers (i.e. it thinks it got 
> call as stcp_network_send(sd, buf1, len1, buf2, len2 ...) instead of 
> (sd, buf1, len1).
> 
>   The craziest thing is that when i add the following line:
> FOO  (i.e. it's predfine to just print out to the screen 'foo')
> in the function transport_init as follows:
> 
> if(is_active) {
>         FOO;
>         errno = establish_active_connection(sd, ctx);
> }
> 
>    i get the following output from client:
> FOO
> BEFORE
> AFTER
> 
> thus it has been able to send the data.
> 
> 
> 
> I am not doing anything else, i haven't added any other lines then as 
> specified above, i haven't changed any files, etc.     
> 
> Any information on this would be very helpful.
> Thank you in advance.
> Filip
.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP Behaviour
Date: Sat, 24 Feb 2007 20:37:37 -0800
Lines: 93
Distribution: su
Message-ID: <paun-AB02A5.20373724022007@nntp.stanford.edu>
References: <paun-499265.20210124022007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1172378263 14878 128.12.135.184 (25 Feb 2007 04:37:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:11853

Nevermind, i misunderstood the api for stcp_network_send, the last 
argument to the procedure has to be null terminated.





In article <paun-499265.20210124022007@nntp.stanford.edu>,
 Filip Paun <paun@stanford.edu> wrote:

> TAs PLEASE READ THIS, i have no idea what's going on. 
> 
> I have run into very weird behavior of the stub code provided.  I am on 
> myth7, i have newest tar ball provided.  My transport.c file has the 
> lines of code given with the following added lines:
> 
> 
> /* ADDED BY ME */
> #define FOO \
>   printf("FOO");
> int establish_active_connection(mysocket_t sd, context_t *ctx);
> /***************/
> 
> void transport_init(mysocket_t sd, bool_t is_active)
> {
>     context_t *ctx;
>     ctx = (context_t *) calloc(1, sizeof(context_t));
>     assert(ctx);
> 
>     generate_initial_seq_num(ctx);
> 
>     /* ADDED BY ME */
>     if(is_active) {
>         errno = establish_active_connection(sd, ctx);
>     }
>     /****************/
> 
>     ctx->connection_state = CSTATE_ESTABLISHED;
>     stcp_unblock_application(sd);
> 
>     control_loop(sd, ctx);
> 
>     /* do any cleanup here */
>     free(ctx);
> }
>  
> 
> /* ADDED BY ME */
> int establish_active_connection(mysocket_t sd, context_t *ctx) {
>    printf("BEFORE\n"); 
>    stcp_network_send(sd, "fooo", 20); 
>    printf("AFTER\n");
>   return 0;
> }
> /***************/
> 
>   When i run this, the client spits out the following error:
> BEFORE
> client: stcp_api.c:212: ssize_t stcp_network_send(mysocket_t, const 
> void*, size_t, ...): Assertion `packet_len + next_len <= sizeof(packet)' 
> failed.
> Abort
> 
> thus i can not send data across the network, what's happening is that 
> the stcp_network_send fails to see that there is only one buffer sent to 
> it, and it thinks there several more such buffers (i.e. it thinks it got 
> call as stcp_network_send(sd, buf1, len1, buf2, len2 ...) instead of 
> (sd, buf1, len1).
> 
>   The craziest thing is that when i add the following line:
> FOO  (i.e. it's predfine to just print out to the screen 'foo')
> in the function transport_init as follows:
> 
> if(is_active) {
>         FOO;
>         errno = establish_active_connection(sd, ctx);
> }
> 
>    i get the following output from client:
> FOO
> BEFORE
> AFTER
> 
> thus it has been able to send the data.
> 
> 
> 
> I am not doing anything else, i haven't added any other lines then as 
> specified above, i haven't changed any files, etc.     
> 
> Any information on this would be very helpful.
> Thank you in advance.
> Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Eric J Park <ejpark@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: STCP Behaviour
Date: Sun, 25 Feb 2007 04:56:34 +0000 (UTC)
Lines: 94
Distribution: su
Message-ID: <err4u2$edv$1@news.Stanford.EDU>
References: <paun-499265.20210124022007@nntp.stanford.edu>
NNTP-Posting-Host: myth4.stanford.edu
X-Trace: news.Stanford.EDU 1172379394 14783 171.64.15.185 (25 Feb 2007 04:56:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11854

Hi Filip,

You should add a null terminator to the arguments list for
stcp_network_send, like this:

   stcp_network_send(sd, "fooo", 20, NULL);

Hope this helps,
Eric

Filip Paun <paun@stanford.edu> wrote:
> TAs PLEASE READ THIS, i have no idea what's going on. 

> I have run into very weird behavior of the stub code provided.  I am on 
> myth7, i have newest tar ball provided.  My transport.c file has the 
> lines of code given with the following added lines:


> /* ADDED BY ME */
> #define FOO \
>   printf("FOO");
> int establish_active_connection(mysocket_t sd, context_t *ctx);
> /***************/

> void transport_init(mysocket_t sd, bool_t is_active)
> {
>     context_t *ctx;
>     ctx = (context_t *) calloc(1, sizeof(context_t));
>     assert(ctx);

>     generate_initial_seq_num(ctx);

>     /* ADDED BY ME */
>     if(is_active) {
>         errno = establish_active_connection(sd, ctx);
>     }
>     /****************/

>     ctx->connection_state = CSTATE_ESTABLISHED;
>     stcp_unblock_application(sd);

>     control_loop(sd, ctx);

>     /* do any cleanup here */
>     free(ctx);
> }
>  

> /* ADDED BY ME */
> int establish_active_connection(mysocket_t sd, context_t *ctx) {
>    printf("BEFORE\n"); 
>    stcp_network_send(sd, "fooo", 20); 
>    printf("AFTER\n");
>   return 0;
> }
> /***************/

>   When i run this, the client spits out the following error:
> BEFORE
> client: stcp_api.c:212: ssize_t stcp_network_send(mysocket_t, const 
> void*, size_t, ...): Assertion `packet_len + next_len <= sizeof(packet)' 
> failed.
> Abort

> thus i can not send data across the network, what's happening is that 
> the stcp_network_send fails to see that there is only one buffer sent to 
> it, and it thinks there several more such buffers (i.e. it thinks it got 
> call as stcp_network_send(sd, buf1, len1, buf2, len2 ...) instead of 
> (sd, buf1, len1).

>   The craziest thing is that when i add the following line:
> FOO  (i.e. it's predfine to just print out to the screen 'foo')
> in the function transport_init as follows:

> if(is_active) {
>         FOO;
>         errno = establish_active_connection(sd, ctx);
> }

>    i get the following output from client:
> FOO
> BEFORE
> AFTER

> thus it has been able to send the data.



> I am not doing anything else, i haven't added any other lines then as 
> specified above, i haven't changed any files, etc.     

> Any information on this would be very helpful.
> Thank you in advance.
> Filip
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Peer window size changes
Date: Sat, 24 Feb 2007 21:34:35 -0800
Lines: 14
Distribution: su
Message-ID: <err75d$gl5$1@news.Stanford.EDU>
References: <erqlvb$4ii$1@news.Stanford.EDU> <erqs1e$95m$1@news.Stanford.EDU> <erqvc5$bo9$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172381677 17061 128.12.133.106 (25 Feb 2007 05:34:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erqvc5$bo9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11855

Kevin Hart wrote:
> Well, my receive window is fixed at 3072.  And if my communication peer is 
> always just another STCP implementation like mine, then I guess the 
> advertised peer window will always be 3072 in ever packet I receive.  But 
> the protocol spec says you're always supposed to adjust for dynamic peer 
> window sizes and not send too much.  I thought you were going to test for 
> stuff like that.  No?

The sender has to make sure NOT to send too much data. Also keep the 
amount of outstanding data less than the advertised window.  Use the 
most current advertised windows size for any decision.

YOUR receiver will always advertise 3072, and throw away other data if 
too much comes in.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP Behaviour
Date: Sat, 24 Feb 2007 21:36:50 -0800
Lines: 4
Distribution: su
Message-ID: <err79k$gl5$2@news.Stanford.EDU>
References: <paun-499265.20210124022007@nntp.stanford.edu> <err4u2$edv$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172381812 17061 128.12.133.106 (25 Feb 2007 05:36:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <err4u2$edv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11856

Thanks Eric! By helping others you are helping yourself. Everyone should 
think about and try to answer other people's questions. You'll get a 
better understanding about the assignment, you'll help a fellow student, 
and you'll make my job easier :)
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: outgoing buffer
Date: Sun, 25 Feb 2007 01:33:08 -0500
Lines: 19
Distribution: su
Message-ID: <erraj4$j1a$1@news.Stanford.EDU>
References: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103> <erqk7r$36o$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172385189 19498 127.0.0.1 (25 Feb 2007 06:33:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11857

Actually, for 3A, do we even need an incoming buffer?  It doesn't seem like 
we do because:
a) we know that the data is arriving in order
b) the interface for passing the data up for myread() consumption always 
takes all data we give it.
to that end, is there a reason, other than preparing for the 3.B to have in 
input buffer?

-Seth

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:erqk7r$36o$1@news.Stanford.EDU...
> Chun Kai Wang wrote:
>> for part 3.A, we don't really need to implement the outgoing buffer 
>> right? since we know the packets are in order and no drops.
>
> Right. You only will need an incoming buffer. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: outgoing buffer
Date: Sat, 24 Feb 2007 23:36:41 -0800
Lines: 11
Distribution: su
Message-ID: <erreaa$l5s$1@news.Stanford.EDU>
References: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103> <erqk7r$36o$1@news.Stanford.EDU> <erraj4$j1a$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172389002 21692 128.12.133.106 (25 Feb 2007 07:36:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erraj4$j1a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11858

Seth Wright wrote:
> Actually, for 3A, do we even need an incoming buffer?  It doesn't seem like 
> we do because:
> a) we know that the data is arriving in order
> b) the interface for passing the data up for myread() consumption always 
> takes all data we give it.
> to that end, is there a reason, other than preparing for the 3.B to have in 
> input buffer?
> 

You are right. You don't need it until 3.B
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 03:20:55 -0500
Lines: 49
Distribution: su
Message-ID: <errgt8$pt3$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172391656 26531 127.0.0.1 (25 Feb 2007 08:20:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11859

Okay, just to be absolutely explicit:
1) running it with -U makes it reliable?
2) When I run it with -U I get one packet twice and another gets munged.
3) When I run it without -U, all the packets go through nicely BUT I don't 
get any application close requests, from on either the client (proxyget) OR 
the server (proxy).  Is there something I'm doing wrong?
4) I downloaded the proxy code after the post below, so I'm certain I have 
the most up to date proxy code.

Seth

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:erqks0$3lm$1@news.Stanford.EDU...
> OOPS!! You are entirely correct. There was a typo in the reference 
> solution. The -U makes it reliable and without it is unreliable. Don't 
> make this mistake!
>
> I've posted an updated tarball. If you don't want the whole tarball, the 
> new proxy.a is here:
>
> http://www.stanford.edu/class/cs244a/hw3/proxy.a
>
> Sorry for that. Thanks for noticing!
>
> Yangfan Wang wrote:
>> ...
>>
>>  From the class website:
>>
>> "You're going to find it helpful to force the network layer to be 
>> unreliable. To emulate the behavior of a congested multi-path network, 
>> setting the  is_reliable parameter to false when creating a socket (use 
>> the -U flag when running the program) will cause the network layer to 
>> randomly reorder and drop packets. You'll see an example of how this is 
>> done in our dummy client/server code."
>>
>> This information appears to be wrong. For me at least, setting the -U 
>> flag makes the proxy's network *reliable*. Maybe a typo in the proxy 
>> code?
>>
>> This should teach me a lesson in checking with the source code rather 
>> than just assuming that the assignment spec is always infallible, only 
>> the proxy source code isn't available yet. :p
>>
>> I'm gonna take a break now...
>>
>> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 03:38:02 -0500
Lines: 64
Distribution: su
Message-ID: <errhtc$qee$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172392684 27086 127.0.0.1 (25 Feb 2007 08:38:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11860

Okay, so it still seems to me that -U makes it unreliable.  BUT I have made 
progress on part 3 from my earlier post.  It seems that for the urls: 
http://www.yahoo.com/, http://www.stanford.edu/, http://www.google.com/, I 
don't get an Application close requested event.  For http://www.pfoo.com/, 
http://www.zdnet.com/, http://en.wikipedia.org/, though, I do.  Am I able to 
chalk this up to the first set of web servers not actually following through 
on http/1.0 semantics?  Does anyone else using the reference web proxy 
actually get app close requested events for the first three urls?

-Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:errgt8$pt3$1@news.Stanford.EDU...
> Okay, just to be absolutely explicit:
> 1) running it with -U makes it reliable?
> 2) When I run it with -U I get one packet twice and another gets munged.
> 3) When I run it without -U, all the packets go through nicely BUT I don't 
> get any application close requests, from on either the client (proxyget) 
> OR the server (proxy).  Is there something I'm doing wrong?
> 4) I downloaded the proxy code after the post below, so I'm certain I have 
> the most up to date proxy code.
>
> Seth
>
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:erqks0$3lm$1@news.Stanford.EDU...
>> OOPS!! You are entirely correct. There was a typo in the reference 
>> solution. The -U makes it reliable and without it is unreliable. Don't 
>> make this mistake!
>>
>> I've posted an updated tarball. If you don't want the whole tarball, the 
>> new proxy.a is here:
>>
>> http://www.stanford.edu/class/cs244a/hw3/proxy.a
>>
>> Sorry for that. Thanks for noticing!
>>
>> Yangfan Wang wrote:
>>> ...
>>>
>>>  From the class website:
>>>
>>> "You're going to find it helpful to force the network layer to be 
>>> unreliable. To emulate the behavior of a congested multi-path network, 
>>> setting the  is_reliable parameter to false when creating a socket (use 
>>> the -U flag when running the program) will cause the network layer to 
>>> randomly reorder and drop packets. You'll see an example of how this is 
>>> done in our dummy client/server code."
>>>
>>> This information appears to be wrong. For me at least, setting the -U 
>>> flag makes the proxy's network *reliable*. Maybe a typo in the proxy 
>>> code?
>>>
>>> This should teach me a lesson in checking with the source code rather 
>>> than just assuming that the assignment spec is always infallible, only 
>>> the proxy source code isn't available yet. :p
>>>
>>> I'm gonna take a break now...
>>>
>>> -Yangfan
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 01:25:10 -0800
Lines: 12
Distribution: su
Message-ID: <errkkt$rui$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172395485 28626 127.0.0.1 (25 Feb 2007 09:24:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <errhtc$qee$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11861

I tried all of those URLs with the reference proxy and it closed every 
time except in the case of http://www.stanford.edu, where it works 
roughly 3 out of every 4 times.  Strange!  http://www.google.com and 
http://www.yahoo.com work every time.  I didn't try the others more than 
once.  I'd say it's something to do with to the proxy implementation...

As for the -U flag, I think the confusion is that -U is SUPPOSED to make 
it unreliable, but there was a mistake in the first release that had the 
opposite semantics.  It's been fixed so if you have the latest proxy it 
should work as expected and you're seeing the correct behavior.

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Peer window size changes
Date: Sun, 25 Feb 2007 01:26:19 -0800
Lines: 48
Distribution: su
Message-ID: <errknu$rvc$1@news.Stanford.EDU>
References: <erqlvb$4ii$1@news.Stanford.EDU> <erqs1e$95m$1@news.Stanford.EDU> <erqvc5$bo9$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172395582 28652 128.12.197.229 (25 Feb 2007 09:26:22 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11862

Yeah you are right... though I don't understand the part of "it could change 
during the send routine".  If you are sending a packet from the application, 
I don't think your receiver window will change until you get another 
incoming packet from the network, right? It's true that while you are 
sending an application packet, some packet might be queing up in your local 
buffer, but there is nothing you can do until you process that incoming 
packet which will happen only after you have finished sending the app 
packet.


Tom


"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:erqvc5$bo9$1@news.Stanford.EDU...
> Well, my receive window is fixed at 3072.  And if my communication peer is 
> always just another STCP implementation like mine, then I guess the 
> advertised peer window will always be 3072 in ever packet I receive.  But 
> the protocol spec says you're always supposed to adjust for dynamic peer 
> window sizes and not send too much.  I thought you were going to test for 
> stuff like that.  No?
>
> --Kevin
>
>
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
> news:erqs1e$95m$1@news.Stanford.EDU...
>> Kevin Hart wrote:
>>> How tightly do we have to track the size of the peer window?  If it can 
>>> change every time the peer sends a packet, then it really isn't possible 
>>> to always know what it is, since some incoming packets are in flight, 
>>> some are buffered in the network layer, etc.  All we can do is sample it 
>>> and make a decision based on our most recent sample.
>>>
>>> In view of that, is it okay for our "send buffer" routine to just sample 
>>> the peer's window size when we start our routine and assume it won't 
>>> change for the duration of the send routine (even though it could)?
>>>
>>> Thanks,
>>> Kevin
>>>
>>>
>> I'm confused. Don't you just have a fixed window of size 3072 bytes? 
>> Thats the max number of bytes that can be in transit at any one time.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 04:44:30 -0500
Lines: 25
Distribution: su
Message-ID: <errlpu$shs$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172396670 29244 127.0.0.1 (25 Feb 2007 09:44:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11863

Hmm.  Mine just never closes for many of them.  I can see the </html> come 
through the other end and if the response has a content-length it seems to 
close correctly all the time - so I'm pretty sure I'm proxying all the 
information back.  In the end, my proxy just sits in wait_for_event and 
doesn't get told of anything.  I'll have to take another look at that.
Thanks for the clarification on -U.

Seth

"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:errkkt$rui$1@news.Stanford.EDU...
>I tried all of those URLs with the reference proxy and it closed every time 
>except in the case of http://www.stanford.edu, where it works roughly 3 out 
>of every 4 times.  Strange!  http://www.google.com and http://www.yahoo.com 
>work every time.  I didn't try the others more than once.  I'd say it's 
>something to do with to the proxy implementation...
>
> As for the -U flag, I think the confusion is that -U is SUPPOSED to make 
> it unreliable, but there was a mistake in the first release that had the 
> opposite semantics.  It's been fixed so if you have the latest proxy it 
> should work as expected and you're seeing the correct behavior.
>
> Greg 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 05:41:07 -0500
Lines: 34
Distribution: su
Message-ID: <errp43$1dr$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172400068 1467 127.0.0.1 (25 Feb 2007 10:41:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11864

Fine.  I knew I shouldn't have said anything, but I figure out what the bug 
in my code is and now my connections close correctly.  Oy.

Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:errlpu$shs$1@news.Stanford.EDU...
> Hmm.  Mine just never closes for many of them.  I can see the </html> come 
> through the other end and if the response has a content-length it seems to 
> close correctly all the time - so I'm pretty sure I'm proxying all the 
> information back.  In the end, my proxy just sits in wait_for_event and 
> doesn't get told of anything.  I'll have to take another look at that.
> Thanks for the clarification on -U.
>
> Seth
>
> "Greg Nelson" <grourk@stanford.edu> wrote in message 
> news:errkkt$rui$1@news.Stanford.EDU...
>>I tried all of those URLs with the reference proxy and it closed every 
>>time except in the case of http://www.stanford.edu, where it works roughly 
>>3 out of every 4 times.  Strange!  http://www.google.com and 
>>http://www.yahoo.com work every time.  I didn't try the others more than 
>>once.  I'd say it's something to do with to the proxy implementation...
>>
>> As for the -U flag, I think the confusion is that -U is SUPPOSED to make 
>> it unreliable, but there was a mistake in the first release that had the 
>> opposite semantics.  It's been fixed so if you have the latest proxy it 
>> should work as expected and you're seeing the correct behavior.
>>
>> Greg
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 02:52:41 -0800
Lines: 5
Distribution: su
Message-ID: <errpou$23m$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172400734 2166 127.0.0.1 (25 Feb 2007 10:52:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <errp43$1dr$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11865

What was the bug, if you don't mind my asking?  Maybe I have something 
similar going on...  Or are you getting the 3 out of 4 thing with 
www.stanford.edu as well, now?

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 06:07:42 -0500
Lines: 17
Distribution: su
Message-ID: <errqlv$3or$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172401663 3867 127.0.0.1 (25 Feb 2007 11:07:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11866

The "bug" was that I didn't read the documentation for stcp_wait_for_event 
closely enough and was only expecting the result to be one of the possible 
flags, not an OR of multiple events.  It's amazing that everything worked as 
well as it did.  Ah, well.  As for the stanford one, it seems to work for me 
now, too.

-Seth

"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:errpou$23m$1@news.Stanford.EDU...
> What was the bug, if you don't mind my asking?  Maybe I have something 
> similar going on...  Or are you getting the 3 out of 4 thing with 
> www.stanford.edu as well, now?
>
> Greg 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Sun, 25 Feb 2007 04:32:43 -0800
Lines: 38
Distribution: su
Message-ID: <errvkt$9l7$1@news.Stanford.EDU>
References: <erof5a$i2g$2@news.Stanford.EDU> <C206331E.8B3A%jpettit@stanford.edu>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172406750 9895 128.12.194.72 (25 Feb 2007 12:32:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <C206331E.8B3A%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11867

One other related question:

 From the man page of gettimeofday:

struct timeval {
                time_t         tv_sec;        /* seconds */
                suseconds_t    tv_usec;  /* microseconds */
};

"... gives the number of seconds and microseconds since the Epoch..."

If the current time is 1.001 seconds after the Epoch, would the 
suseconds_t field have a value of 1 or 1001?

Similiarly, what about the nanoseconds field in struct timespec?

Thanks.

-Yangfan

Justin Pettit wrote:
>>1. What is the internal structure of struct timespec? I cannot find a
>>description of it in the man pages.
> 
> 
> You can use Google or look in "/usr/include".  Specifically, you may want to
> look at "/usr/include/time.h".
> 
> 
>>2. What would happen if wait_for_event is called with a time that has
>>already passed? Would it: crash? time out immediately? or never time
>>out? (As for why I can't just test this myself, please see question 1.)
> 
> 
> Now that you have the definition, you should be able to try it out...
> 
> --Justin
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: HW3A submission files
Date: Sun, 25 Feb 2007 14:49:28 -0500
Lines: 9
Distribution: su
Message-ID: <ersp85$2op$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172432965 2841 127.0.0.1 (25 Feb 2007 19:49:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11868

How should we submit the files, should we do a make dist and just submit the 
..tgz file it creates?  In that case it will contain all of the files not 
just the transport.c and the README.  Or should I just do:
tar zcvf stcp_parta.tgz transport.c README.txt
?

Seth 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: receiver window
Date: Sun, 25 Feb 2007 12:04:45 -0800
Lines: 27
Distribution: su
Message-ID: <ersq51$3gt$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172433889 3613 128.12.197.229 (25 Feb 2007 20:04:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11869

 I understand how the sender needs to limit the sending rate based on MIN( 
cwin, rwin) and I'm doing that.  On top of that, PA3 seems to ask us that we 
also need to check that the remote guy is not violating my advertised window 
and is keeping his side of the contract as well.  How do we do this? 
Right now, whenever I receive a packet from the network, I send the data to 
the application without checking that any window constraints have been 
violated.  What "window" do I have to check so I know the other side of the 
connection is not violating my advertised window size? I mean, what are the 
events that define this window?
 Related to this question.  The handout says:

"Note that received data may cross either end of the current receiver 
window; in this case, the data is split into two parts and each part is 
processed appropriately."

            This is very confusing.  The "receiver window" is how much the 
other guy can accept so this window is only meaningful to the sender.  What 
in the world does "received data" from the network have anything to do with 
"receiver window" then?


            Thanks in advanced for your response.


Tom


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 12:55:54 -0800
Lines: 12
Distribution: su
Message-ID: <erst3t$5r0$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172436925 5984 127.0.0.1 (25 Feb 2007 20:55:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <errqlv$3or$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11870

This is really weird.  Using the reference proxy with 
http://www.stanford.edu works about half the time and the other half it 
gets all the way to the end, the server requests the connection to be 
closed, sends a FIN, the client receives it, then the client requests a 
close, sends a FIN, but the server never receives it.  The server sits 
there waiting in stcp_wait_for_event and the client sits waiting for an ACK.

I've tried at least a dozen other sites numerous times and they all work 
flawlessly.  What's the deal with www.stanford.edu?  I'm sure it's 
something wrong with my code...  Anyone have any hints?

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 22:00:54 +0000 (UTC)
Lines: 27
Distribution: su
Message-ID: <ert0um$9qo$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU>
NNTP-Posting-Host: myth24.stanford.edu
X-Trace: news.Stanford.EDU 1172440854 10072 171.64.15.34 (25 Feb 2007 22:00:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11871

Hi,

proxyget.c code looks like :
bool_t is_reliable = 0;
  if (!strncmp("-U", argv[nextarg], 2)) {
    is_reliable = 1;
    nextarg++;
  }

Which tells -U means is_reliable = 1. Shouldn't it be otherwise?

Thanks,
Dinesh

Greg Nelson <grourk@stanford.edu> wrote:
> This is really weird.  Using the reference proxy with 
> http://www.stanford.edu works about half the time and the other half it 
> gets all the way to the end, the server requests the connection to be 
> closed, sends a FIN, the client receives it, then the client requests a 
> close, sends a FIN, but the server never receives it.  The server sits 
> there waiting in stcp_wait_for_event and the client sits waiting for an ACK.

> I've tried at least a dozen other sites numerous times and they all work 
> flawlessly.  What's the deal with www.stanford.edu?  I'm sure it's 
> something wrong with my code...  Anyone have any hints?

> Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Kavin Asavanant <kavin@stanford.edu>
Newsgroups: su.class.cs244a
Subject: stcp_network_recv strange behavior?
Date: Sun, 25 Feb 2007 14:05:41 -0800
Lines: 10
Distribution: su
Message-ID: <ert17m$a9u$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172441142 10558 127.0.0.1 (25 Feb 2007 22:05:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
Xref: shelby.stanford.edu su.class.cs244a:11872

Hi,
   I ran into this problem and quite puzzled what is going on.
I called stcp_network_recv with the following parameters:

stcp_network_recv(sd,(char*)segment,556); *note the max_len = 556*

What I got from the return value of the function is 560.
How is this possible since I explicitly said that the max_len is 556??

Kavin
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 22:07:50 +0000 (UTC)
Lines: 36
Distribution: su
Message-ID: <ert1bm$a9r$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert0um$9qo$1@news.Stanford.EDU>
NNTP-Posting-Host: myth24.stanford.edu
X-Trace: news.Stanford.EDU 1172441270 10555 171.64.15.34 (25 Feb 2007 22:07:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11873

Hi Greg,

I forgot to mention that www.stanford.edu is closing fine for me
irrespective of -U option with proxyget. 

Thanks,
Dinesh

Dinesh Gupta <dineshg@stanford.edu> wrote:
> Hi,

> proxyget.c code looks like :
> bool_t is_reliable = 0;
>   if (!strncmp("-U", argv[nextarg], 2)) {
>     is_reliable = 1;
>     nextarg++;
>   }

> Which tells -U means is_reliable = 1. Shouldn't it be otherwise?

> Thanks,
> Dinesh

> Greg Nelson <grourk@stanford.edu> wrote:
> > This is really weird.  Using the reference proxy with 
> > http://www.stanford.edu works about half the time and the other half it 
> > gets all the way to the end, the server requests the connection to be 
> > closed, sends a FIN, the client receives it, then the client requests a 
> > close, sends a FIN, but the server never receives it.  The server sits 
> > there waiting in stcp_wait_for_event and the client sits waiting for an ACK.

> > I've tried at least a dozen other sites numerous times and they all work 
> > flawlessly.  What's the deal with www.stanford.edu?  I'm sure it's 
> > something wrong with my code...  Anyone have any hints?

> > Greg
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: receiver window
Date: Sun, 25 Feb 2007 17:08:52 -0500
Lines: 43
Distribution: su
Message-ID: <ert1dj$adc$1@news.Stanford.EDU>
References: <ersq51$3gt$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172441332 10668 127.0.0.1 (25 Feb 2007 22:08:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11874

I was thinking about this just a minute ago and came to the conclusion that 
this isn't something you can really do in the context of part A if you're 
not implementing a receive buffer.  I don't see how it could possibly happen 
or how you would possibly detect it if you don't have a receive buffer 
because your window, while advertised to be of fixed length, is in reality, 
is unbounded.  For part B, where you'll have to have a receive buffer, this 
makes total sense because, defensively, you don't want to overflow your 
buffer.  That said, I'm not a TA and it would be good to have verification 
of this. :)

-Seth

"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:ersq51$3gt$1@news.Stanford.EDU...
> I understand how the sender needs to limit the sending rate based on 
> MIN( cwin, rwin) and I'm doing that.  On top of that, PA3 seems to ask us 
> that we also need to check that the remote guy is not violating my 
> advertised window and is keeping his side of the contract as well.  How do 
> we do this? Right now, whenever I receive a packet from the network, I 
> send the data to the application without checking that any window 
> constraints have been violated.  What "window" do I have to check so I 
> know the other side of the connection is not violating my advertised 
> window size? I mean, what are the events that define this window?
> Related to this question.  The handout says:
>
> "Note that received data may cross either end of the current receiver 
> window; in this case, the data is split into two parts and each part is 
> processed appropriately."
>
>            This is very confusing.  The "receiver window" is how much the 
> other guy can accept so this window is only meaningful to the sender. 
> What in the world does "received data" from the network have anything to 
> do with "receiver window" then?
>
>
>            Thanks in advanced for your response.
>
>
> Tom
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 17:21:55 -0500
Lines: 52
Distribution: su
Message-ID: <ert262$auk$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert0um$9qo$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172442114 11220 127.0.0.1 (25 Feb 2007 22:21:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11875

Argh.  The assignment says (as we've covered before):
You're going to find it helpful to force the network layer to be unreliable. 
To emulate the behavior of a congested multi-path network, setting the 
is_reliable parameter to false when creating a socket (use the -U flag when 
running the program) will cause the network layer to randomly reorder and 
drop packets. You'll see an example of how this is done in our dummy 
client/server code.

So, yeah, -U should make is_reliable = 0.

Paul, can you please clarify what I'm missing here.  And I have the latest 
tarball (at least as of last night).  Can we also find out what the proxy is 
doing, since we can't see the source for it?  (on a side note, shouldn't the 
usage output specifically tell use what that application takes the -U 
parameter to mean? - I get no such clarification from either proxy or 
proxyget)

-Seth


"Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
news:ert0um$9qo$1@news.Stanford.EDU...
> Hi,
>
> proxyget.c code looks like :
> bool_t is_reliable = 0;
>  if (!strncmp("-U", argv[nextarg], 2)) {
>    is_reliable = 1;
>    nextarg++;
>  }
>
> Which tells -U means is_reliable = 1. Shouldn't it be otherwise?
>
> Thanks,
> Dinesh
>
> Greg Nelson <grourk@stanford.edu> wrote:
>> This is really weird.  Using the reference proxy with
>> http://www.stanford.edu works about half the time and the other half it
>> gets all the way to the end, the server requests the connection to be
>> closed, sends a FIN, the client receives it, then the client requests a
>> close, sends a FIN, but the server never receives it.  The server sits
>> there waiting in stcp_wait_for_event and the client sits waiting for an 
>> ACK.
>
>> I've tried at least a dozen other sites numerous times and they all work
>> flawlessly.  What's the deal with www.stanford.edu?  I'm sure it's
>> something wrong with my code...  Anyone have any hints?
>
>> Greg 


.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: FIN sequence number
Date: Sun, 25 Feb 2007 22:40:50 +0000 (UTC)
Lines: 9
Distribution: su
Message-ID: <ert39i$bkg$1@news.Stanford.EDU>
NNTP-Posting-Host: myth17.stanford.edu
X-Trace: news.Stanford.EDU 1172443250 11920 171.64.15.58 (25 Feb 2007 22:40:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11876



When a FIN is piggybacked with the last data segment, how is the
sequence number for the ACK computed?
Is it "last byte of data received" or is it
"last byte of data received+1" ?

Thanks
Dina
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: outgoing buffer
Date: Sun, 25 Feb 2007 22:45:54 +0000 (UTC)
Organization: Your Company
Lines: 20
Distribution: su
Message-ID: <Xns98E29632D72CBchunkaiwstanfordedu@171.64.14.103>
References: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103> <erqk7r$36o$1@news.Stanford.EDU> <erraj4$j1a$1@news.Stanford.EDU> <erreaa$l5s$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172443554 12302 128.12.22.217 (25 Feb 2007 22:45:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11877

so, that means no deduction for no in/outgoing buffer for 3.A?



"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in
news:erreaa$l5s$1@news.Stanford.EDU: 

> Seth Wright wrote:
>> Actually, for 3A, do we even need an incoming buffer?  It doesn't
>> seem like we do because:
>> a) we know that the data is arriving in order
>> b) the interface for passing the data up for myread() consumption
>> always takes all data we give it.
>> to that end, is there a reason, other than preparing for the 3.B to
>> have in input buffer?
>> 
> 
> You are right. You don't need it until 3.B
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Sun, 25 Feb 2007 22:47:46 +0000 (UTC)
Organization: Your Company
Lines: 19
Distribution: su
Message-ID: <Xns98E2968437416chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103> <erq0ag$f0h$1@news.Stanford.EDU> <erqkag$36o$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172443666 12302 128.12.22.217 (25 Feb 2007 22:47:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11878

I don't think that's what seth is saying. I think what he's saying is, it's 
the user's responsibility to call mywrite() again.

but paul i think what ur saying is that mywrite() will call itself again 
next time (thus buffered for next time) is that right?






"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in news:erqkag$36o$2
@news.Stanford.EDU:

> 
> Seth is right. You can choose how much data you pull from the 
> application. The rest will be buffered for next time.
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 14:52:11 -0800
Lines: 48
Distribution: su
Message-ID: <ert3ut$c94$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert0um$9qo$1@news.Stanford.EDU> <ert262$auk$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172443933 12580 128.12.133.106 (25 Feb 2007 22:52:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ert262$auk$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11879

First of all, congratulations for having the longest thread on the 
newsgroup :)

> Argh.  The assignment says (as we've covered before):
> You're going to find it helpful to force the network layer to be unreliable. 
> To emulate the behavior of a congested multi-path network, setting the 
> is_reliable parameter to false when creating a socket (use the -U flag when 
> running the program) will cause the network layer to randomly reorder and 
> drop packets. You'll see an example of how this is done in our dummy 
> client/server code.
> 
> So, yeah, -U should make is_reliable = 0.
At least I'm consistent with my errors. Yes, I made the same mistake as 
I did with the proxy. Currently, -U does the OPPOSITE what what was 
intended. In proxyget.c:

------------------
   bool_t is_reliable = 0;
   if (!strncmp("-U", argv[nextarg], 2)) {
     is_reliable = 1;
     nextarg++;
   }
------------------
Should be

------------------
   bool_t is_reliable = 1;
   if (!strncmp("-U", argv[nextarg], 2)) {
     is_reliable = 0;
     nextarg++;
   }
------------------

Either make the change yourself or get the new tarball.

> 
> Paul, can you please clarify what I'm missing here.  And I have the latest 
> tarball (at least as of last night).  Can we also find out what the proxy is 
> doing, since we can't see the source for it?  (on a side note, shouldn't the 
> usage output specifically tell use what that application takes the -U 
> parameter to mean? - I get no such clarification from either proxy or 
> proxyget)

You can find out what the proxy is doing by printing out the packets 
that are being sent and received. Remember, the unreliable part means 
that the network is unreliable, not the application. You will always get 
your app reads and write correctly, it is just the network that will 
play games with you.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 14:53:13 -0800
Lines: 20
Distribution: su
Message-ID: <ert40q$c94$2@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172443994 12580 128.12.133.106 (25 Feb 2007 22:53:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erst3t$5r0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11880

Greg Nelson wrote:
> This is really weird.  Using the reference proxy with 
> http://www.stanford.edu works about half the time and the other half it 
> gets all the way to the end, the server requests the connection to be 
> closed, sends a FIN, the client receives it, then the client requests a 
> close, sends a FIN, but the server never receives it.  The server sits 
> there waiting in stcp_wait_for_event and the client sits waiting for an 
> ACK.
> 
> I've tried at least a dozen other sites numerous times and they all work 
> flawlessly.  What's the deal with www.stanford.edu?  I'm sure it's 
> something wrong with my code...  Anyone have any hints?
> 
> Greg

Try changing it to HTTP/1.1 request and see if they like that better.

Also, get it working with your proxy so that you can play around with 
the source rather than having to use the object file that I gave you. 
Then you can step through the application as well as the TCP layer.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW3A submission files
Date: Sun, 25 Feb 2007 14:56:58 -0800
Lines: 15
Distribution: su
Message-ID: <ert47r$c94$3@news.Stanford.EDU>
References: <ersp85$2op$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172444219 12580 128.12.133.106 (25 Feb 2007 22:56:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ersp85$2op$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11881

Do one or the other. How I will grade you will be:

i='seth'; mkdir $i; tar zxvf $i_stcp.tgz -C $i/; cp -rf stub/ $i/; cd 
$i; make; "run secret grading script"; cd -

Seth Wright wrote:
> How should we submit the files, should we do a make dist and just submit the 
> .tgz file it creates?  In that case it will contain all of the files not 
> just the transport.c and the README.  Or should I just do:
> tar zcvf stcp_parta.tgz transport.c README.txt
> ?
> 
> Seth 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: receiver window
Date: Sun, 25 Feb 2007 14:58:41 -0800
Lines: 17
Distribution: su
Message-ID: <ert4b2$c94$4@news.Stanford.EDU>
References: <ersq51$3gt$1@news.Stanford.EDU> <ert1dj$adc$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172444322 12580 128.12.133.106 (25 Feb 2007 22:58:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ert1dj$adc$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11882

Seth Wright wrote:
> I was thinking about this just a minute ago and came to the conclusion that 
> this isn't something you can really do in the context of part A if you're 
> not implementing a receive buffer.  I don't see how it could possibly happen 
> or how you would possibly detect it if you don't have a receive buffer 
> because your window, while advertised to be of fixed length, is in reality, 
> is unbounded.  For part B, where you'll have to have a receive buffer, this 
> makes total sense because, defensively, you don't want to overflow your 
> buffer.  That said, I'm not a TA and it would be good to have verification 
> of this. :)
> 

Seth you should be the TA. That is the correct answer.

If you don't have a receiver buffer then you can't check the sender. 
When you finally get the receiver buffer done then you can check that 
(s)he isn't overflowing that window.
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 18:03:21 -0500
Lines: 63
Distribution: su
Message-ID: <ert4jo$csv$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert0um$9qo$1@news.Stanford.EDU> <ert262$auk$1@news.Stanford.EDU> <ert3ut$c94$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172444601 13215 127.0.0.1 (25 Feb 2007 23:03:21 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11883

Thanks Paul.  I'll change it, as for the -U description in the usage I just 
meant that the usage should say something like:
proxy [-U] <port> (-U makes network connection unreliable)

I only say this because in most cases you can use man to find out what 
parameters do, but in this case we don't have man, so it's just a bit 
cryptic, that's all.

Thanks again,
Seth

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:ert3ut$c94$1@news.Stanford.EDU...
> First of all, congratulations for having the longest thread on the 
> newsgroup :)
>
>> Argh.  The assignment says (as we've covered before):
>> You're going to find it helpful to force the network layer to be 
>> unreliable. To emulate the behavior of a congested multi-path network, 
>> setting the is_reliable parameter to false when creating a socket (use 
>> the -U flag when running the program) will cause the network layer to 
>> randomly reorder and drop packets. You'll see an example of how this is 
>> done in our dummy client/server code.
>>
>> So, yeah, -U should make is_reliable = 0.
> At least I'm consistent with my errors. Yes, I made the same mistake as I 
> did with the proxy. Currently, -U does the OPPOSITE what what was 
> intended. In proxyget.c:
>
> ------------------
>   bool_t is_reliable = 0;
>   if (!strncmp("-U", argv[nextarg], 2)) {
>     is_reliable = 1;
>     nextarg++;
>   }
> ------------------
> Should be
>
> ------------------
>   bool_t is_reliable = 1;
>   if (!strncmp("-U", argv[nextarg], 2)) {
>     is_reliable = 0;
>     nextarg++;
>   }
> ------------------
>
> Either make the change yourself or get the new tarball.
>
>>
>> Paul, can you please clarify what I'm missing here.  And I have the 
>> latest tarball (at least as of last night).  Can we also find out what 
>> the proxy is doing, since we can't see the source for it?  (on a side 
>> note, shouldn't the usage output specifically tell use what that 
>> application takes the -U parameter to mean? - I get no such clarification 
>> from either proxy or proxyget)
>
> You can find out what the proxy is doing by printing out the packets that 
> are being sent and received. Remember, the unreliable part means that the 
> network is unreliable, not the application. You will always get your app 
> reads and write correctly, it is just the network that will play games 
> with you. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Sun, 25 Feb 2007 18:05:07 -0500
Lines: 29
Distribution: su
Message-ID: <ert4n2$cum$1@news.Stanford.EDU>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103> <erq0ag$f0h$1@news.Stanford.EDU> <erqkag$36o$2@news.Stanford.EDU> <Xns98E2968437416chunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1172444706 13270 127.0.0.1 (25 Feb 2007 23:05:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11884

Actually, that is what I was saying (and what I think Paul is saying, too). 
mywrite will not call itself again, but rather the application will have to 
call it as many times as necessary to send the data it wants to send.

Seth

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98E2968437416chunkaiwstanfordedu@171.64.14.103...
>I don't think that's what seth is saying. I think what he's saying is, it's
> the user's responsibility to call mywrite() again.
>
> but paul i think what ur saying is that mywrite() will call itself again
> next time (thus buffered for next time) is that right?
>
>
>
>
>
>
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in news:erqkag$36o$2
> @news.Stanford.EDU:
>
>>
>> Seth is right. You can choose how much data you pull from the
>> application. The rest will be buffered for next time.
>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: receiver window
Date: Sun, 25 Feb 2007 23:05:40 +0000 (UTC)
Organization: Your Company
Lines: 67
Distribution: su
Message-ID: <Xns98E2998CAB210chunkaiwstanfordedu@171.64.14.103>
References: <ersq51$3gt$1@news.Stanford.EDU> <ert1dj$adc$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172444740 12302 128.12.22.217 (25 Feb 2007 23:05:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11885

For part A, since there's no incoming buffer, whatever you receive you 
push to stcp_app_write(), so basically, your reciever window is 
unbounded. since every packet is in order, whatever you receive will 
slide your window.


but for part B, since the packets are out of order, you can receive tons 
of packet but the last_received_byte is still behind, thus, your sliding 
window cannot progress. hence, you can know if the other side is keeping 
their contract.

am i right TAs?





"Seth Wright" <orion@cs.stanford.edu> wrote in
news:ert1dj$adc$1@news.Stanford.EDU: 

> I was thinking about this just a minute ago and came to the conclusion
> that this isn't something you can really do in the context of part A
> if you're not implementing a receive buffer.  I don't see how it could
> possibly happen or how you would possibly detect it if you don't have
> a receive buffer because your window, while advertised to be of fixed
> length, is in reality, is unbounded.  For part B, where you'll have to
> have a receive buffer, this makes total sense because, defensively,
> you don't want to overflow your buffer.  That said, I'm not a TA and
> it would be good to have verification of this. :)
> 
> -Seth
> 
> "Tom Deane" <tdeane@stanford.edu> wrote in message 
> news:ersq51$3gt$1@news.Stanford.EDU...
>> I understand how the sender needs to limit the sending rate based on 
>> MIN( cwin, rwin) and I'm doing that.  On top of that, PA3 seems to
>> ask us that we also need to check that the remote guy is not
>> violating my advertised window and is keeping his side of the
>> contract as well.  How do we do this? Right now, whenever I receive a
>> packet from the network, I send the data to the application without
>> checking that any window constraints have been violated.  What
>> "window" do I have to check so I know the other side of the
>> connection is not violating my advertised window size? I mean, what
>> are the events that define this window? Related to this question. 
>> The handout says: 
>>
>> "Note that received data may cross either end of the current receiver
>> window; in this case, the data is split into two parts and each part
>> is processed appropriately."
>>
>>            This is very confusing.  The "receiver window" is how much
>>            the 
>> other guy can accept so this window is only meaningful to the sender.
>> What in the world does "received data" from the network have anything
>> to do with "receiver window" then?
>>
>>
>>            Thanks in advanced for your response.
>>
>>
>> Tom
>>
>> 
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: outgoing buffer
Date: Sun, 25 Feb 2007 15:13:46 -0800
Lines: 5
Distribution: su
Message-ID: <ert57b$d9i$1@news.Stanford.EDU>
References: <Xns98E15594BC65chunkaiwstanfordedu@171.64.14.103> <erqk7r$36o$1@news.Stanford.EDU> <erraj4$j1a$1@news.Stanford.EDU> <erreaa$l5s$1@news.Stanford.EDU> <Xns98E29632D72CBchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172445227 13618 128.12.133.106 (25 Feb 2007 23:13:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E29632D72CBchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11886

Chun Kai Wang wrote:
> so, that means no deduction for no in/outgoing buffer for 3.A?
> 
We're not even going to look at your code in 3.A. Just the the 
functionality done and you'll get 100% for this part.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: receiver window
Date: Sun, 25 Feb 2007 15:32:02 -0800
Lines: 15
Distribution: su
Message-ID: <ert69j$e8d$1@news.Stanford.EDU>
References: <ersq51$3gt$1@news.Stanford.EDU> <ert1dj$adc$1@news.Stanford.EDU> <Xns98E2998CAB210chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172446323 14605 128.12.133.106 (25 Feb 2007 23:32:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E2998CAB210chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11887

Chun Kai Wang wrote:
> For part A, since there's no incoming buffer, whatever you receive you 
> push to stcp_app_write(), so basically, your reciever window is 
> unbounded. since every packet is in order, whatever you receive will 
> slide your window.
> 
> 
> but for part B, since the packets are out of order, you can receive tons 
> of packet but the last_received_byte is still behind, thus, your sliding 
> window cannot progress. hence, you can know if the other side is keeping 
> their contract.
> 
> am i right TAs?
> 
Yes.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gethostbyname_r failing
Date: Sun, 25 Feb 2007 15:37:33 -0800
Lines: 15
Distribution: su
Message-ID: <ert6ju$edv$1@news.Stanford.EDU>
References: <erp0uv$54d$1@news.Stanford.EDU> <erqkc5$36o$3@news.Stanford.EDU> <erqqca$7mv$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172446654 14783 128.12.133.106 (25 Feb 2007 23:37:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erqqca$7mv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11888

>> What is your machine configuration, and what is gethostbyname_r dieing 
>> because of? What are the inputs when the method calls aborts?
> Adding a static map between my ip and the name returned by gethostname 
> fixed the issue. Another thing, nslookup returns multiple ip addresses
> for the specified hostname which could cause a problem.
> 
> Anyway, all is well!

Thank you for finding the program. Is there anything in the stub code 
that we could have put that would have helped you find this machine 
config issue?

And that goes for everyone else too. If you think there should be a 
change in the stub code (like the -U explanation from Seth) please let a 
TA know and we'll consider it for next year.
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 16:13:01 -0800
Lines: 4
Distribution: su
Message-ID: <ert8le$g6r$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172448750 16603 127.0.0.1 (26 Feb 2007 00:12:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <ert40q$c94$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11889

Well, I converted over my proxy and now everything works fine.  So I'm 
gonna throw up my hands and blame it on the proxy you gave us.

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Mon, 26 Feb 2007 00:17:43 +0000 (UTC)
Organization: Your Company
Lines: 43
Distribution: su
Message-ID: <Xns98E2A5C3FDD7Echunkaiwstanfordedu@171.64.14.103>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103> <erq0ag$f0h$1@news.Stanford.EDU> <erqkag$36o$2@news.Stanford.EDU> <Xns98E2968437416chunkaiwstanfordedu@171.64.14.103> <ert4n2$cum$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172449063 16648 128.12.22.217 (26 Feb 2007 00:17:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11890

hum... if that's the case, how does transport.c communicate to the app 
layer that only 10 bytes out of 100 was consumed?





"Seth Wright" <orion@cs.stanford.edu> wrote in
news:ert4n2$cum$1@news.Stanford.EDU: 

> Actually, that is what I was saying (and what I think Paul is saying,
> too). mywrite will not call itself again, but rather the application
> will have to call it as many times as necessary to send the data it
> wants to send. 
> 
> Seth
> 
> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
> news:Xns98E2968437416chunkaiwstanfordedu@171.64.14.103...
>>I don't think that's what seth is saying. I think what he's saying is,
>>it's 
>> the user's responsibility to call mywrite() again.
>>
>> but paul i think what ur saying is that mywrite() will call itself
>> again next time (thus buffered for next time) is that right?
>>
>>
>>
>>
>>
>>
>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in news:erqkag$36o$2
>> @news.Stanford.EDU:
>>
>>>
>>> Seth is right. You can choose how much data you pull from the
>>> application. The rest will be buffered for next time.
>>>
>> 
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: application write
Date: Sun, 25 Feb 2007 20:28:47 -0500
Lines: 52
Distribution: su
Message-ID: <ertd4m$jfj$1@news.Stanford.EDU>
References: <Xns98E1A5F46212chunkaiwstanfordedu@171.64.14.103> <erq0ag$f0h$1@news.Stanford.EDU> <erqkag$36o$2@news.Stanford.EDU> <Xns98E2968437416chunkaiwstanfordedu@171.64.14.103> <ert4n2$cum$1@news.Stanford.EDU> <Xns98E2A5C3FDD7Echunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1172453334 19955 127.0.0.1 (26 Feb 2007 01:28:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11891

That's not up to transport.c so you don't have to worry about it.  That's up 
to the mywrite implementation (and I'm guessing it's a bit funky).

Seth

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98E2A5C3FDD7Echunkaiwstanfordedu@171.64.14.103...
> hum... if that's the case, how does transport.c communicate to the app
> layer that only 10 bytes out of 100 was consumed?
>
>
>
>
>
> "Seth Wright" <orion@cs.stanford.edu> wrote in
> news:ert4n2$cum$1@news.Stanford.EDU:
>
>> Actually, that is what I was saying (and what I think Paul is saying,
>> too). mywrite will not call itself again, but rather the application
>> will have to call it as many times as necessary to send the data it
>> wants to send.
>>
>> Seth
>>
>> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message
>> news:Xns98E2968437416chunkaiwstanfordedu@171.64.14.103...
>>>I don't think that's what seth is saying. I think what he's saying is,
>>>it's
>>> the user's responsibility to call mywrite() again.
>>>
>>> but paul i think what ur saying is that mywrite() will call itself
>>> again next time (thus buffered for next time) is that right?
>>>
>>>
>>>
>>>
>>>
>>>
>>> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in news:erqkag$36o$2
>>> @news.Stanford.EDU:
>>>
>>>>
>>>> Seth is right. You can choose how much data you pull from the
>>>> application. The rest will be buffered for next time.
>>>>
>>>
>>
>>
>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 20:37:46 -0500
Lines: 39
Distribution: su
Message-ID: <ertdla$js7$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172453866 20359 127.0.0.1 (26 Feb 2007 01:37:46 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11892

Well, I'm going to add some more to this thread:
I had weird behaviour with proxyget with http://www.google.com/.  The 
problem was that it would always truncate the last few bytes the were 
received from google so I wouldn't see the final </html>.  I traced the code 
and saw that the data I was sending back up contained everything it should, 
it just didn't make it out to stdout.  It works correctly for most all other 
urls (the only other one where I ran into this was 
http://www.appleinsider.com/).  I changed proxyget to write to a file rather 
than stdout and then performed an fflush and fclose on the file after 
myclose() and the output file did, indeed, have the correct output.  So it 
looks to me like there's some sort of interesting race condition here that I 
don't feel like trying to figure out.  Also, I think the call to fwrite is 
proxyget is off (it works, but I don't think it was what was intended).  The 
man page says:

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);

But the call is:
fwrite(buf,read,sizeof(char),stdout);

It works because it's writing one segment of size read bytes, but the 
sizeof(char) leads me to believe that the intended call was:
fwrite(buf,sizeof(char),read,stdout);

Anyway, proxyget works for me except for the race condition above.  Also, if 
I add a printf("\n") after myclose(); I also get the correct output so I 
just think that stdout isn't flushing correctly or something.

Seth


"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:ert8le$g6r$1@news.Stanford.EDU...
> Well, I converted over my proxy and now everything works fine.  So I'm 
> gonna throw up my hands and blame it on the proxy you gave us.
>
> Greg 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Receiver window range
Date: Sun, 25 Feb 2007 17:47:05 -0800
Lines: 21
Distribution: su
Message-ID: <erte6q$kdj$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172454426 20915 127.0.0.1 (26 Feb 2007 01:47:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11893

Can someone please explain what the following means (this is from the 
assignment description page):

+++++++++++++++++++
 The first byte of all windows is always the last acknowledged byte of data. 
For example, for the receiver window, if the last acknowledgment was 
sequence number 8192, then the receiver is willing to accept data with 
sequence numbers of 8192 through 11263 (=8192+3072-1), inclusive.
+++++++++++++++++++

(1) Does the above mean that if I acknowledged seq number 8191 with an ACK 
number 8192, the receiver window should start from 8192

OR

(2) If I acknowledged seq number 8192 with an ACK number 8193, the receiver 
window should start from 8192

To me, (1) makes more sense, but the above statement seems to suggest (2). 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: retrying packets
Date: Sun, 25 Feb 2007 17:59:55 -0800
Lines: 8
Distribution: su
Message-ID: <erteut$kv8$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434deb.stanford.edu
X-Trace: news.Stanford.EDU 1172455197 21480 171.67.77.235 (26 Feb 2007 01:59:57 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11894

Should we handle retrying of packets for milestone one?

I think NO, since for milestone-1, there are no lost/reord-red packets and 
no-time-outs

Is this understanding correct? 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Go-back-N?
Date: Sun, 25 Feb 2007 18:04:12 -0800
Lines: 43
Distribution: su
Message-ID: <ertf3d$l5k$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172455341 21684 128.12.134.140 (26 Feb 2007 02:02:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11895

Hi,

The assignment states that we should retransmit everything:

     "STCP, like TCP, is a Go-back-N protocol. This means that if the
      transport layer decides that its peer has not received the segment
      with sequence number n, then it will retransmit all data starting
      at n, not just that segment."

I thought TCP doesn't resend _all_ the data on a timeout. I thought it
just resends the first segment. From RFC793:

RETRANSMISSION TIMEOUT

    For any state if the retransmission timeout expires on a segment in
    the retransmission queue, send the segment at the front of the
    retransmission queue again, reinitialize the retransmission timer,
    and return.

From Kurose and Ross p. 241:

    "TCP responds to the timeout event by retransmitting the segment
     that caused the timeout. TC then restarts the timer."

The point is, it doesn't make sense to resend everything and buffer out
of order packets at the same time. There is also a conflicting
requirement there in the assignment:

"If the timeout for a segment is reached, the segment is examined. If it
has been sent a total of 6 times (once from the original send plus 5
retransmissions), then the network is assumed to have failed and the
network terminated. Otherwise the segment is retransmitted and the
timeout is reset again."

This says only the segment causing the timeout is retransmitted.

So are we to resend everything or just the timed out packet? And if we
resend everything, what is the point of buffering out-of-order packets?
I mean there is a point (in case you don't get it at the next
retransmit) but not much of it.

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Receiver window range
Date: Sun, 25 Feb 2007 19:49:10 -0800
Lines: 27
Distribution: su
Message-ID: <ertlbm$pvd$1@news.Stanford.EDU>
References: <erte6q$kdj$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172461750 26605 128.12.194.72 (26 Feb 2007 03:49:10 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erte6q$kdj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11896

Riju Kallivalappil wrote:
> Can someone please explain what the following means (this is from the 
> assignment description page):
> 
> +++++++++++++++++++
>  The first byte of all windows is always the last acknowledged byte of data. 
> For example, for the receiver window, if the last acknowledgment was 
> sequence number 8192, then the receiver is willing to accept data with 
> sequence numbers of 8192 through 11263 (=8192+3072-1), inclusive.
> +++++++++++++++++++
> 
> (1) Does the above mean that if I acknowledged seq number 8191 with an ACK 
> number 8192, the receiver window should start from 8192
> 
> OR
> 
> (2) If I acknowledged seq number 8192 with an ACK number 8193, the receiver 
> window should start from 8192
> 
> To me, (1) makes more sense, but the above statement seems to suggest (2). 
> 
> 
I say it's (1).

Disclaimer: not a TA.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Jitendra Nath Pandey <jnpandey@gmail.com>
Newsgroups: su.class.cs244a
Subject: Telnet to proxy server
Date: Sun, 25 Feb 2007 20:28:17 -0800
Lines: 17
Distribution: su
Message-ID: <ertnlk$rs8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172464116 28552 127.0.0.1 (26 Feb 2007 04:28:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
Xref: shelby.stanford.edu su.class.cs244a:11897

Hi,

I am running the proxy server with mysock, and trying to connect to it 
with telnet on the port where sever is listening.
Thus a real tcp client is trying to connect to STCP. The telnet gets 
connected to that port but none of my commands afterwards seem to get 
through.
In fact my code in transport.c is not invoked at all. Here are my 
guesses on the possible reasons.
1)I am doing something terribly wrong.
2)STCP is actually running on top of TCP (or UDP?). and telnet gets 
connected to the TCP underneath not to STCP.

Please let me know.

thanks
jitendra
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: receiver window
Date: Sun, 25 Feb 2007 20:33:19 -0800
Lines: 36
Distribution: su
Message-ID: <C207A30F.8BB2%jpettit@stanford.edu>
References: <ersq51$3gt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172464403 28843 127.0.0.1 (26 Feb 2007 04:33:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: receiver window
Thread-Index: AcdZXz1ifC1NPcVSEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11898

>  I understand how the sender needs to limit the sending rate based on MIN(
> cwin, rwin) and I'm doing that.  On top of that, PA3 seems to ask us that we
> also need to check that the remote guy is not violating my advertised window
> and is keeping his side of the contract as well.  How do we do this?
> Right now, whenever I receive a packet from the network, I send the data to
> the application without checking that any window constraints have been
> violated.  What "window" do I have to check so I know the other side of the
> connection is not violating my advertised window size? I mean, what are the
> events that define this window?

I think there's some confusion about the various windows.  Both sides have a
sender window and a receiver window.  Your receiver window is the amount of
data that you are willing to accept.  You want to make sure that the other
side doesn't send any data outside of this window.  If you do receive data
outside of this window, you should ignore the part that is outside of it.

>  Related to this question.  The handout says:
> 
> "Note that received data may cross either end of the current receiver
> window; in this case, the data is split into two parts and each part is
> processed appropriately."
> 
>             This is very confusing.  The "receiver window" is how much the
> other guy can accept so this window is only meaningful to the sender.  What
> in the world does "received data" from the network have anything to do with
> "receiver window" then?

With the correct understanding of the various windows, this should be
clearer.  Let's say your receiver window is open from 80 to 100.  If you
receive sequence numbers 60 to 85, then you send out an ACK of 86 and only
send bytes 80 through 85 to the application layer.  If you receive data from
80 to 105, then you should send an ACK of 101 and only send bytes 80 through
100 to the application layer.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Kavin Asavanant <kavin@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp_network_recv strange behavior?
Date: Sun, 25 Feb 2007 20:34:47 -0800
Lines: 15
Distribution: su
Message-ID: <erto17$s5u$1@news.Stanford.EDU>
References: <ert17m$a9u$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172464487 28862 127.0.0.1 (26 Feb 2007 04:34:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
In-Reply-To: <ert17m$a9u$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11899

figure it out..send the wrong size packet -_-''



Kavin Asavanant wrote:
> Hi,
>   I ran into this problem and quite puzzled what is going on.
> I called stcp_network_recv with the following parameters:
> 
> stcp_network_recv(sd,(char*)segment,556); *note the max_len = 556*
> 
> What I got from the return value of the function is 560.
> How is this possible since I explicitly said that the max_len is 556??
> 
> Kavin
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Receiver window range
Date: Sun, 25 Feb 2007 21:41:47 -0800
Lines: 30
Distribution: su
Message-ID: <ertrus$1g1$1@news.Stanford.EDU>
References: <erte6q$kdj$1@news.Stanford.EDU> <ertlbm$pvd$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172468508 1537 128.12.133.106 (26 Feb 2007 05:41:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ertlbm$pvd$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11900

Yangfan Wang wrote:
> Riju Kallivalappil wrote:
>> Can someone please explain what the following means (this is from the 
>> assignment description page):
>>
>> +++++++++++++++++++
>>  The first byte of all windows is always the last acknowledged byte of 
>> data. For example, for the receiver window, if the last acknowledgment 
>> was sequence number 8192, then the receiver is willing to accept data 
>> with sequence numbers of 8192 through 11263 (=8192+3072-1), inclusive.
>> +++++++++++++++++++
>>
>> (1) Does the above mean that if I acknowledged seq number 8191 with an 
>> ACK number 8192, the receiver window should start from 8192
>>
>> OR
>>
>> (2) If I acknowledged seq number 8192 with an ACK number 8193, the 
>> receiver window should start from 8192
>>
>> To me, (1) makes more sense, but the above statement seems to suggest 
>> (2).
>>
> I say it's (1).
> 
> Disclaimer: not a TA.
> 
> -Yangfan

The ACK contains the next byte you want to receive. So (1).
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: retrying packets
Date: Sun, 25 Feb 2007 21:41:59 -0800
Lines: 10
Distribution: su
Message-ID: <ertrv8$1g1$2@news.Stanford.EDU>
References: <erteut$kv8$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172468520 1537 128.12.133.106 (26 Feb 2007 05:42:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erteut$kv8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11901

manj wrote:
> Should we handle retrying of packets for milestone one?
> 
> I think NO, since for milestone-1, there are no lost/reord-red packets and 
> no-time-outs
> 
> Is this understanding correct? 
> 
> 
Correct.
.

Path: shelby.stanford.edu!not-for-mail
From: Ray Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Cleanliness of Code?
Date: Sun, 25 Feb 2007 21:46:03 -0800
Lines: 14
Distribution: su
Message-ID: <erts6s$1th$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172468765 1969 127.0.0.1 (26 Feb 2007 05:46:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
Xref: shelby.stanford.edu su.class.cs244a:11902

At the risk of being severely berated...

For the purposes of the milestones 3.A and 3.B, how will we be graded 
stylistically (i.e does style matter)?  Will things like design choices and 
comments matter?

Amongst a few ugly things, I have a bunch of printfs scattered throughout the 
code, for debugging purposes, and I'd prefer not to have to clean it up, just to 
find out that I have to put it back in for testing the next parts.

Any insight to your grading standards would be appreciated...

TIA,
- Raymond
.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 22:04:57 -0800
Lines: 12
Distribution: su
Message-ID: <pan.2007.02.26.06.04.57.614864@cs.stanford.edu>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172469376 2340 128.12.186.133 (26 Feb 2007 05:56:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11903

On Sun, 25 Feb 2007 16:13:01 -0800, Greg Nelson wrote:

> Well, I converted over my proxy and now everything works fine.  So I'm 
> gonna throw up my hands and blame it on the proxy you gave us.
> 
> Greg


I'm having the same problem as you guys.

Greg, does everything work consistently for you using proxyget?

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW3A submission files
Date: Sun, 25 Feb 2007 21:58:00 -0800
Lines: 20
Distribution: su
Message-ID: <ertsta$2be$1@news.Stanford.EDU>
References: <ersp85$2op$1@news.Stanford.EDU> <ert47r$c94$3@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172469483 2414 127.0.0.1 (26 Feb 2007 05:58:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:11904

Do we need to submit a README file for 3A? I remember seeing in another 
thread that TA's care only about the functionality in 3A.

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:ert47r$c94$3@news.Stanford.EDU...
> Do one or the other. How I will grade you will be:
>
> i='seth'; mkdir $i; tar zxvf $i_stcp.tgz -C $i/; cp -rf stub/ $i/; cd $i; 
> make; "run secret grading script"; cd -
>
> Seth Wright wrote:
>> How should we submit the files, should we do a make dist and just submit 
>> the .tgz file it creates?  In that case it will contain all of the files 
>> not just the transport.c and the README.  Or should I just do:
>> tar zcvf stcp_parta.tgz transport.c README.txt
>> ?
>>
>> Seth 


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Telnet to proxy server
Date: Sun, 25 Feb 2007 22:03:52 -0800
Lines: 23
Distribution: su
Message-ID: <ertt89$2h9$1@news.Stanford.EDU>
References: <ertnlk$rs8$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172469833 2601 128.12.133.106 (26 Feb 2007 06:03:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ertnlk$rs8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11905

Jitendra Nath Pandey wrote:
> Hi,
> 
> I am running the proxy server with mysock, and trying to connect to it 
> with telnet on the port where sever is listening.
> Thus a real tcp client is trying to connect to STCP. The telnet gets 
> connected to that port but none of my commands afterwards seem to get 
> through.
> In fact my code in transport.c is not invoked at all. Here are my 
> guesses on the possible reasons.
> 1)I am doing something terribly wrong.
> 2)STCP is actually running on top of TCP (or UDP?). and telnet gets 
> connected to the TCP underneath not to STCP.
> 
> Please let me know.
> 
> thanks
> jitendra


STCP will NOT interact with real TCP (we are emulating it on top of a 
TCP connection). Use the proxyget program to talk to your proxy (or 
write your own similar program).
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW3A submission files
Date: Sun, 25 Feb 2007 22:09:49 -0800
Lines: 9
Distribution: su
Message-ID: <erttje$2h9$2@news.Stanford.EDU>
References: <ersp85$2op$1@news.Stanford.EDU> <ert47r$c94$3@news.Stanford.EDU> <ertsta$2be$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172470190 2601 128.12.133.106 (26 Feb 2007 06:09:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ertsta$2be$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11906

Riju Kallivalappil wrote:
> Do we need to submit a README file for 3A? I remember seeing in another 
> thread that TA's care only about the functionality in 3A.
> 
If you are confident enough that you will get 100% and I will not have 
to look at your code, you only need a README with your name. But if you 
get something wrong and I have to poke into your code, if I have a 
readme, it makes it much easier to find a problem instead of just giving 
up and letting you fail the test.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cleanliness of Code?
Date: Sun, 25 Feb 2007 22:14:57 -0800
Lines: 19
Distribution: su
Message-ID: <erttt2$2h9$3@news.Stanford.EDU>
References: <erts6s$1th$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172470498 2601 128.12.133.106 (26 Feb 2007 06:14:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erts6s$1th$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11907

Ray Thang wrote:
> At the risk of being severely berated...
> 
> For the purposes of the milestones 3.A and 3.B, how will we be graded 
> stylistically (i.e does style matter)?  Will things like design choices 
> and comments matter?
A and B will be automated. C is where we look at your code. But 
remember, if you fail EVERY test and it is due to a small bug, we will 
usually look at your code. If everything is in one function and you use 
GOTOs we will give up and just give you the automated grade.
> 
> Amongst a few ugly things, I have a bunch of printfs scattered 
> throughout the code, for debugging purposes, and I'd prefer not to have 
> to clean it up, just to find out that I have to put it back in for 
> testing the next parts.
Please don't have anything printing. Just remove every line that has the 
word printf in your code, or make a #define to null them or something. 
It is very hard to see the output of the grading script if you are 
printing all sorts of stuff.
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Testing for parts A and B
Date: Sun, 25 Feb 2007 22:20:11 -0800
Lines: 4
Distribution: su
Message-ID: <ertu6r$386$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172470811 3334 128.12.104.61 (26 Feb 2007 06:20:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:11908

Will our STCP implementations be tested against other STCP implementations?

Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Sun, 25 Feb 2007 22:31:11 -0800
Lines: 6
Distribution: su
Message-ID: <ertuqd$3ls$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172471437 3772 127.0.0.1 (26 Feb 2007 06:30:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <pan.2007.02.26.06.04.57.614864@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11909

Now that I'm using my own proxy it seems to work consistently.  Except 
with http://en.wikipedia.org/...  it looks like they're not returning 
any HTTP headers with their document which confuses my proxy, but that 
doesn't really involve STCP.  Every other site I've tested seems to work.

Are you seeing the issue just with http://www.stanford.edu?
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Mon, 26 Feb 2007 01:53:51 -0500
Lines: 53
Distribution: su
Message-ID: <eru05v$4i9$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172472831 4681 127.0.0.1 (26 Feb 2007 06:53:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11910

Clarification on this point would be great.  I'm just starting to design my 
retransmission approach, etc and would like to know how to handle this, so 
if a TA could comment, that would be great. :)

Seth

"Jad Naous" <jnaous@stanford.edu> wrote in message 
news:ertf3d$l5k$1@news.Stanford.EDU...
> Hi,
>
> The assignment states that we should retransmit everything:
>
>     "STCP, like TCP, is a Go-back-N protocol. This means that if the
>      transport layer decides that its peer has not received the segment
>      with sequence number n, then it will retransmit all data starting
>      at n, not just that segment."
>
> I thought TCP doesn't resend _all_ the data on a timeout. I thought it
> just resends the first segment. From RFC793:
>
> RETRANSMISSION TIMEOUT
>
>    For any state if the retransmission timeout expires on a segment in
>    the retransmission queue, send the segment at the front of the
>    retransmission queue again, reinitialize the retransmission timer,
>    and return.
>
> From Kurose and Ross p. 241:
>
>    "TCP responds to the timeout event by retransmitting the segment
>     that caused the timeout. TC then restarts the timer."
>
> The point is, it doesn't make sense to resend everything and buffer out
> of order packets at the same time. There is also a conflicting
> requirement there in the assignment:
>
> "If the timeout for a segment is reached, the segment is examined. If it
> has been sent a total of 6 times (once from the original send plus 5
> retransmissions), then the network is assumed to have failed and the
> network terminated. Otherwise the segment is retransmitted and the
> timeout is reset again."
>
> This says only the segment causing the timeout is retransmitted.
>
> So are we to resend everything or just the timed out packet? And if we
> resend everything, what is the point of buffering out-of-order packets?
> I mean there is a point (in case you don't get it at the next
> retransmit) but not much of it.
>
> Thanks,
> Jad. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Mon, 26 Feb 2007 02:08:54 -0500
Lines: 67
Distribution: su
Message-ID: <eru125$582$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172473733 5378 127.0.0.1 (26 Feb 2007 07:08:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11911

Also, similar to this is what's the expected behavior for when we get back 
an ACK that lands half way through a datagram we've already sent (could be 
caused by it going across the end of the receiver's window)?  Should we 
retransmit the entire packet (couldn't hurt because the receiver is supposed 
to ignore data it's already received), or should we just resend the data 
that didn't get ACKed, or (in conjunction with the Go-back-N stuff) are we 
supposed to resend all data after the ACK in a series of new datagrams?

Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:eru05v$4i9$1@news.Stanford.EDU...
> Clarification on this point would be great.  I'm just starting to design 
> my retransmission approach, etc and would like to know how to handle this, 
> so if a TA could comment, that would be great. :)
>
> Seth
>
> "Jad Naous" <jnaous@stanford.edu> wrote in message 
> news:ertf3d$l5k$1@news.Stanford.EDU...
>> Hi,
>>
>> The assignment states that we should retransmit everything:
>>
>>     "STCP, like TCP, is a Go-back-N protocol. This means that if the
>>      transport layer decides that its peer has not received the segment
>>      with sequence number n, then it will retransmit all data starting
>>      at n, not just that segment."
>>
>> I thought TCP doesn't resend _all_ the data on a timeout. I thought it
>> just resends the first segment. From RFC793:
>>
>> RETRANSMISSION TIMEOUT
>>
>>    For any state if the retransmission timeout expires on a segment in
>>    the retransmission queue, send the segment at the front of the
>>    retransmission queue again, reinitialize the retransmission timer,
>>    and return.
>>
>> From Kurose and Ross p. 241:
>>
>>    "TCP responds to the timeout event by retransmitting the segment
>>     that caused the timeout. TC then restarts the timer."
>>
>> The point is, it doesn't make sense to resend everything and buffer out
>> of order packets at the same time. There is also a conflicting
>> requirement there in the assignment:
>>
>> "If the timeout for a segment is reached, the segment is examined. If it
>> has been sent a total of 6 times (once from the original send plus 5
>> retransmissions), then the network is assumed to have failed and the
>> network terminated. Otherwise the segment is retransmitted and the
>> timeout is reset again."
>>
>> This says only the segment causing the timeout is retransmitted.
>>
>> So are we to resend everything or just the timed out packet? And if we
>> resend everything, what is the point of buffering out-of-order packets?
>> I mean there is a point (in case you don't get it at the next
>> retransmit) but not much of it.
>>
>> Thanks,
>> Jad.
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: HELP!!!!!!!!! receive from app outside window
Date: Mon, 26 Feb 2007 07:53:08 +0000 (UTC)
Organization: Your Company
Lines: 12
Distribution: su
Message-ID: <Xns98E2F2FA922BAchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172476388 8956 128.12.22.217 (26 Feb 2007 07:53:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11912

so right now, i have a bug where (i'm running ./server and ./client)

where the server is trying to send 8kb of files,

and since the window is ~3kb, when the window fills and the ack packets 
have not been reached, 


my program will get into a huge loop... and keey trying to accept from the 
application layer... is this suppose to happen? what's going on???


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: errno = ECONNREFUSED
Date: Sun, 25 Feb 2007 23:56:18 -0800
Lines: 21
Distribution: su
Message-ID: <eru3r6$9gs$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172476583 9756 128.12.197.229 (26 Feb 2007 07:56:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11913

In transport_init:
    /* after the handshake completes, unblock the
     * application with stcp_unblock_application(sd).  you may also use
     * this to communicate an error condition back to the application, e.g.
     * if connection fails; to do so, just set errno appropriately (e.g. to
     * ECONNREFUSED, etc.) before calling the function.
     */

Right now, I just stall until I get the packet I'm looking for (such as 
SYN_ACK) during network init.

1.) Is this OK for part A?

2.) If we get a timeout waiting for the SYN_ACK, shouldn't we just 
restranmit the SYN?  If yes, then when do we ever use this errno = 
ECONNREFUSED?  Perhaps after sending "many" SYN packets without luck?

Thanks,
Tom


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HELP!!!!!!!!! receive from app outside window
Date: Mon, 26 Feb 2007 00:02:56 -0800
Lines: 6
Distribution: su
Message-ID: <eru46d$9tn$1@news.Stanford.EDU>
References: <Xns98E2F2FA922BAchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172476942 10167 127.0.0.1 (26 Feb 2007 08:02:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <Xns98E2F2FA922BAchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11914

Yes, until ACKs come in you can't send any data even though the 
application has some waiting for you.  You could avoid busy-waiting by 
not bothering to wait for APP_DATA events until you can actually send 
something.

Greg
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HELP!!!!!!!!! receive from app outside window
Date: Mon, 26 Feb 2007 08:05:06 +0000 (UTC)
Organization: Your Company
Lines: 18
Distribution: su
Message-ID: <Xns98E3DDBFAD7chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E2F2FA922BAchunkaiwstanfordedu@171.64.14.103> <eru46d$9tn$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172477106 8956 128.12.22.217 (26 Feb 2007 08:05:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11915

thks! tat makes perfect sense







Greg Nelson <grourk@stanford.edu> wrote in news:eru46d$9tn$1
@news.Stanford.EDU:

> Yes, until ACKs come in you can't send any data even though the 
> application has some waiting for you.  You could avoid busy-waiting by 
> not bothering to wait for APP_DATA events until you can actually send 
> something.
> 
> Greg

.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: errno = ECONNREFUSED
Date: Mon, 26 Feb 2007 00:06:08 -0800
Lines: 36
Distribution: su
Message-ID: <eru4dk$a6o$1@news.Stanford.EDU>
References: <eru3r6$9gs$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172477172 10456 128.12.197.229 (26 Feb 2007 08:06:12 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11916


> 2.) If we get a timeout waiting for the SYN_ACK, shouldn't we just
> restranmit the SYN?  If yes, then when do we ever use this errno = 
> ECONNREFUSED?  Perhaps after sending "many" SYN packets without luck?
    Found answer to Q2 in the handout... pls ignore this one =)

Tom




"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:eru3r6$9gs$1@news.Stanford.EDU...
> In transport_init:
>    /* after the handshake completes, unblock the
>     * application with stcp_unblock_application(sd).  you may also use
>     * this to communicate an error condition back to the application, e.g.
>     * if connection fails; to do so, just set errno appropriately (e.g. to
>     * ECONNREFUSED, etc.) before calling the function.
>     */
>
> Right now, I just stall until I get the packet I'm looking for (such as 
> SYN_ACK) during network init.
>
> 1.) Is this OK for part A?
>
> 2.) If we get a timeout waiting for the SYN_ACK, shouldn't we just 
> restranmit the SYN?  If yes, then when do we ever use this errno = 
> ECONNREFUSED?  Perhaps after sending "many" SYN packets without luck?
>
> Thanks,
> Tom
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: TIME_WAIT and LAST_ACK states
Date: Mon, 26 Feb 2007 00:08:10 -0800
Lines: 10
Distribution: su
Message-ID: <eru4dr$a6v$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172477179 10463 128.12.134.140 (26 Feb 2007 08:06:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:11917

Hi,

Somewhere in the assignment it says we are not supposed to implement the
TIME_WAIT state. That means in an unreliable connection, we might not
get an ACK for a FIN sent by the server-side TCP (while waiting in the
LAST_ACK state). Does that mean that we shouldn't implement the LAST_ACK
state either?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: hum... weird bug...
Date: Mon, 26 Feb 2007 08:12:33 +0000 (UTC)
Organization: Your Company
Lines: 14
Distribution: su
Message-ID: <Xns98E3220ED0FCchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172477553 8956 128.12.22.217 (26 Feb 2007 08:12:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11918

i have a really weird bug...

it takes more than 1 minute to transfer 6kb... i have an 8kb file and it's 
transmitting over 3 minutes...


is this normal? i'm transmitting from myth 22 to myth 15.


somehow, it takes a long time for the ack packets to reach the server....



help
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: robustness with respect to transport layer
Date: Mon, 26 Feb 2007 00:54:45 -0800
Lines: 11
Distribution: su
Message-ID: <eru78l$csh$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek-laptop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172480085 13201 128.12.104.76 (26 Feb 2007 08:54:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11919

Hi--

How robust should our STCP implementation be to failures in the 
underlying transport mechanism? In my current implementation, if I 
Ctrl-C the server, an assert fails in my client due to underlying 
network calls failing. Is this something we should try to gracefully 
recover from (even for the final submission)?

Thanks,
peter

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: duplicate data
Date: Mon, 26 Feb 2007 10:12:56 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172484776 16160 128.12.22.217 (26 Feb 2007 10:12:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11920

in the assignment, it says that if a packet contains duplicate data, a new 
ack has to be sent.

how do u distinguish between duplicate data and data that is out of the 
receiver window? for part A? since we don't have an incomming buffer? will 
this be required for A?


.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 02:18:51 -0800
Lines: 15
Distribution: su
Message-ID: <eruc6l$gce$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1172485141 16782 128.12.137.162 (26 Feb 2007 10:19:01 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11921


"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:ertuqd$3ls$1@news.Stanford.EDU...
> Now that I'm using my own proxy it seems to work consistently.  Except 
> with http://en.wikipedia.org/...  it looks like they're not returning any 
> HTTP headers with their document which confuses my proxy, but that doesn't 
> really involve STCP.  Every other site I've tested seems to work.
>
> Are you seeing the issue just with http://www.stanford.edu?

This ones quite weird!
I'm seeing the same issue ( The server waiting in stcp_wait_for_event and 
the client sits waiting for an ACK.), and only with http://www.stanford.edu. 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Question on timer:
Date: Mon, 26 Feb 2007 03:23:37 -0800
Lines: 20
Distribution: su
Message-ID: <erufvp$k5d$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489017 20653 128.12.194.72 (26 Feb 2007 11:23:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11922

I'm re-posting this, since it seems to have been buried under the deluge 
of questions. :p

 From the man page of gettimeofday:

struct timeval {
                time_t         tv_sec;        /* seconds */
                suseconds_t    tv_usec;  /* microseconds */
};

"... gives the number of seconds and microseconds since the Epoch..."

Question: If the current time is 1.001 seconds after the Epoch, would 
the tv_usec field have a value of 1 or 1001?

Similiarly, what about the nanoseconds field in struct timespec?

Thanks.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Testing for parts A and B
Date: Mon, 26 Feb 2007 03:27:15 -0800
Lines: 9
Distribution: su
Message-ID: <erug6k$khf$1@news.Stanford.EDU>
References: <ertu6r$386$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489236 21039 128.12.133.106 (26 Feb 2007 11:27:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <ertu6r$386$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11923

Matt Page wrote:
> Will our STCP implementations be tested against other STCP implementations?
> 
> Thanks,
> Matt

Hmm. Good idea! Currently we don't in our grading script, but there is 
no reason not to. We might make this bonus credit for interoperability. 
I'll chat with the other TAs about it.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HELP!!!!!!!!! receive from app outside window
Date: Mon, 26 Feb 2007 03:27:41 -0800
Lines: 9
Distribution: su
Message-ID: <erug7e$khf$2@news.Stanford.EDU>
References: <Xns98E2F2FA922BAchunkaiwstanfordedu@171.64.14.103> <eru46d$9tn$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489262 21039 128.12.133.106 (26 Feb 2007 11:27:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eru46d$9tn$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11924

Greg Nelson wrote:
> Yes, until ACKs come in you can't send any data even though the 
> application has some waiting for you.  You could avoid busy-waiting by 
> not bothering to wait for APP_DATA events until you can actually send 
> something.
> 
> Greg

Thanks Greg.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: errno = ECONNREFUSED
Date: Mon, 26 Feb 2007 03:29:43 -0800
Lines: 7
Distribution: su
Message-ID: <erugb9$khf$3@news.Stanford.EDU>
References: <eru3r6$9gs$1@news.Stanford.EDU> <eru4dk$a6o$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489385 21039 128.12.133.106 (26 Feb 2007 11:29:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eru4dk$a6o$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11925

>> Right now, I just stall until I get the packet I'm looking for (such as 
>> SYN_ACK) during network init.
>>
>> 1.) Is this OK for part A?
>>
For part A you can assume whenever you send a packet it will arrive at 
the other end without duplicates or drops or any nastyness.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: sliding window implementation in part A
Date: Mon, 26 Feb 2007 11:31:14 +0000 (UTC)
Organization: Your Company
Lines: 9
Distribution: su
Message-ID: <Xns98E323D07747Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172489474 19930 128.12.22.217 (26 Feb 2007 11:31:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11926

for part A,

can i assume that the packet is never out of the window bounds? since this 
is reliable and thus, that shouldn't happen.

in other words, will the grading script test this "functionality"?


thanks,
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 03:31:44 -0800
Lines: 25
Distribution: su
Message-ID: <erugf0$krp$1@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489504 21369 128.12.194.72 (26 Feb 2007 11:31:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erufvp$k5d$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11927

Never mind. I figured it out. :)

-Yangfan

Yangfan Wang wrote:
> I'm re-posting this, since it seems to have been buried under the deluge 
> of questions. :p
> 
>  From the man page of gettimeofday:
> 
> struct timeval {
>                time_t         tv_sec;        /* seconds */
>                suseconds_t    tv_usec;  /* microseconds */
> };
> 
> "... gives the number of seconds and microseconds since the Epoch..."
> 
> Question: If the current time is 1.001 seconds after the Epoch, would 
> the tv_usec field have a value of 1 or 1001?
> 
> Similiarly, what about the nanoseconds field in struct timespec?
> 
> Thanks.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Cleanliness of Code?
Date: Mon, 26 Feb 2007 03:39:14 -0800
Lines: 11
Distribution: su
Message-ID: <erugt4$l5f$1@news.Stanford.EDU>
References: <erts6s$1th$1@news.Stanford.EDU> <erttt2$2h9$3@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172489956 21679 128.12.133.106 (26 Feb 2007 11:39:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erttt2$2h9$3@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11928

> Please don't have anything printing. Just remove every line that has the 
> word printf in your code, or make a #define to null them or something. 
> It is very hard to see the output of the grading script if you are 
> printing all sorts of stuff.

Why don't you use the function we gave you? dprintf. If you have

#define DEBUG

then it is just regular printf. It you don't have that define then it 
doesn't do anything.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Testing for parts A and B
Date: Mon, 26 Feb 2007 03:40:40 -0800
Lines: 17
Distribution: su
Message-ID: <erugvn$l6m$1@news.Stanford.EDU>
References: <ertu6r$386$1@news.Stanford.EDU> <erug6k$khf$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490039 21718 128.12.194.72 (26 Feb 2007 11:40:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erug6k$khf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11929

Paul Tarjan (TA) wrote:
> Matt Page wrote:
> 
>> Will our STCP implementations be tested against other STCP 
>> implementations?
>>
>> Thanks,
>> Matt
> 
> 
> Hmm. Good idea! Currently we don't in our grading script, but there is 
> no reason not to. We might make this bonus credit for interoperability. 
> I'll chat with the other TAs about it.

Nice going, Matt. :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 03:46:06 -0800
Lines: 33
Distribution: su
Message-ID: <eruh9u$lia$1@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490366 22090 128.12.194.72 (26 Feb 2007 11:46:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <erufvp$k5d$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11930

Hmm. I can't seem to get the timer to trigger.

In struct timeval, the tv_sec value means "seconds after Epoch". Does 
the tv_sec field in struct timespec carry the same meaning?

Because all I'm doing right now is adding a few seconds to the time 
value that I get from gettimeofday() and then feeding it into 
wait_for_event, but the timer never triggers. I'm running in unreliable 
mode.

-Yangfan

Yangfan Wang wrote:
> I'm re-posting this, since it seems to have been buried under the deluge 
> of questions. :p
> 
>  From the man page of gettimeofday:
> 
> struct timeval {
>                time_t         tv_sec;        /* seconds */
>                suseconds_t    tv_usec;  /* microseconds */
> };
> 
> "... gives the number of seconds and microseconds since the Epoch..."
> 
> Question: If the current time is 1.001 seconds after the Epoch, would 
> the tv_usec field have a value of 1 or 1001?
> 
> Similiarly, what about the nanoseconds field in struct timespec?
> 
> Thanks.
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Mon, 26 Feb 2007 03:46:13 -0800
Lines: 36
Distribution: su
Message-ID: <eruha6$lih$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490374 22097 128.12.133.106 (26 Feb 2007 11:46:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eru125$582$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11931

Seth Wright wrote:
> Also, similar to this is what's the expected behavior for when we get back 
> an ACK that lands half way through a datagram we've already sent (could be 
> caused by it going across the end of the receiver's window)?  Should we 
> retransmit the entire packet (couldn't hurt because the receiver is supposed 
> to ignore data it's already received), or should we just resend the data 
> that didn't get ACKed, or (in conjunction with the Go-back-N stuff) are we 
> supposed to resend all data after the ACK in a series of new datagrams?
Treat the piece that has been ACKed as being done. Your window will now 
start at the unACKed bytes.
>>>
>>> The assignment states that we should retransmit everything:
>>>
>>>     "STCP, like TCP, is a Go-back-N protocol. This means that if the
>>>      transport layer decides that its peer has not received the segment
>>>      with sequence number n, then it will retransmit all data starting
>>>      at n, not just that segment."
>>>
>>> I thought TCP doesn't resend _all_ the data on a timeout. I thought it
>>> just resends the first segment. From RFC793:
All the data please.

>>> The point is, it doesn't make sense to resend everything and buffer out
>>> of order packets at the same time. There is also a conflicting
>>> requirement there in the assignment:
Buffering out of order packets will help if some of the second batch get 
dropped. Its always a good idea to keep any data that you receive incase 
that data won't get to you again.

>>>
>>> "If the timeout for a segment is reached, the segment is examined. If it
>>> has been sent a total of 6 times (once from the original send plus 5
>>> retransmissions), then the network is assumed to have failed and the
>>> network terminated. Otherwise the segment is retransmitted and the
>>> timeout is reset again."
Poorly worded. Send everything.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: robustness with respect to transport layer
Date: Mon, 26 Feb 2007 03:47:21 -0800
Lines: 16
Distribution: su
Message-ID: <eruhca$lih$2@news.Stanford.EDU>
References: <eru78l$csh$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490442 22097 128.12.133.106 (26 Feb 2007 11:47:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eru78l$csh$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11932

Peter Pawlowski wrote:
> Hi--
> 
> How robust should our STCP implementation be to failures in the 
> underlying transport mechanism? In my current implementation, if I 
> Ctrl-C the server, an assert fails in my client due to underlying 
> network calls failing. Is this something we should try to gracefully 
> recover from (even for the final submission)?
> 
> Thanks,
> peter
> 
I think that death happens in code that you can't touch. If you are 
dieing in transport.c, then yes, that is an issue. But if the death 
occurs in another file, don't worry about it. Just make sure that 
everything that YOU control works well.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: duplicate data
Date: Mon, 26 Feb 2007 03:48:50 -0800
Lines: 15
Distribution: su
Message-ID: <eruhf3$lih$3@news.Stanford.EDU>
References: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490531 22097 128.12.133.106 (26 Feb 2007 11:48:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11933

Chun Kai Wang wrote:
> in the assignment, it says that if a packet contains duplicate data, a new 
> ack has to be sent.
> 
> how do u distinguish between duplicate data and data that is out of the 
> receiver window? for part A? since we don't have an incomming buffer? will 
> this be required for A?
> 
> 
In Part A you will NEVER get duplicate data (unless you send duplicate, 
but then you have more to worry about than this!).

If you think about it a bit more, you'll see that there is a difference 
between duplicate data (that you've seen before) and data outside the 
window (that you've never seen before).
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 03:49:49 -0800
Lines: 23
Distribution: su
Message-ID: <eruhgv$lih$4@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490591 22097 128.12.133.106 (26 Feb 2007 11:49:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erufvp$k5d$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11934

Yangfan Wang wrote:
> I'm re-posting this, since it seems to have been buried under the deluge 
> of questions. :p
> 
>  From the man page of gettimeofday:
> 
> struct timeval {
>                time_t         tv_sec;        /* seconds */
>                suseconds_t    tv_usec;  /* microseconds */
> };
> 
> "... gives the number of seconds and microseconds since the Epoch..."
> 
> Question: If the current time is 1.001 seconds after the Epoch, would 
> the tv_usec field have a value of 1 or 1001?
> 
> Similiarly, what about the nanoseconds field in struct timespec?
> 
> Thanks.
> 
> -Yangfan
Please google it. I'd have to look it up just the same as you. If you 
don't want to google it, try printing it out and looking at it.
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 03:53:15 -0800
Lines: 14
Distribution: su
Message-ID: <eruhnb$lt2$1@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU> <eruhgv$lih$4@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490795 22434 128.12.194.72 (26 Feb 2007 11:53:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eruhgv$lih$4@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11935

Paul Tarjan (TA) wrote:
> Please google it. I'd have to look it up just the same as you. If you 
> don't want to google it, try printing it out and looking at it.

Paul, are you sure having TIMEOUT defined as 0 will work?

I don't seem to be getting TIMEOUT events if I wait for ANYEVENT. This 
is most likely due to the fact that ANYEVENT | TIMEOUT is 0. Is this 
intentional?

It seems to me that I should get TIMEOUT events if I wait for ANYEVENT. 
I'd change it myself, but the code is inside stcp_api.h.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 03:54:53 -0800
Lines: 21
Distribution: su
Message-ID: <eruhqc$lt2$2@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU> <eruhgv$lih$4@news.Stanford.EDU> <eruhnb$lt2$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172490893 22434 128.12.194.72 (26 Feb 2007 11:54:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eruhnb$lt2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11936

Yangfan Wang wrote:
> Paul Tarjan (TA) wrote:
> 
>> Please google it. I'd have to look it up just the same as you. If you 
>> don't want to google it, try printing it out and looking at it.
> 
> 
> Paul, are you sure having TIMEOUT defined as 0 will work?
> 
> I don't seem to be getting TIMEOUT events if I wait for ANYEVENT. This 
> is most likely due to the fact that ANYEVENT | TIMEOUT is 0. Is this 
> intentional?
> 
> It seems to me that I should get TIMEOUT events if I wait for ANYEVENT. 
> I'd change it myself, but the code is inside stcp_api.h.
> 
> -Yangfan

Oh wait. I get it. Ha! That's tricky. Never mind. :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 04:13:54 -0800
Lines: 38
Distribution: su
Message-ID: <eruiu2$og3$1@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU> <eruhgv$lih$4@news.Stanford.EDU> <eruhnb$lt2$1@news.Stanford.EDU> <eruhqc$lt2$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172492034 25091 128.12.194.72 (26 Feb 2007 12:13:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eruhqc$lt2$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11937

Yangfan Wang wrote:
> Yangfan Wang wrote:
> 
>> Paul Tarjan (TA) wrote:
>>
>>> Please google it. I'd have to look it up just the same as you. If you 
>>> don't want to google it, try printing it out and looking at it.
>>
>>
>>
>> Paul, are you sure having TIMEOUT defined as 0 will work?
>>
>> I don't seem to be getting TIMEOUT events if I wait for ANYEVENT. This 
>> is most likely due to the fact that ANYEVENT | TIMEOUT is 0. Is this 
>> intentional?
>>
>> It seems to me that I should get TIMEOUT events if I wait for 
>> ANYEVENT. I'd change it myself, but the code is inside stcp_api.h.
>>
>> -Yangfan
> 
> 
> Oh wait. I get it. Ha! That's tricky. Never mind. :)
> 
> -Yangfan

Huh.

So calling stcp_wait_for_event(sd, TIMEOUT, abs time) works as expected.

but if I call stcp_wait_for_event(sd, ANYEVENT, abs time) with absolute 
time being a few seconds after all other events have stopped occuring, 
the whole program just blocks.

I've looked through the source code for stcp_wait_for_event and don't 
see how this could be happening. I'm stumped. :(

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: duplicate data
Date: Mon, 26 Feb 2007 12:16:52 +0000 (UTC)
Organization: Your Company
Lines: 28
Distribution: su
Message-ID: <Xns98E32B8D9E934chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103> <eruhf3$lih$3@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172492212 25137 128.12.22.217 (26 Feb 2007 12:16:52 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11938

for part A, since everything is in order, and no dropping packets, can i 
assume that everything it receives is "in the window" ? 







"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in
news:eruhf3$lih$3@news.Stanford.EDU: 

> Chun Kai Wang wrote:
>> in the assignment, it says that if a packet contains duplicate data,
>> a new ack has to be sent.
>> 
>> how do u distinguish between duplicate data and data that is out of
>> the receiver window? for part A? since we don't have an incomming
>> buffer? will this be required for A?
>> 
>> 
> In Part A you will NEVER get duplicate data (unless you send
> duplicate, but then you have more to worry about than this!).
> 
> If you think about it a bit more, you'll see that there is a
> difference between duplicate data (that you've seen before) and data
> outside the window (that you've never seen before).

.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Question on timer:
Date: Mon, 26 Feb 2007 04:20:27 -0800
Lines: 49
Distribution: su
Message-ID: <erujab$oma$1@news.Stanford.EDU>
References: <erufvp$k5d$1@news.Stanford.EDU> <eruhgv$lih$4@news.Stanford.EDU> <eruhnb$lt2$1@news.Stanford.EDU> <eruhqc$lt2$2@news.Stanford.EDU> <eruiu2$og3$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172492427 25290 128.12.194.72 (26 Feb 2007 12:20:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eruiu2$og3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11939

Yangfan Wang wrote:
> Yangfan Wang wrote:
> 
>> Yangfan Wang wrote:
>>
>>> Paul Tarjan (TA) wrote:
>>>
>>>> Please google it. I'd have to look it up just the same as you. If 
>>>> you don't want to google it, try printing it out and looking at it.
>>>
>>>
>>>
>>>
>>> Paul, are you sure having TIMEOUT defined as 0 will work?
>>>
>>> I don't seem to be getting TIMEOUT events if I wait for ANYEVENT. 
>>> This is most likely due to the fact that ANYEVENT | TIMEOUT is 0. Is 
>>> this intentional?
>>>
>>> It seems to me that I should get TIMEOUT events if I wait for 
>>> ANYEVENT. I'd change it myself, but the code is inside stcp_api.h.
>>>
>>> -Yangfan
>>
>>
>>
>> Oh wait. I get it. Ha! That's tricky. Never mind. :)
>>
>> -Yangfan
> 
> 
> Huh.
> 
> So calling stcp_wait_for_event(sd, TIMEOUT, abs time) works as expected.
> 
> but if I call stcp_wait_for_event(sd, ANYEVENT, abs time) with absolute 
> time being a few seconds after all other events have stopped occuring, 
> the whole program just blocks.
> 
> I've looked through the source code for stcp_wait_for_event and don't 
> see how this could be happening. I'm stumped. :(
> 
> -Yangfan

Never mind.

(Writing on the newsgroup is a great way to debug.) :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Madeleine Lam" <mlamone@cisco.com>
Newsgroups: su.class.cs244a
Subject: stcp_network_recv() when getting STCP_MSS bytes
Date: Mon, 26 Feb 2007 07:26:42 -0800
Lines: 15
Distribution: su
Message-ID: <eruu7j$625$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172503604 6213 127.0.0.1 (26 Feb 2007 15:26:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4968.1600
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4971.600
Xref: shelby.stanford.edu su.class.cs244a:11940

I ran into a bug that when stcp_network_recv() returns size_t which is equal
to STCP_MSS, stcp_network_recv() will fail as follows on the client:

proxyget: stcp_api.c:166: ssize_t stcp_network_recv(mysocket_t, void*,
size_t): Assertion `len <= 0 ||
_mysock_verify_checksum(_mysock_get_context(sd), dst, len)' failed.
Abort

I could not understand why stcp_network_recv() fails with STCP_MSS bytes of
data.  Please help.

Thanks,
Madeleine


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Mon, 26 Feb 2007 08:22:27 -0800
Lines: 13
Distribution: su
Message-ID: <erv1ed$8sv$1@news.Stanford.EDU>
References: <erof5a$i2g$2@news.Stanford.EDU> <C206331E.8B3A%jpettit@stanford.edu> <errvkt$9l7$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172506893 9119 127.0.0.1 (26 Feb 2007 16:21:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11941

> If the current time is 1.001 seconds after the Epoch, would the 
> suseconds_t field have a value of 1 or 1001?
1000 (its in usec)
>
> Similiarly, what about the nanoseconds field in struct timespec?
1000000 (its in nsec)

HTH,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp_network_recv strange behavior?
Date: Mon, 26 Feb 2007 08:37:59 -0800
Lines: 15
Distribution: su
Message-ID: <erv2bh$9ki$1@news.Stanford.EDU>
References: <ert17m$a9u$1@news.Stanford.EDU> <erto17$s5u$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172507825 9874 127.0.0.1 (26 Feb 2007 16:37:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11942

> figure it out..send the wrong size packet -_-''
>> stcp_network_recv(sd,(char*)segment,556); *note the max_len = 556*
>>
>> What I got from the return value of the function is 560.
>> How is this possible since I explicitly said that the max_len is 556??
Uh, you still should not get over 556 bytes.  If it is, then the mysocket 
code has a bug: it's overrunning your buffer.  (Of course, you may have 
appreciated it this time, as it helped you catch a bug!)

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: stcp_network_recv() when getting STCP_MSS bytes
Date: Mon, 26 Feb 2007 08:50:25 -0800
Lines: 22
Distribution: su
Message-ID: <erv32s$aak$1@news.Stanford.EDU>
References: <eruu7j$625$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172508572 10580 127.0.0.1 (26 Feb 2007 16:49:32 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11943

I think the discussion in the thread "max payload size" might help...
"Madeleine Lam" <mlamone@cisco.com> wrote in message 
news:eruu7j$625$1@news.Stanford.EDU...
>I ran into a bug that when stcp_network_recv() returns size_t which is 
>equal
> to STCP_MSS, stcp_network_recv() will fail as follows on the client:
>
> proxyget: stcp_api.c:166: ssize_t stcp_network_recv(mysocket_t, void*,
> size_t): Assertion `len <= 0 ||
> _mysock_verify_checksum(_mysock_get_context(sd), dst, len)' failed.
> Abort
>
> I could not understand why stcp_network_recv() fails with STCP_MSS bytes 
> of
> data.  Please help.
>
> Thanks,
> Madeleine
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: TIME_WAIT and LAST_ACK states
Date: Mon, 26 Feb 2007 08:50:50 -0800
Lines: 19
Distribution: su
Message-ID: <erv354$a2s$1@news.Stanford.EDU>
References: <eru4dr$a6v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172508644 10332 127.0.0.1 (26 Feb 2007 16:50:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <eru4dr$a6v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11944

Jad Naous wrote:
> Hi,
> 
> Somewhere in the assignment it says we are not supposed to implement the
> TIME_WAIT state. That means in an unreliable connection, we might not
> get an ACK for a FIN sent by the server-side TCP (while waiting in the
> LAST_ACK state). Does that mean that we shouldn't implement the LAST_ACK
> state either?
> 
> Thanks,
> Jad.

TIME_WAIT means you have issued a fin and received an ack for it, and 
now the remote side issued a fin, you ack'd it, but you stick around for 
some period of time to resend that ack in case it got lost.  We say you 
are not required to do this, in that once you send your ack you are 
welcome to close the socket and assume it got there.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: hum... weird bug...
Date: Mon, 26 Feb 2007 08:51:47 -0800
Lines: 21
Distribution: su
Message-ID: <erv36t$a2s$2@news.Stanford.EDU>
References: <Xns98E3220ED0FCchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172508701 10332 127.0.0.1 (26 Feb 2007 16:51:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E3220ED0FCchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11945

Chun Kai Wang wrote:
> i have a really weird bug...
> 
> it takes more than 1 minute to transfer 6kb... i have an 8kb file and it's 
> transmitting over 3 minutes...
> 
> 
> is this normal? i'm transmitting from myth 22 to myth 15.
> 
> 
> somehow, it takes a long time for the ack packets to reach the server....
> 
> 
> 
> help

That is pretty strange, the latency between those machines shouldn't be 
more than a couple ms at most, you may want to try a pair of different 
myths, or work on sending on the same machine.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: duplicate data
Date: Mon, 26 Feb 2007 08:53:48 -0800
Lines: 36
Distribution: su
Message-ID: <erv3am$a2s$3@news.Stanford.EDU>
References: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103> <eruhf3$lih$3@news.Stanford.EDU> <Xns98E32B8D9E934chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172508822 10332 127.0.0.1 (26 Feb 2007 16:53:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E32B8D9E934chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11946

Chun Kai Wang wrote:
> for part A, since everything is in order, and no dropping packets, can i 
> assume that everything it receives is "in the window" ? 
> 
> 
> 
> 
> 
> 
> 
> "Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in
> news:eruhf3$lih$3@news.Stanford.EDU: 
> 
>> Chun Kai Wang wrote:
>>> in the assignment, it says that if a packet contains duplicate data,
>>> a new ack has to be sent.
>>>
>>> how do u distinguish between duplicate data and data that is out of
>>> the receiver window? for part A? since we don't have an incomming
>>> buffer? will this be required for A?
>>>
>>>
>> In Part A you will NEVER get duplicate data (unless you send
>> duplicate, but then you have more to worry about than this!).
>>
>> If you think about it a bit more, you'll see that there is a
>> difference between duplicate data (that you've seen before) and data
>> outside the window (that you've never seen before).
> 

You should be checking against the window on both sides, at the sender 
you should never send more than the advertised window, and the receiver 
should be checking its own window so it knows what to advertise to the 
sender.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window implementation in part A
Date: Mon, 26 Feb 2007 08:56:02 -0800
Lines: 15
Distribution: su
Message-ID: <erv3es$a2s$4@news.Stanford.EDU>
References: <Xns98E323D07747Echunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172508956 10332 127.0.0.1 (26 Feb 2007 16:55:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <Xns98E323D07747Echunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11947

Chun Kai Wang wrote:
> for part A,
> 
> can i assume that the packet is never out of the window bounds? since this 
> is reliable and thus, that shouldn't happen.
> 
> in other words, will the grading script test this "functionality"?
> 
> 
> thanks,

The data you send should not be more than what your receiver advertises 
it is willing to accept.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: duplicate data
Date: Mon, 26 Feb 2007 12:39:53 -0500
Lines: 38
Distribution: su
Message-ID: <erv617$cq8$1@news.Stanford.EDU>
References: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103> <eruhf3$lih$3@news.Stanford.EDU> <Xns98E32B8D9E934chunkaiwstanfordedu@171.64.14.103> <erv3am$a2s$3@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172511591 13128 127.0.0.1 (26 Feb 2007 17:39:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11948

Hmm.  The assignment says that STCP has a fixed receive window or 3072 
bytes, so I'd assumed we didn't have to advertise anything different, but 
rather just take into account the fact that the peer might not be STCP and 
handle the case of a changing receive window on the peer.

Seth

"David Erickson" <derickso@stanford.edu> wrote in message 
news:erv3am$a2s$3@news.Stanford.EDU...
> Chun Kai Wang wrote:
>> for part A, since everything is in order, and no dropping packets, can i 
>> assume that everything it receives is "in the window" ? "Paul Tarjan 
>> (TA)" <ptarjan@stanford.edu> wrote in
>> news:eruhf3$lih$3@news.Stanford.EDU:
>>> Chun Kai Wang wrote:
>>>> in the assignment, it says that if a packet contains duplicate data,
>>>> a new ack has to be sent.
>>>>
>>>> how do u distinguish between duplicate data and data that is out of
>>>> the receiver window? for part A? since we don't have an incomming
>>>> buffer? will this be required for A?
>>>>
>>>>
>>> In Part A you will NEVER get duplicate data (unless you send
>>> duplicate, but then you have more to worry about than this!).
>>>
>>> If you think about it a bit more, you'll see that there is a
>>> difference between duplicate data (that you've seen before) and data
>>> outside the window (that you've never seen before).
>>
>
> You should be checking against the window on both sides, at the sender you 
> should never send more than the advertised window, and the receiver should 
> be checking its own window so it knows what to advertise to the sender.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window implementation in part A
Date: Mon, 26 Feb 2007 12:44:46 -0500
Lines: 30
Distribution: su
Message-ID: <erv6ac$d4j$1@news.Stanford.EDU>
References: <Xns98E323D07747Echunkaiwstanfordedu@171.64.14.103> <erv3es$a2s$4@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172511884 13459 127.0.0.1 (26 Feb 2007 17:44:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11949

Right, but in part A we don't really need a receive buffer, so all data is 
immediately consumed once it arrives from the network, so the only time we 
could accept data out of the bounds of the window is if we got repeat data 
which shouldn't happen in part A, or if the payload is greater than our 
entire window - which, since we're ignoring the options fields, will be 
fixed at 536 bytes, much lower than our window of 3072 bytes.  So I'm not 
sure how you'd test this functionality in part A.  Is there something I'm 
missing here?

Seth

"David Erickson" <derickso@stanford.edu> wrote in message 
news:erv3es$a2s$4@news.Stanford.EDU...
> Chun Kai Wang wrote:
>> for part A,
>>
>> can i assume that the packet is never out of the window bounds? since 
>> this is reliable and thus, that shouldn't happen.
>>
>> in other words, will the grading script test this "functionality"?
>>
>>
>> thanks,
>
> The data you send should not be more than what your receiver advertises it 
> is willing to accept.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: duplicate data
Date: Mon, 26 Feb 2007 09:54:46 -0800
Lines: 11
Distribution: su
Message-ID: <erv6t0$dkt$1@news.Stanford.EDU>
References: <Xns98E3168A01A9Achunkaiwstanfordedu@171.64.14.103> <eruhf3$lih$3@news.Stanford.EDU> <Xns98E32B8D9E934chunkaiwstanfordedu@171.64.14.103> <erv3am$a2s$3@news.Stanford.EDU> <erv617$cq8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172512480 13981 127.0.0.1 (26 Feb 2007 17:54:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erv617$cq8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11950

Seth Wright wrote:
> Hmm.  The assignment says that STCP has a fixed receive window or 3072 
> bytes, so I'd assumed we didn't have to advertise anything different, but 
> rather just take into account the fact that the peer might not be STCP and 
> handle the case of a changing receive window on the peer.
> 
> Seth

You are correct, my mistake :)

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window implementation in part A
Date: Mon, 26 Feb 2007 09:55:29 -0800
Lines: 15
Distribution: su
Message-ID: <erv6ub$dkt$2@news.Stanford.EDU>
References: <Xns98E323D07747Echunkaiwstanfordedu@171.64.14.103> <erv3es$a2s$4@news.Stanford.EDU> <erv6ac$d4j$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172512523 13981 127.0.0.1 (26 Feb 2007 17:55:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <erv6ac$d4j$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11951

Seth Wright wrote:
> Right, but in part A we don't really need a receive buffer, so all data is 
> immediately consumed once it arrives from the network, so the only time we 
> could accept data out of the bounds of the window is if we got repeat data 
> which shouldn't happen in part A, or if the payload is greater than our 
> entire window - which, since we're ignoring the options fields, will be 
> fixed at 536 bytes, much lower than our window of 3072 bytes.  So I'm not 
> sure how you'd test this functionality in part A.  Is there something I'm 
> missing here?
> 
> Seth

Nope you hit the nail on the head.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Bug in stcp_api.c
Date: Mon, 26 Feb 2007 11:08:41 -0700
Lines: 17
Distribution: su
Message-ID: <erv7na$etk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172513322 15284 127.0.0.1 (26 Feb 2007 18:08:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11952

stcp_wait_for_event never bothers to check the caller's APP_CLOSE_REQUESTED 
flag.

Someone altered the implementation at line 78 to ensure that the close 
requested event would only be reported once.  It's fine to report the event 
only once, but the semantics of the function call clearly intend that it be 
reported only when asked for.  The way it's currently written, this event 
will be reported *regardless* of whether it's asked for or not by the 
caller.  If the /* and the */ were removed, then I think the function would 
work as intended.

TAs, if you agree, will you please fix this in your code (or allow us to fix 
it) so that we don't have to tie our own code in knots to work around it?

--Kevin 


.

Path: shelby.stanford.edu!not-for-mail
From: Paolo <paolo@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 11:23:00 -0800
Lines: 20
Distribution: su
Message-ID: <pan.2007.02.26.19.23.00.329876@cs.stanford.edu>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU>
NNTP-Posting-Host: mugen.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172517258 20212 128.12.186.133 (26 Feb 2007 19:14:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Xref: shelby.stanford.edu su.class.cs244a:11953

On Mon, 26 Feb 2007 02:18:51 -0800, Ajay Martin wrote:

> 
> "Greg Nelson" <grourk@stanford.edu> wrote in message 
> news:ertuqd$3ls$1@news.Stanford.EDU...
>> Now that I'm using my own proxy it seems to work consistently.  Except 
>> with http://en.wikipedia.org/...  it looks like they're not returning any 
>> HTTP headers with their document which confuses my proxy, but that doesn't 
>> really involve STCP.  Every other site I've tested seems to work.
>>
>> Are you seeing the issue just with http://www.stanford.edu?
> 
> This ones quite weird!
> I'm seeing the same issue ( The server waiting in stcp_wait_for_event and 
> the client sits waiting for an ACK.), and only with http://www.stanford.edu.


I'm not exactly sure what is going on. But for the record, I switched to
my proxy too and everything seems to be working now (all urls mentioned in
this thread).
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Mon, 26 Feb 2007 11:21:09 -0800
Lines: 15
Distribution: su
Message-ID: <ervbtv$j3s$1@news.Stanford.EDU>
References: <erof5a$i2g$2@news.Stanford.EDU> <C206331E.8B3A%jpettit@stanford.edu> <errvkt$9l7$1@news.Stanford.EDU> <erv1ed$8sv$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172517631 19580 127.0.0.1 (26 Feb 2007 19:20:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <erv1ed$8sv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11954

Wouldn't 1.001 seconds be 1001000 usec and 1001000000 nsec?

Randy Jennings wrote:
>> If the current time is 1.001 seconds after the Epoch, would the 
>> suseconds_t field have a value of 1 or 1001?
> 1000 (its in usec)
>> Similiarly, what about the nanoseconds field in struct timespec?
> 1000000 (its in nsec)
> 
> HTH,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 11:22:07 -0800
Lines: 1
Distribution: su
Message-ID: <ervbvp$j3s$2@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172517689 19580 127.0.0.1 (26 Feb 2007 19:21:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <pan.2007.02.26.19.23.00.329876@cs.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:11955

I wonder how indented we can get this thread...
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 11:41:57 -0800
Lines: 19
Distribution: su
Message-ID: <ervd6m$l9e$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1172518934 21806 171.64.75.59 (26 Feb 2007 19:42:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11956

Hi,
I'm having the same problem as you guys.. (relieved to see this thread!)

One interesting thing I noticed is that, if you gdb proxyget and
*slowly* receive packets, then proxy properly sends the FIN packet
and the connection terminates. If I just run the code on gdb without
breaking, the same error occurs (i.e., the freeze at the end).

Hence, I think there is some race condition in the proxy code that
somehow drops the FIN packet to be sent.

-Steven


"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:ervbvp$j3s$2@news.Stanford.EDU...
>I wonder how indented we can get this thread... 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More questions on timer.
Date: Mon, 26 Feb 2007 12:01:57 -0800
Lines: 9
Distribution: su
Message-ID: <ervea1$mk9$1@news.Stanford.EDU>
References: <erof5a$i2g$2@news.Stanford.EDU> <C206331E.8B3A%jpettit@stanford.edu> <errvkt$9l7$1@news.Stanford.EDU> <erv1ed$8sv$1@news.Stanford.EDU> <ervbtv$j3s$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172520065 23177 127.0.0.1 (26 Feb 2007 20:01:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11957

> Wouldn't 1.001 seconds be 1001000 usec and 1001000000 nsec?
What you say is correct, but I was saying what was in the tv_u/nsec field.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Bug in stcp_api.c
Date: Mon, 26 Feb 2007 12:03:35 -0800
Lines: 15
Distribution: su
Message-ID: <erved2$mp4$1@news.Stanford.EDU>
References: <erv7na$etk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172520163 23332 127.0.0.1 (26 Feb 2007 20:02:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11958

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:erv7na$etk$1@news.Stanford.EDU...
> TAs, if you agree, will you please fix this in your code (or allow us to 
> fix it) so that we don't have to tie our own code in knots to work around 
> it?

Just curious, when are you turning off APP_CLOSE_REQUESTED before it is 
delivered once?

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Kavin Asavanant <kavin@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW3A submission files
Date: Mon, 26 Feb 2007 12:27:13 -0800
Lines: 16
Distribution: su
Message-ID: <ervfr2$o90$1@news.Stanford.EDU>
References: <ersp85$2op$1@news.Stanford.EDU> <ert47r$c94$3@news.Stanford.EDU> <ertsta$2be$1@news.Stanford.EDU> <erttje$2h9$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172521634 24864 127.0.0.1 (26 Feb 2007 20:27:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
In-Reply-To: <erttje$2h9$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11959

Are we submitting the files through the website normally? or should
we send the tar file to the TA?

Thanks,
Kavin

Paul Tarjan (TA) wrote:
> Riju Kallivalappil wrote:
>> Do we need to submit a README file for 3A? I remember seeing in 
>> another thread that TA's care only about the functionality in 3A.
>>
> If you are confident enough that you will get 100% and I will not have 
> to look at your code, you only need a README with your name. But if you 
> get something wrong and I have to poke into your code, if I have a 
> readme, it makes it much easier to find a problem instead of just giving 
> up and letting you fail the test.
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 13:02:16 -0800
Lines: 3
Distribution: su
Message-ID: <ervhrh$q8b$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU> <ervd6m$l9e$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172523697 26891 127.0.0.1 (26 Feb 2007 21:01:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <ervd6m$l9e$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11960

I've actually seen this occur with my own proxy a few times now, 
although not as frequently as with the reference proxy.  Could there be 
something wrong with the simulated network code underneath our STCP layer?
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Bug in stcp_api.c
Date: Mon, 26 Feb 2007 14:28:38 -0700
Lines: 24
Distribution: su
Message-ID: <ervje9$rsb$1@news.Stanford.EDU>
References: <erv7na$etk$1@news.Stanford.EDU> <erved2$mp4$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172525322 28555 127.0.0.1 (26 Feb 2007 21:28:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11961

I use separate send and receive threads.  They care about different events. 
That should work given the promises made in stcp_api.h.

--Kevin

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:erved2$mp4$1@news.Stanford.EDU...
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:erv7na$etk$1@news.Stanford.EDU...
>> TAs, if you agree, will you please fix this in your code (or allow us to 
>> fix it) so that we don't have to tie our own code in knots to work around 
>> it?
>
> Just curious, when are you turning off APP_CLOSE_REQUESTED before it is 
> delivered once?
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: robustness with respect to transport layer
Date: Mon, 26 Feb 2007 13:45:41 -0800
Lines: 18
Distribution: su
Message-ID: <ervkei$sp7$1@news.Stanford.EDU>
References: <eru78l$csh$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172526354 29479 127.0.0.1 (26 Feb 2007 21:45:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:11962

I imagine that when you implement timeouts there will just eventually 
be 6 successive packets that are not ACKED, and your client should 
terminate the connection by normal means.

On 2007-02-26 00:54:45 -0800, Peter Pawlowski <pawlowski@stanford.edu> said:

> Hi--
> 
> How robust should our STCP implementation be to failures in the 
> underlying transport mechanism? In my current implementation, if I 
> Ctrl-C the server, an assert fails in my client due to underlying 
> network calls failing. Is this something we should try to gracefully 
> recover from (even for the final submission)?
> 
> Thanks,
> peter


.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Mon, 26 Feb 2007 13:50:55 -0800
Lines: 10
Distribution: su
Message-ID: <ervko1$45$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU> <ervd6m$l9e$1@news.Stanford.EDU> <ervhrh$q8b$1@news.Stanford.EDU>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1172526657 133 128.12.137.162 (26 Feb 2007 21:50:57 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:11963


"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:ervhrh$q8b$1@news.Stanford.EDU...
> I've actually seen this occur with my own proxy a few times now, although 
> not as frequently as with the reference proxy.  Could there be something 
> wrong with the simulated network code underneath our STCP layer?

After looking at it for a while, I actually came to the same conclusion too. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Bug in stcp_api.c
Date: Mon, 26 Feb 2007 15:43:50 -0800
Lines: 26
Distribution: su
Message-ID: <ervra1$7rj$1@news.Stanford.EDU>
References: <erv7na$etk$1@news.Stanford.EDU> <erved2$mp4$1@news.Stanford.EDU> <ervje9$rsb$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172533378 8051 127.0.0.1 (26 Feb 2007 23:42:58 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11964

I see.  More threads!  Yes, I can see why you would want the API to work 
like it claims.

Sincerely,
Randy Jennings

The squirrels are your friends!
>I use separate send and receive threads.  They care about different events. 
>That should work given the promises made in stcp_api.h.
>>> TAs, if you agree, will you please fix this in your code (or allow us to 
>>> fix it) so that we don't have to tie our own code in knots to work 
>>> around it?
>>
>> Just curious, when are you turning off APP_CLOSE_REQUESTED before it is 
>> delivered once?
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Sanjay Jeyakumar <sjeyakum@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Tue, 27 Feb 2007 00:02:50 +0000 (UTC)
Lines: 19
Distribution: su
Message-ID: <ervsfa$92g$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU> <ervd6m$l9e$1@news.Stanford.EDU> <ervhrh$q8b$1@news.Stanford.EDU> <ervko1$45$1@news.Stanford.EDU>
NNTP-Posting-Host: myth19.stanford.edu
X-Trace: news.Stanford.EDU 1172534570 9296 171.64.15.39 (27 Feb 2007 00:02:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11965

Ajay Martin <ajaym@stanford.edu> wrote:

> "Greg Nelson" <grourk@stanford.edu> wrote in message 
> news:ervhrh$q8b$1@news.Stanford.EDU...
> > I've actually seen this occur with my own proxy a few times now, although 
> > not as frequently as with the reference proxy.  Could there be something 
> > wrong with the simulated network code underneath our STCP layer?

> After looking at it for a while, I actually came to the same conclusion too. 

FWIW, I saw the same issue. My client got stuck in the LAST_FINACK
state while the server on the FINWAIT2 state. I added debug print 
outs and noticed that though the last FIN packet was being sent on
the client while going from the CLOSE_WAIT to the LAST_ACK state, 
the server never received the packet. I'm inclined to believe that 
there's a bug with the underlying network layer too. 

Sanjay

.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Tue, 27 Feb 2007 00:17:25 +0000 (UTC)
Lines: 35
Distribution: su
Message-ID: <ervtal$a70$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU> <ervd6m$l9e$1@news.Stanford.EDU> <ervhrh$q8b$1@news.Stanford.EDU> <ervko1$45$1@news.Stanford.EDU> <ervsfa$92g$1@news.Stanford.EDU>
NNTP-Posting-Host: myth22.stanford.edu
X-Trace: news.Stanford.EDU 1172535445 10464 171.64.15.36 (27 Feb 2007 00:17:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:11966

Hi,

I also faced the similar issues. But after changing proxyget.c to have
bool_t is_reliable = 1;
  if (!strncmp("-U", argv[nextarg], 2)) {
    is_reliable = 0;
    nextarg++;
  }
I don't see any closing issue. I tried both my proxy and TA proxy.
May be I'm not trying the correct website. Can you please mention the
troublesome website.

Thanks,
Dinesh

Sanjay Jeyakumar <sjeyakum@stanford.edu> wrote:
> Ajay Martin <ajaym@stanford.edu> wrote:

> > "Greg Nelson" <grourk@stanford.edu> wrote in message 
> > news:ervhrh$q8b$1@news.Stanford.EDU...
> > > I've actually seen this occur with my own proxy a few times now, although 
> > > not as frequently as with the reference proxy.  Could there be something 
> > > wrong with the simulated network code underneath our STCP layer?

> > After looking at it for a while, I actually came to the same conclusion too. 

> FWIW, I saw the same issue. My client got stuck in the LAST_FINACK
> state while the server on the FINWAIT2 state. I added debug print 
> outs and noticed that though the last FIN packet was being sent on
> the client while going from the CLOSE_WAIT to the LAST_ACK state, 
> the server never received the packet. I'm inclined to believe that 
> there's a bug with the underlying network layer too. 

> Sanjay

.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Testing for parts A and B
Date: Mon, 26 Feb 2007 16:35:16 -0800
Lines: 12
Distribution: su
Message-ID: <ervuc4$bdh$1@news.Stanford.EDU>
References: <ertu6r$386$1@news.Stanford.EDU> <erug6k$khf$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172536516 11697 128.12.104.61 (27 Feb 2007 00:35:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
In-Reply-To: <erug6k$khf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11967

Paul Tarjan (TA) wrote:
> Matt Page wrote:
>> Will our STCP implementations be tested against other STCP 
>> implementations?
>>
>> Thanks,
>> Matt
> 
> Hmm. Good idea! Currently we don't in our grading script, but there is 
> no reason not to. We might make this bonus credit for interoperability. 
> I'll chat with the other TAs about it.
Why did I open my big mouth =)
.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxy submission for 3C
Date: Mon, 26 Feb 2007 17:17:12 -0800
Lines: 19
Distribution: su
Message-ID: <es00qp$eib$1@news.Stanford.EDU>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1172539033 14923 128.12.137.162 (27 Feb 2007 01:17:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11968

http://www.stanford.edu/class/cs244a/hw3/milestone3.html says that 
deliverables for milestone HW3.C of this assignment are:
  1.. Your modified transport.c
  2.. *.c - Source code for the web proxy (only if using your web proxy)
  3.. README
  4.. Makefile
and in another location it says

a.. Proxy.a : This is the reference implementation for the proxy. You can 
test against ours to see if your transport.c is working. You will be 
replacing this for part C.


I would guess that we cannot submit 3C with the reference implementation 
proxy. Or can we?

Ajay 


.

Path: shelby.stanford.edu!not-for-mail
From: Sanjay Jeyakumar <sjeyakum@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: More fun with proxys!
Date: Tue, 27 Feb 2007 01:37:19 +0000 (UTC)
Lines: 20
Distribution: su
Message-ID: <es020f$fg8$1@news.Stanford.EDU>
References: <eronc6$nr8$1@news.Stanford.EDU> <eronti$obp$1@news.Stanford.EDU> <erooe6$oph$1@news.Stanford.EDU> <erooqj$oul$1@news.Stanford.EDU> <eropa1$pdk$1@news.Stanford.EDU> <erqks0$3lm$1@news.Stanford.EDU> <errgt8$pt3$1@news.Stanford.EDU> <errhtc$qee$1@news.Stanford.EDU> <errkkt$rui$1@news.Stanford.EDU> <errlpu$shs$1@news.Stanford.EDU> <errp43$1dr$1@news.Stanford.EDU> <errpou$23m$1@news.Stanford.EDU> <errqlv$3or$1@news.Stanford.EDU> <erst3t$5r0$1@news.Stanford.EDU> <ert40q$c94$2@news.Stanford.EDU> <ert8le$g6r$1@news.Stanford.EDU> <pan.2007.02.26.06.04.57.614864@cs.stanford.edu> <ertuqd$3ls$1@news.Stanford.EDU> <eruc6l$gce$1@news.Stanford.EDU> <pan.2007.02.26.19.23.00.329876@cs.stanford.edu> <ervbvp$j3s$2@news.Stanford.EDU> <ervd6m$l9e$1@news.Stanford.EDU> <ervhrh$q8b$1@news.Stanford.EDU> <ervko1$45$1@news.Stanford.EDU> <ervsfa$92g$1@news.Stanford.EDU> <ervtal$a70$1@news.Stanford.EDU>
NNTP-Posting-Host: elaine10.stanford.edu
X-Trace: news.Stanford.EDU 1172540239 15880 171.64.15.75 (27 Feb 2007 01:37:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (SunOS/5.8 (sun4u))
Xref: shelby.stanford.edu su.class.cs244a:11969

Dinesh Gupta <dineshg@stanford.edu> wrote:
> Hi,

> I also faced the similar issues. But after changing proxyget.c to have
> bool_t is_reliable = 1;
>   if (!strncmp("-U", argv[nextarg], 2)) {
>     is_reliable = 0;
>     nextarg++;
>   }
> I don't see any closing issue. I tried both my proxy and TA proxy.
> May be I'm not trying the correct website. Can you please mention the
> troublesome website.

I'm pretty certain I'm running in reliable mode. I was able to reproduce
pretty consistently with www.stanford.edu after 4-5 tries. But a lot of
the websites face similar issues if you run it a sufficient number of
times. Seems like a timing issue. 

Sanjay

.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 03:09:45 -0500
Lines: 21
Distribution: su
Message-ID: <es0p0c$8e9$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172563789 8649 127.0.0.1 (27 Feb 2007 08:09:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11972

Can I ask why we want STCP to use go back n?  It seems easier to me to do 
what TCP actually does (or at least what Kurose says TCP actually does), so 
why the change?  My STCP implementation is done in a way where retransmits 
of individual lost segments would be fairly easy and, while I can do the 
extra work to downgrade my STCP, I'd like to at least know why I'm doing so 
and why I'd be penalized if I did what TCP actually does.

I don't know if that came out right, tact can be a touchy thing over a 
newsgroup.  :)

-Seth

>>>> "If the timeout for a segment is reached, the segment is examined. If 
>>>> it
>>>> has been sent a total of 6 times (once from the original send plus 5
>>>> retransmissions), then the network is assumed to have failed and the
>>>> network terminated. Otherwise the segment is retransmitted and the
>>>> timeout is reset again."
> Poorly worded. Send everything. 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 00:48:01 -0800
Lines: 30
Distribution: su
Message-ID: <es0r7v$apk$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU> <es0p0c$8e9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172566079 11060 128.12.194.72 (27 Feb 2007 08:47:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es0p0c$8e9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11973

I, for one, definitely feel that go-back-N is much easier to implement 
than selective repeat. :)

-Yangfan

Seth Wright wrote:
> Can I ask why we want STCP to use go back n?  It seems easier to me to do 
> what TCP actually does (or at least what Kurose says TCP actually does), so 
> why the change?  My STCP implementation is done in a way where retransmits 
> of individual lost segments would be fairly easy and, while I can do the 
> extra work to downgrade my STCP, I'd like to at least know why I'm doing so 
> and why I'd be penalized if I did what TCP actually does.
> 
> I don't know if that came out right, tact can be a touchy thing over a 
> newsgroup.  :)
> 
> -Seth
> 
> 
>>>>>"If the timeout for a segment is reached, the segment is examined. If 
>>>>>it
>>>>>has been sent a total of 6 times (once from the original send plus 5
>>>>>retransmissions), then the network is assumed to have failed and the
>>>>>network terminated. Otherwise the segment is retransmitted and the
>>>>>timeout is reset again."
>>
>>Poorly worded. Send everything. 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 01:04:47 -0800
Lines: 51
Distribution: su
Message-ID: <es0s5p$biq$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU> <es0p0c$8e9$1@news.Stanford.EDU> <es0r7v$apk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172567034 11866 127.0.0.1 (27 Feb 2007 09:03:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11974

I guess it could, but it does not seem like one is particularly harder than 
the other.  It is just a question of consuming/processing one interval range 
in your retx queue or all of them (loop vs. one).  I guess that depends on 
your implementation.

Forgetting some things might make one seem easier than the other:  If the 
first interval gets acked, only part of it might get acked, so you need to 
be able to retransmit a partial segment.  Additionally, if one whole segment 
is acked, you still need the (separate timeout) on the next interval.  The 
timeout is only the same value if you happened to send them at the same time 
(and then they can be merged) or if they have already both been retxed once 
before.

Not sure if that came out right either.

Sincerely,
Randy Jennings

The squirrels are your friends!
"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:es0r7v$apk$1@news.Stanford.EDU...
> I, for one, definitely feel that go-back-N is much easier to implement 
> than selective repeat. :)
>
> -Yangfan
>
> Seth Wright wrote:
>> Can I ask why we want STCP to use go back n?  It seems easier to me to do 
>> what TCP actually does (or at least what Kurose says TCP actually does), 
>> so why the change?  My STCP implementation is done in a way where 
>> retransmits of individual lost segments would be fairly easy and, while I 
>> can do the extra work to downgrade my STCP, I'd like to at least know why 
>> I'm doing so and why I'd be penalized if I did what TCP actually does.
>>
>> I don't know if that came out right, tact can be a touchy thing over a 
>> newsgroup.  :)
>>
>> -Seth
>>
>>
>>>>>>"If the timeout for a segment is reached, the segment is examined. If 
>>>>>>it
>>>>>>has been sent a total of 6 times (once from the original send plus 5
>>>>>>retransmissions), then the network is assumed to have failed and the
>>>>>>network terminated. Otherwise the segment is retransmitted and the
>>>>>>timeout is reset again."
>>>
>>>Poorly worded. Send everything.
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 04:15:17 -0500
Lines: 72
Distribution: su
Message-ID: <es0srd$c2k$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU> <es0p0c$8e9$1@news.Stanford.EDU> <es0r7v$apk$1@news.Stanford.EDU> <es0s5p$biq$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172567726 12372 127.0.0.1 (27 Feb 2007 09:15:26 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11975

I'm guessing our approaches are somewhat similar. :)
One reason I actually think it would be harder for go back n is that I would 
expect for the retx logic to take the data and rebreak it up into new 
segments with size STCP_MSS otherwise it seems a bit wasteful, but then if 
you do that, you run into what you were talking about with what do we do 
with timeouts - what if two segments get combined into one, do we move the 
timeout and retransmission count to the first segment of the two that got 
combined and forget we ever had the second segment?  It all just seems a lot 
cleaner if you say, oh, this particular segment didn't get there, let me 
resend that one and I'll wait for a timeout to resend others as necessary. 
And in the case of a triple ACK go back n seems incredibly inefficient.  I 
dunno, maybe I'm way over analyzing this and should simply take the blue 
pill and just do as the assignment says.

Seth

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:es0s5p$biq$1@news.Stanford.EDU...
>I guess it could, but it does not seem like one is particularly harder than 
>the other.  It is just a question of consuming/processing one interval 
>range in your retx queue or all of them (loop vs. one).  I guess that 
>depends on your implementation.
>
> Forgetting some things might make one seem easier than the other:  If the 
> first interval gets acked, only part of it might get acked, so you need to 
> be able to retransmit a partial segment.  Additionally, if one whole 
> segment is acked, you still need the (separate timeout) on the next 
> interval.  The timeout is only the same value if you happened to send them 
> at the same time (and then they can be merged) or if they have already 
> both been retxed once before.
>
> Not sure if that came out right either.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:es0r7v$apk$1@news.Stanford.EDU...
>> I, for one, definitely feel that go-back-N is much easier to implement 
>> than selective repeat. :)
>>
>> -Yangfan
>>
>> Seth Wright wrote:
>>> Can I ask why we want STCP to use go back n?  It seems easier to me to 
>>> do what TCP actually does (or at least what Kurose says TCP actually 
>>> does), so why the change?  My STCP implementation is done in a way where 
>>> retransmits of individual lost segments would be fairly easy and, while 
>>> I can do the extra work to downgrade my STCP, I'd like to at least know 
>>> why I'm doing so and why I'd be penalized if I did what TCP actually 
>>> does.
>>>
>>> I don't know if that came out right, tact can be a touchy thing over a 
>>> newsgroup.  :)
>>>
>>> -Seth
>>>
>>>
>>>>>>>"If the timeout for a segment is reached, the segment is examined. If 
>>>>>>>it
>>>>>>>has been sent a total of 6 times (once from the original send plus 5
>>>>>>>retransmissions), then the network is assumed to have failed and the
>>>>>>>network terminated. Otherwise the segment is retransmitted and the
>>>>>>>timeout is reset again."
>>>>
>>>>Poorly worded. Send everything.
>>>
>>>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 01:46:31 -0800
Lines: 29
Distribution: su
Message-ID: <es0uk2$dcn$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU> <es0p0c$8e9$1@news.Stanford.EDU> <es0r7v$apk$1@news.Stanford.EDU> <es0s5p$biq$1@news.Stanford.EDU> <es0srd$c2k$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172569538 13719 127.0.0.1 (27 Feb 2007 09:45:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11977

> One reason I actually think it would be harder for go back n is that I 
> would expect for the retx logic to take the data and rebreak it up into 
> new segments with size STCP_MSS otherwise it seems a bit wasteful, but 
> then if you do that, you run into what you were talking about with what do 
> we do with timeouts - what if two segments get combined into one, do we 
> move the timeout and retransmission count to the first segment of the two 
> that got combined and forget we ever had the second segment?
Well, mine does re-cut them up into packets.  Not that I tried, it is just a 
consequence of my implementation.  It would be harder not to.

However, I just leave the extra entries in the queue.  There should not be 
many of them, so it would probably waste more cycles than I'd gain to 
combine them.

> It all just seems a lot cleaner if you say, oh, this particular segment 
> didn't get there, let me resend that one and I'll wait for a timeout to 
> resend others as necessary. And in the case of a triple ACK go back n 
> seems incredibly inefficient.
Yeah, but we are not doing triple ACK anyway.

BTW, I think it would be hard for the TAs to check if you were doing 
selective retransmit or go-back-N.  They _could_, but I think it'd be a bit 
of extra code.  Not that I am recommending finding out... :-).  You would 
probably have to find out the hard way.

Sincerely,
Randy Jennings 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Go-back-N?
Date: Tue, 27 Feb 2007 03:17:32 -0800
Lines: 87
Distribution: su
Message-ID: <es140a$h8i$1@news.Stanford.EDU>
References: <ertf3d$l5k$1@news.Stanford.EDU> <eru05v$4i9$1@news.Stanford.EDU> <eru125$582$1@news.Stanford.EDU> <eruha6$lih$1@news.Stanford.EDU> <es0p0c$8e9$1@news.Stanford.EDU> <es0r7v$apk$1@news.Stanford.EDU> <es0s5p$biq$1@news.Stanford.EDU> <es0srd$c2k$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172575050 17682 128.12.194.72 (27 Feb 2007 11:17:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es0srd$c2k$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11978

I guess it all depends on how you mentally approach the problem. I find 
the idea of keeping track of each packet that you've sent much harder to 
think about. Best to throw all the data into a buffer and worry about it 
later. :)

I haven't implemented retransmission count yet, but all you're trying to 
detect with the count is a dead link or host, and it shouldn't be that 
hard to detect. (Famous last words.)

-Yangfan

Seth Wright wrote:
> I'm guessing our approaches are somewhat similar. :)
> One reason I actually think it would be harder for go back n is that I would 
> expect for the retx logic to take the data and rebreak it up into new 
> segments with size STCP_MSS otherwise it seems a bit wasteful, but then if 
> you do that, you run into what you were talking about with what do we do 
> with timeouts - what if two segments get combined into one, do we move the 
> timeout and retransmission count to the first segment of the two that got 
> combined and forget we ever had the second segment?  It all just seems a lot 
> cleaner if you say, oh, this particular segment didn't get there, let me 
> resend that one and I'll wait for a timeout to resend others as necessary. 
> And in the case of a triple ACK go back n seems incredibly inefficient.  I 
> dunno, maybe I'm way over analyzing this and should simply take the blue 
> pill and just do as the assignment says.
> 
> Seth
> 
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:es0s5p$biq$1@news.Stanford.EDU...
> 
>>I guess it could, but it does not seem like one is particularly harder than 
>>the other.  It is just a question of consuming/processing one interval 
>>range in your retx queue or all of them (loop vs. one).  I guess that 
>>depends on your implementation.
>>
>>Forgetting some things might make one seem easier than the other:  If the 
>>first interval gets acked, only part of it might get acked, so you need to 
>>be able to retransmit a partial segment.  Additionally, if one whole 
>>segment is acked, you still need the (separate timeout) on the next 
>>interval.  The timeout is only the same value if you happened to send them 
>>at the same time (and then they can be merged) or if they have already 
>>both been retxed once before.
>>
>>Not sure if that came out right either.
>>
>>Sincerely,
>>Randy Jennings
>>
>>The squirrels are your friends!
>>"Yangfan Wang" <yfw@stanford.edu> wrote in message 
>>news:es0r7v$apk$1@news.Stanford.EDU...
>>
>>>I, for one, definitely feel that go-back-N is much easier to implement 
>>>than selective repeat. :)
>>>
>>>-Yangfan
>>>
>>>Seth Wright wrote:
>>>
>>>>Can I ask why we want STCP to use go back n?  It seems easier to me to 
>>>>do what TCP actually does (or at least what Kurose says TCP actually 
>>>>does), so why the change?  My STCP implementation is done in a way where 
>>>>retransmits of individual lost segments would be fairly easy and, while 
>>>>I can do the extra work to downgrade my STCP, I'd like to at least know 
>>>>why I'm doing so and why I'd be penalized if I did what TCP actually 
>>>>does.
>>>>
>>>>I don't know if that came out right, tact can be a touchy thing over a 
>>>>newsgroup.  :)
>>>>
>>>>-Seth
>>>>
>>>>
>>>>
>>>>>>>>"If the timeout for a segment is reached, the segment is examined. If 
>>>>>>>>it
>>>>>>>>has been sent a total of 6 times (once from the original send plus 5
>>>>>>>>retransmissions), then the network is assumed to have failed and the
>>>>>>>>network terminated. Otherwise the segment is retransmitted and the
>>>>>>>>timeout is reset again."
>>>>>
>>>>>Poorly worded. Send everything.
>>>>
>>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: robustness with respect to transport layer
Date: Tue, 27 Feb 2007 10:55:28 -0800
Lines: 9
Distribution: su
Message-ID: <es1ur1$eq7$1@news.Stanford.EDU>
References: <eru78l$csh$1@news.Stanford.EDU> <ervkei$sp7$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek-laptop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172602529 15175 128.12.104.76 (27 Feb 2007 18:55:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:11979

On 2007-02-26 13:45:41 -0800, Adam Cohen <adam.cohen@stanford.edu> said:

> I imagine that when you implement timeouts there will just eventually 
> be 6 successive packets that are not ACKED, and your client should 
> terminate the connection by normal means.

One would hope. But it looks like termination of the underlying 
connection causes the fake network layer to die hard.

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: TCP state diagram
Date: Tue, 27 Feb 2007 12:30:12 -0700
Lines: 10
Distribution: su
Message-ID: <es20s5$hvq$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172604613 18426 127.0.0.1 (27 Feb 2007 19:30:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11980

A question regarding the downward transition from SYN_RCVD to FIN_WAIT_1 on 
page 23 of the RFC:  If the stcp implementation is supposed to block the 
client until the connection is established, how can this arrow ever come 
into play?  The client won't be unblocked until stcp sees an ACK of SYN, so 
the client won't be able to issue a close request until stcp gets into the 
ESTABLISHED state.  Am I missing something?

--Kevin 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: timeout in passive sent syn ack
Date: Tue, 27 Feb 2007 12:25:57 -0800
Lines: 16
Distribution: su
Message-ID: <es2430$llv$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172607904 22207 127.0.0.1 (27 Feb 2007 20:25:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11981

In passive mode, after we ACK a SYN, if we timeout waiting for the ACK back, 
should we exit, sending a timeout up to the user, or should we wait for 
another connection?

It seems like a timeout event would be required to be sent up to the user, 
but it seems that that would not be very useful for a user waiting for a 
valid connection.

I imagine rfc793 says something about it, but I cannot find it right now.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Slides from the 2/23 review session
Date: Tue, 27 Feb 2007 14:25:49 -0700
Lines: 4
Distribution: su
Message-ID: <es27ku$q4h$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172611550 26769 127.0.0.1 (27 Feb 2007 21:25:50 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11982

Are Justin's slides posted anywhere?  I don't see them linked on the course 
schedule page. 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Slides from the 2/23 review session
Date: Tue, 27 Feb 2007 13:41:20 -0800
Lines: 14
Distribution: su
Message-ID: <C209E580.8CA2%jpettit@stanford.edu>
References: <es27ku$q4h$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172612488 27784 127.0.0.1 (27 Feb 2007 21:41:28 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Slides from the 2/23 review session
Thread-Index: AcdauASKQwB4QMarEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:11983

> Are Justin's slides posted anywhere?  I don't see them linked on the course
> schedule page. 

Sorry, I just noticed this, too!  It's now posted:
    
 http://www.stanford.edu/class/cs244a/handouts/Review-Congestion-2007.pdf

and the PowerPoint presentation is here:

 http://www.stanford.edu/class/cs244a/handouts/Review-Congestion-2007.ppt

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: send ack
Date: Wed, 28 Feb 2007 05:15:53 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98E4D851B336chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172639753 25795 128.12.22.217 (28 Feb 2007 05:15:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11984

suppose the initial seq num was 100,

i've received 100 to 120, already, but somehow the ack for 120 was dropped.

so the sender sends 100 to 110 again. What should i do withi this packet? 
drop it and send ack of 120? or just drop it? since it's out of the 
receiving window range.

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: sliding window
Date: Wed, 28 Feb 2007 06:41:38 +0000 (UTC)
Organization: Your Company
Lines: 2
Distribution: su
Message-ID: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1172644898 29122 128.12.22.217 (28 Feb 2007 06:41:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:11985

im really confused with the sliding window thing... for part B... what 
should i send as the value for window size? always 3072? or 3072-???
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout in passive sent syn ack
Date: Wed, 28 Feb 2007 00:27:56 -0800
Lines: 31
Distribution: su
Message-ID: <es3eej$74a$1@news.Stanford.EDU>
References: <es2430$llv$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172651283 7306 128.12.197.229 (28 Feb 2007 08:28:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11986

I was confused about this earlier too but I think this is what makes most 
sense:

If the server sends an SYN_ACK and you don't get an ACK back from the 
client, then wait RTO and then send another SYN_ACK.  Do this 6 times before 
giving up.

TAs pls correct me if this is not the right approach.

Tom


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:es2430$llv$1@news.Stanford.EDU...
> In passive mode, after we ACK a SYN, if we timeout waiting for the ACK 
> back, should we exit, sending a timeout up to the user, or should we wait 
> for another connection?
>
> It seems like a timeout event would be required to be sent up to the user, 
> but it seems that that would not be very useful for a user waiting for a 
> valid connection.
>
> I imagine rfc793 says something about it, but I cannot find it right now.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: packet length
Date: Wed, 28 Feb 2007 00:35:47 -0800
Lines: 14
Distribution: su
Message-ID: <es3eta$7em$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172651754 7638 128.12.197.229 (28 Feb 2007 08:35:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11987

If I send a packet with 20 bytes of data across the network and I receive 
the packet at the other end, can we assume that the packet will also have 20 
bytes of uncorrupted data at the other end?... this would make me very 
happy.

I found something related in the FAQ but it talks about the packet length in 
the tcp header.... however,  I don't see any length field in the tcp header 
(i might be blind). I think the only way we are calculating length right now 
is by looking at the number of bytes we get from network_recv... so i guess 
my question is if that length will always be the one intended.

Tom


.

Path: shelby.stanford.edu!not-for-mail
From: Ben Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ps3 problem 5
Date: Wed, 28 Feb 2007 00:38:54 -0800
Lines: 12
Distribution: su
Message-ID: <es3f3t$7hh$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172651965 7729 128.12.94.22 (28 Feb 2007 08:39:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
Xref: shelby.stanford.edu su.class.cs244a:11988

In the lecture, PROP is defined as the token rotation time, e.g. the 
propagation delay between one host and itself in the cycle.

In the homework, PROP is defined as the delay between one host and the 
Nth host in the network. This means that the token rotation time is 
actually PROP/(N-1) * N, because there are N-1 edges separating the 
first host from the last host, but there are N edges in the cycle.

This makes the math unnecessarily messy. Can we just assume the 
definition from lecture, or have I gotten something wrong here?

Ben
.

Path: shelby.stanford.edu!not-for-mail
From: Ben Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ps3 problem 5
Date: Wed, 28 Feb 2007 01:15:22 -0800
Lines: 17
Distribution: su
Message-ID: <es3h89$8pr$1@news.Stanford.EDU>
References: <es3f3t$7hh$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172654153 9019 128.12.94.22 (28 Feb 2007 09:15:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
In-Reply-To: <es3f3t$7hh$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11989

Ah darn. I should read the problem more carefully.

Ben

Ben Nham wrote:
> In the lecture, PROP is defined as the token rotation time, e.g. the 
> propagation delay between one host and itself in the cycle.
> 
> In the homework, PROP is defined as the delay between one host and the 
> Nth host in the network. This means that the token rotation time is 
> actually PROP/(N-1) * N, because there are N-1 edges separating the 
> first host from the last host, but there are N edges in the cycle.
> 
> This makes the math unnecessarily messy. Can we just assume the 
> definition from lecture, or have I gotten something wrong here?
> 
> Ben
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet length
Date: Wed, 28 Feb 2007 01:24:52 -0800
Lines: 22
Distribution: su
Message-ID: <es3hov$94n$1@news.Stanford.EDU>
References: <es3eta$7em$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172654687 9367 128.12.194.72 (28 Feb 2007 09:24:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es3eta$7em$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11990

Tom Deane wrote:
> If I send a packet with 20 bytes of data across the network and I receive 
> the packet at the other end, can we assume that the packet will also have 20 
> bytes of uncorrupted data at the other end?... this would make me very 
> happy.
> 
> I found something related in the FAQ but it talks about the packet length in 
> the tcp header.... however,  I don't see any length field in the tcp header 
> (i might be blind). I think the only way we are calculating length right now 
> is by looking at the number of bytes we get from network_recv... so i guess 
> my question is if that length will always be the one intended.
> 
> Tom
> 
> 

I don't see how this will always be true in unreliable mode, since the 
link will be dropping and duplicating packets. So you may send a packet 
onto the network and get a duplicate copy of an earlier packet on the 
other host.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet length
Date: Wed, 28 Feb 2007 02:04:29 -0800
Lines: 34
Distribution: su
Message-ID: <es3k3d$bba$1@news.Stanford.EDU>
References: <es3eta$7em$1@news.Stanford.EDU> <es3hov$94n$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172657069 11626 128.12.197.130 (28 Feb 2007 10:04:29 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11991

Yangfan, thanks for the reply but that's not what I asked.  I'm aware there 
will be dropped and duplicate packets in unreliable mode.

Thanks,
Tom


"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:es3hov$94n$1@news.Stanford.EDU...
> Tom Deane wrote:
>> If I send a packet with 20 bytes of data across the network and I receive 
>> the packet at the other end, can we assume that the packet will also have 
>> 20 bytes of uncorrupted data at the other end?... this would make me very 
>> happy.
>>
>> I found something related in the FAQ but it talks about the packet length 
>> in the tcp header.... however,  I don't see any length field in the tcp 
>> header (i might be blind). I think the only way we are calculating length 
>> right now is by looking at the number of bytes we get from 
>> network_recv... so i guess my question is if that length will always be 
>> the one intended.
>>
>> Tom
>>
>>
>
> I don't see how this will always be true in unreliable mode, since the 
> link will be dropping and duplicating packets. So you may send a packet 
> onto the network and get a duplicate copy of an earlier packet on the 
> other host.
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet length
Date: Wed, 28 Feb 2007 02:38:26 -0800
Lines: 48
Distribution: su
Message-ID: <es3m2t$cbj$1@news.Stanford.EDU>
References: <es3eta$7em$1@news.Stanford.EDU> <es3hov$94n$1@news.Stanford.EDU> <es3k3d$bba$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172659101 12659 128.12.194.72 (28 Feb 2007 10:38:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es3k3d$bba$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11992

Tom Deane wrote:
> Yangfan, thanks for the reply but that's not what I asked.  I'm aware there 
> will be dropped and duplicate packets in unreliable mode.
> 
> Thanks,
> Tom
> 
> 
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:es3hov$94n$1@news.Stanford.EDU...
> 
>>Tom Deane wrote:
>>
>>>If I send a packet with 20 bytes of data across the network and I receive 
>>>the packet at the other end, can we assume that the packet will also have 
>>>20 bytes of uncorrupted data at the other end?... this would make me very 
>>>happy.
>>>
>>>I found something related in the FAQ but it talks about the packet length 
>>>in the tcp header.... however,  I don't see any length field in the tcp 
>>>header (i might be blind). I think the only way we are calculating length 
>>>right now is by looking at the number of bytes we get from 
>>>network_recv... so i guess my question is if that length will always be 
>>>the one intended.
>>>
>>>Tom
>>>
>>>
>>
>>I don't see how this will always be true in unreliable mode, since the 
>>link will be dropping and duplicating packets. So you may send a packet 
>>onto the network and get a duplicate copy of an earlier packet on the 
>>other host.
>>
>>-Yangfan 
> 
> 
> 
I misunderstood your question. My bad. :)

I was saying that you can't be sure whether it was the same packet 
coming out of the link, so you can't assume "20 bytes in, 20 bytes out".

You were asking if the the packet has the same sequence number, so 
you're reasonably sure that it was the right packet, would it carry the 
same amount of data. Right?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: connection teardown
Date: Wed, 28 Feb 2007 02:43:53 -0800
Lines: 8
Distribution: su
Message-ID: <es3md5$clh$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172659429 12977 128.12.194.72 (28 Feb 2007 10:43:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:11993

In TCP, the client always sends the FIN segment first. In STCP, either 
side may decide to initiate the teardown, correct?

In fact, the server seems to always initiate the teardown first. So we 
can't really use the TCP state transition diagram on page 253 of Kurose 
for our teardown protocol, correct?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: TCP state diagram
Date: Wed, 28 Feb 2007 02:45:40 -0800
Lines: 21
Distribution: su
Message-ID: <es3n2i$d6g$1@news.Stanford.EDU>
References: <es20s5$hvq$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172660117 13520 171.64.74.54 (28 Feb 2007 10:55:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <es20s5$hvq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11994

Not all implementations of TCP (notice the lack of an 'S') behave the 
same way.  One additional possible transition that isn't explicit in 
that diagram is that you could possible receive a FIN or RST after you 
send back your SYN- in other words, the active side of the connection 
sends you a SYN, you respond with SYN ACK, and the active side then 
gives you a FIN or RST.  This is sometimes used as a 'stealth scanning' 
technique by programmers; because the three-way handshake is not 
completed, the connection may not show up in connection logs.

Clay
Kevin Hart wrote:
> A question regarding the downward transition from SYN_RCVD to FIN_WAIT_1 on 
> page 23 of the RFC:  If the stcp implementation is supposed to block the 
> client until the connection is established, how can this arrow ever come 
> into play?  The client won't be unblocked until stcp sees an ACK of SYN, so 
> the client won't be able to issue a close request until stcp gets into the 
> ESTABLISHED state.  Am I missing something?
> 
> --Kevin 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: send ack
Date: Wed, 28 Feb 2007 03:11:09 -0800
Lines: 13
Distribution: su
Message-ID: <es3oib$ef7$1@news.Stanford.EDU>
References: <Xns98E4D851B336chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172661644 14823 171.64.74.54 (28 Feb 2007 11:20:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98E4D851B336chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11995

You have to send an ACK in this case.  Check page 69 of the RFC.

Clay

Chun Kai Wang wrote:
> suppose the initial seq num was 100,
> 
> i've received 100 to 120, already, but somehow the ack for 120 was dropped.
> 
> so the sender sends 100 to 110 again. What should i do withi this packet? 
> drop it and send ack of 120? or just drop it? since it's out of the 
> receiving window range.
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout in passive sent syn ack
Date: Wed, 28 Feb 2007 03:36:38 -0800
Lines: 50
Distribution: su
Message-ID: <es3q29$flt$1@news.Stanford.EDU>
References: <es2430$llv$1@news.Stanford.EDU> <es3eej$74a$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172663178 16061 171.64.74.54 (28 Feb 2007 11:46:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <es3eej$74a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11996

Just to clarify, you should be trying a total of six times: once for the 
initial send of the SYN-ACK, and then 5 retries (this is a general rule- 
take a look at 'Retransmission' in the assignment).  Since you never 
reach the 'Established' state, from the perspective of a listening 
application, nothing worth paying attention to has really happened. 
There is no action that the application can take, so there is typically 
no notification to the layers above.

Of course, that's why creating a half-open TCP connection and then not 
sending the final ACK is a useful stealth scan technique; there are even 
some programs that can attempt to guess what operating system is running 
on the machine by figuring out how the retransmission timeout is set. 
SYN flooding is another abuse of this aspect of TCP, where a denial of 
service attack can be staged against a listening host by repeatedly 
creating half-open connections and then letting them sit.

Clay

Tom Deane wrote:
> I was confused about this earlier too but I think this is what makes most 
> sense:
> 
> If the server sends an SYN_ACK and you don't get an ACK back from the 
> client, then wait RTO and then send another SYN_ACK.  Do this 6 times before 
> giving up.
> 
> TAs pls correct me if this is not the right approach.
> 
> Tom
> 
> 
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:es2430$llv$1@news.Stanford.EDU...
>> In passive mode, after we ACK a SYN, if we timeout waiting for the ACK 
>> back, should we exit, sending a timeout up to the user, or should we wait 
>> for another connection?
>>
>> It seems like a timeout event would be required to be sent up to the user, 
>> but it seems that that would not be very useful for a user waiting for a 
>> valid connection.
>>
>> I imagine rfc793 says something about it, but I cannot find it right now.
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 03:41:23 -0800
Lines: 11
Distribution: su
Message-ID: <es3qb1$flt$2@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172663459 16061 171.64.74.54 (28 Feb 2007 11:50:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:11997

The receiver window on your end is always 3072.  If you are sending, the 
sender window is the smaller of a) 3072, and b) the window size 
advertised by the receiver.  So if two STCP implementations are talking 
to each other, the window size is always 3072.  If your STCP is sending 
data to a non-STCP host, the window size may be smaller.

Clay

Chun Kai Wang wrote:
> im really confused with the sliding window thing... for part B... what 
> should i send as the value for window size? always 3072? or 3072-???
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: connection teardown
Date: Wed, 28 Feb 2007 03:47:24 -0800
Lines: 17
Distribution: su
Message-ID: <es3qma$g0a$1@news.Stanford.EDU>
References: <es3md5$clh$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172663820 16394 171.64.74.54 (28 Feb 2007 11:57:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <es3md5$clh$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:11998

Yangfan Wang wrote:
> In TCP, the client always sends the FIN segment first. In STCP, either 
> side may decide to initiate the teardown, correct?
Nope- in TCP, either side may initiate the connection teardown by 
sending the first FIN.  Whoever sends the first FIN is said to be 
performing the 'active close', but this isn't unnecessarily the same 
party that was the 'active' side in connection establishment.  HTTP/1.0 
web servers, for instance, often close the connection to the client as 
soon as they are done sending data.

Clay
> 
> In fact, the server seems to always initiate the teardown first. So we 
> can't really use the TCP state transition diagram on page 253 of Kurose 
> for our teardown protocol, correct?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet length
Date: Wed, 28 Feb 2007 12:47:21 -0800
Lines: 54
Distribution: su
Message-ID: <es4pp1$j3b$1@news.Stanford.EDU>
References: <es3eta$7em$1@news.Stanford.EDU> <es3hov$94n$1@news.Stanford.EDU> <es3k3d$bba$1@news.Stanford.EDU> <es3m2t$cbj$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172695649 19563 128.12.197.229 (28 Feb 2007 20:47:29 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:11999

Right

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:es3m2t$cbj$1@news.Stanford.EDU...
> Tom Deane wrote:
>> Yangfan, thanks for the reply but that's not what I asked.  I'm aware 
>> there will be dropped and duplicate packets in unreliable mode.
>>
>> Thanks,
>> Tom
>>
>>
>> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
>> news:es3hov$94n$1@news.Stanford.EDU...
>>
>>>Tom Deane wrote:
>>>
>>>>If I send a packet with 20 bytes of data across the network and I 
>>>>receive the packet at the other end, can we assume that the packet will 
>>>>also have 20 bytes of uncorrupted data at the other end?... this would 
>>>>make me very happy.
>>>>
>>>>I found something related in the FAQ but it talks about the packet 
>>>>length in the tcp header.... however,  I don't see any length field in 
>>>>the tcp header (i might be blind). I think the only way we are 
>>>>calculating length right now is by looking at the number of bytes we get 
>>>>from network_recv... so i guess my question is if that length will 
>>>>always be the one intended.
>>>>
>>>>Tom
>>>>
>>>>
>>>
>>>I don't see how this will always be true in unreliable mode, since the 
>>>link will be dropping and duplicating packets. So you may send a packet 
>>>onto the network and get a duplicate copy of an earlier packet on the 
>>>other host.
>>>
>>>-Yangfan
>>
>>
>>
> I misunderstood your question. My bad. :)
>
> I was saying that you can't be sure whether it was the same packet coming 
> out of the link, so you can't assume "20 bytes in, 20 bytes out".
>
> You were asking if the the packet has the same sequence number, so you're 
> reasonably sure that it was the right packet, would it carry the same 
> amount of data. Right?
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: clock_gettime + gettimeofday()
Date: Wed, 28 Feb 2007 15:08:08 -0800
Lines: 14
Distribution: su
Message-ID: <es520q$rkq$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172704090 28314 171.67.77.244 (28 Feb 2007 23:08:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12001

The FAQ, says that we can't use -lrt (real time library), which defines 
clock_gettime()

And we are supposed to use gettimeofday().

But, the man pages of gettimeofday() uses the struct timeval type. And the 
stcp_wait_for_event() requires a struct timespec type?

Why aren't we allowed to use -lrt.

And how should I use gettimeofday() to get a struct timespec struct? Should 
I just cast timeval to timespec....? 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime + gettimeofday()
Date: Wed, 28 Feb 2007 15:18:38 -0800
Lines: 21
Distribution: su
Message-ID: <es52kd$s1q$1@news.Stanford.EDU>
References: <es520q$rkq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172704717 28730 127.0.0.1 (28 Feb 2007 23:18:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es520q$rkq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12002

manj wrote:
> The FAQ, says that we can't use -lrt (real time library), which defines 
> clock_gettime()
> 
> And we are supposed to use gettimeofday().
> 
> But, the man pages of gettimeofday() uses the struct timeval type. And the 
> stcp_wait_for_event() requires a struct timespec type?
> 
> Why aren't we allowed to use -lrt.
> 
> And how should I use gettimeofday() to get a struct timespec struct? Should 
> I just cast timeval to timespec....? 
> 
> 

You don't necessarily need something to return the timespec struct, you 
can just populate its members, take a look at what is in the timespec 
struct, and take a look at what time() returns, then go from there.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 15:24:44 -0800
Lines: 26
Distribution: su
Message-ID: <es52vv$sia$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172705087 29258 171.67.77.244 (28 Feb 2007 23:24:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12003

If I have 3072 outstanding bytes of data (which haven't been acked).

Now I get an ACK, which just moves my window by 1 (i.e just acknowldeges the 
oldest bytes).

But the advertised window now becomes say 1000. What should I do with the 
3072 - 1 - 1000 bytes of data?

Can I discard them? I think NO, but the result is that I have to keep many 
buffers lying around since I have to retransmit this sometime later on...

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:es3qb1$flt$2@news.Stanford.EDU...
> The receiver window on your end is always 3072.  If you are sending, the 
> sender window is the smaller of a) 3072, and b) the window size advertised 
> by the receiver.  So if two STCP implementations are talking to each 
> other, the window size is always 3072.  If your STCP is sending data to a 
> non-STCP host, the window size may be smaller.
>
> Clay
>
> Chun Kai Wang wrote:
>> im really confused with the sliding window thing... for part B... what 
>> should i send as the value for window size? always 3072? or 3072-??? 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime + gettimeofday()
Date: Wed, 28 Feb 2007 15:30:44 -0800
Lines: 45
Distribution: su
Message-ID: <es53b7$suj$1@news.Stanford.EDU>
References: <es520q$rkq$1@news.Stanford.EDU> <es52kd$s1q$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172705447 29651 171.67.77.244 (28 Feb 2007 23:30:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12004

      struct timespec {
               time_t   tv_sec;        /* seconds */
               long     tv_nsec;       /* nanoseconds */
       };

while gettimeofday() returns:
       struct timeval {
               time_t         tv_sec;        /* seconds */
               suseconds_t    tv_usec;  /* microseconds */
       };

In both the time is the time spent since Epoch.

But, obviously they operate at different granularities. So, how can we use 
them in a compatible way.

I looked at time() and it returs _seconds_ since Epoch.

So, does this mean we should calculate RTO only in granularities of seconds?

Manju.

"David Erickson" <derickso@stanford.edu> wrote in message 
news:es52kd$s1q$1@news.Stanford.EDU...
> manj wrote:
>> The FAQ, says that we can't use -lrt (real time library), which defines 
>> clock_gettime()
>>
>> And we are supposed to use gettimeofday().
>>
>> But, the man pages of gettimeofday() uses the struct timeval type. And 
>> the stcp_wait_for_event() requires a struct timespec type?
>>
>> Why aren't we allowed to use -lrt.
>>
>> And how should I use gettimeofday() to get a struct timespec struct? 
>> Should I just cast timeval to timespec....?
>
> You don't necessarily need something to return the timespec struct, you 
> can just populate its members, take a look at what is in the timespec 
> struct, and take a look at what time() returns, then go from there.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: intial RTO value
Date: Wed, 28 Feb 2007 15:33:19 -0800
Lines: 4
Distribution: su
Message-ID: <es53g1$t1a$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172705602 29738 171.67.77.244 (28 Feb 2007 23:33:22 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12005

What would be reasonable value of the initial RTO value for the first SYN 
packet (from client) and SYN + ACK packe (from server)? 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime + gettimeofday()
Date: Wed, 28 Feb 2007 15:38:56 -0800
Lines: 22
Distribution: su
Message-ID: <es53qf$1t$1@news.Stanford.EDU>
References: <es520q$rkq$1@news.Stanford.EDU> <es52kd$s1q$1@news.Stanford.EDU> <es53b7$suj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172705936 61 127.0.0.1 (28 Feb 2007 23:38:56 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es53b7$suj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12006

manj wrote:
>       struct timespec {
>                time_t   tv_sec;        /* seconds */
>                long     tv_nsec;       /* nanoseconds */
>        };
> 
> while gettimeofday() returns:
>        struct timeval {
>                time_t         tv_sec;        /* seconds */
>                suseconds_t    tv_usec;  /* microseconds */
>        };
> 
> In both the time is the time spent since Epoch.
> 
> But, obviously they operate at different granularities. So, how can we use 
> them in a compatible way.
> 

It shouldn't be a problem converting from microseconds to nanoseconds 
for passing to the method, right?

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 15:40:52 -0800
Lines: 17
Distribution: su
Message-ID: <es53u3$1t$2@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172706051 61 127.0.0.1 (28 Feb 2007 23:40:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es52vv$sia$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12007

manj wrote:
> If I have 3072 outstanding bytes of data (which haven't been acked).
> 
> Now I get an ACK, which just moves my window by 1 (i.e just acknowldeges the 
> oldest bytes).
> 
> But the advertised window now becomes say 1000. What should I do with the 
> 3072 - 1 - 1000 bytes of data?
> 
> Can I discard them? I think NO, but the result is that I have to keep many 
> buffers lying around since I have to retransmit this sometime later on...

If I understand your question right, there is no reason to maintain data 
that has been acked, once your window moves past the ack'd data you just 
toss it.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: intial RTO value
Date: Wed, 28 Feb 2007 15:41:56 -0800
Lines: 11
Distribution: su
Message-ID: <es5403$1t$3@news.Stanford.EDU>
References: <es53g1$t1a$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172706115 61 127.0.0.1 (28 Feb 2007 23:41:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es53g1$t1a$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12008

manj wrote:
> What would be reasonable value of the initial RTO value for the first SYN 
> packet (from client) and SYN + ACK packe (from server)? 
> 
> 

Good question, try sending a packet from telnet or something to a 
firewalled host that blocks the SYN and see how long it takes to time 
out in practice.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: intial RTO value
Date: Wed, 28 Feb 2007 15:51:27 -0800
Lines: 24
Distribution: su
Message-ID: <es54i2$s8$1@news.Stanford.EDU>
References: <es53g1$t1a$1@news.Stanford.EDU> <es5403$1t$3@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172706690 904 171.67.77.244 (28 Feb 2007 23:51:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12009

Thanks.

This is what I tried:

http://192.168.18.100/,  from windows xp2 and looked at ethereal traces.

It retransmitted SYN packet twice (1 + 2) before giving up and the 1st 
packet was separated from 2nd packet by an RTO of around 1 second and the 
2nd packet was separted from the 3rd by 2 seconds.

Manju.
"David Erickson" <derickso@stanford.edu> wrote in message 
news:es5403$1t$3@news.Stanford.EDU...
> manj wrote:
>> What would be reasonable value of the initial RTO value for the first SYN 
>> packet (from client) and SYN + ACK packe (from server)?
>
> Good question, try sending a packet from telnet or something to a 
> firewalled host that blocks the SYN and see how long it takes to time out 
> in practice.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: intial RTO value
Date: Wed, 28 Feb 2007 15:57:15 -0800
Lines: 50
Distribution: su
Message-ID: <es54su$12v$1@news.Stanford.EDU>
References: <es53g1$t1a$1@news.Stanford.EDU> <es5403$1t$3@news.Stanford.EDU> <es54i2$s8$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172707038 1119 171.67.77.244 (28 Feb 2007 23:57:18 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12011

FYI:

I looked at rfc 1122. And it states the following:

            The following values SHOULD be used to initialize the
            estimation parameters for a new connection:

            (a)  RTT = 0 seconds.

            (b)  RTO = 3 seconds.  (The smoothed variance is to be
                 initialized to the value that will result in this RTO).

            The recommended upper and lower bounds on the RTO are known
            to be inadequate on large internets.  The lower bound SHOULD
            be measured in fractions of a second (to accommodate high
            speed LANs) and the upper bound should be 2*MSL, i.e., 240
            seconds.

            DISCUSSION:
                 Experience has shown that these initialization values
                 are reasonable, and that in any case the Karn and
                 Jacobson algorithms make TCP behavior reasonably
                 insensitive to the initial parameter choices."manj" 
<manj@stanford.edu> wrote in message news:es54i2$s8$1@news.Stanford.EDU...
> Thanks.
>
> This is what I tried:
>
> http://192.168.18.100/,  from windows xp2 and looked at ethereal traces.
>
> It retransmitted SYN packet twice (1 + 2) before giving up and the 1st 
> packet was separated from 2nd packet by an RTO of around 1 second and the 
> 2nd packet was separted from the 3rd by 2 seconds.
>
> Manju.
> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:es5403$1t$3@news.Stanford.EDU...
>> manj wrote:
>>> What would be reasonable value of the initial RTO value for the first 
>>> SYN packet (from client) and SYN + ACK packe (from server)?
>>
>> Good question, try sending a packet from telnet or something to a 
>> firewalled host that blocks the SYN and see how long it takes to time out 
>> in practice.
>>
>> -David
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 16:01:50 -0800
Lines: 37
Distribution: su
Message-ID: <es555h$1f2$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU>
NNTP-Posting-Host: dnab434df4.stanford.edu
X-Trace: news.Stanford.EDU 1172707313 1506 171.67.77.244 (1 Mar 2007 00:01:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12012

maybe I did do explain the question properly.

If I have outstanding bytes (unacked data) and now I receive an ACK, which 
just acknowledges a small amount of
data and also *shrinks* the window (= the value from the window field in the 
tcp packet). Some portion of the data
still remains uack'ed.

The window is now shrinked by an amount that is not enough to accommodate 
all the sender's oustanding data ....But, the fact that we have accepted
this data already from the application, we cannot discard this data, and 
have to keep it around until the window increases in size again.

Is this understanding correct?

"David Erickson" <derickso@stanford.edu> wrote in message 
news:es53u3$1t$2@news.Stanford.EDU...
> manj wrote:
>> If I have 3072 outstanding bytes of data (which haven't been acked).
>>
>> Now I get an ACK, which just moves my window by 1 (i.e just acknowldeges 
>> the oldest bytes).
>>
>> But the advertised window now becomes say 1000. What should I do with the 
>> 3072 - 1 - 1000 bytes of data?
>>
>> Can I discard them? I think NO, but the result is that I have to keep 
>> many buffers lying around since I have to retransmit this sometime later 
>> on...
>
> If I understand your question right, there is no reason to maintain data 
> that has been acked, once your window moves past the ack'd data you just 
> toss it.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 16:04:47 -0800
Lines: 29
Distribution: su
Message-ID: <es5599$1jl$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172707433 1653 127.0.0.1 (1 Mar 2007 00:03:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12013

> If I have 3072 outstanding bytes of data (which haven't been acked).
>
> Now I get an ACK, which just moves my window by 1 (i.e just acknowldeges 
> the oldest bytes).
>
> But the advertised window now becomes say 1000. What should I do with the 
> 3072 - 1 - 1000 bytes of data?
>
> Can I discard them? I think NO, but the result is that I have to keep many 
> buffers lying around since I have to retransmit this sometime later on...
It sounds like you are asking from the transmitter side of things.

The data hasn't been acked, and your app thinks you have it, so I think you 
are right.  You have to keep it around and retransmit the data when the 
window opens up.  Personally, I would probably still run the timeout code on 
that data for simplicity's sake, but it seems like it would be more correct 
to reset the timer for that data (& the number of times it was txed) after 
the window opens up again.

I am not sure what you mean by keeping many buffers around.  I would think 
you would have exactly the same buffers you had before the advertised window 
became 1000.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: repost: packet length
Date: Wed, 28 Feb 2007 16:05:41 -0800
Lines: 14
Distribution: su
Message-ID: <es55ct$1o5$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172707549 1797 128.12.197.229 (1 Mar 2007 00:05:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12014

If I send a packet with 20 bytes of data across the network and I receive
the packet at the other end, can we assume that the packet will also have 20
bytes of uncorrupted data at the other end?... this would make me very
happy.

I found something related in the FAQ but it talks about the packet length in
the tcp header.... however,  I don't see any length field in the tcp header
(i might be blind). I think the only way we are calculating length right now
is by looking at the number of bytes we get from network_recv... so i guess
my question is if that length will always be the one intended.

Tom 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet length
Date: Wed, 28 Feb 2007 16:10:20 -0800
Lines: 16
Distribution: su
Message-ID: <es55jm$215$1@news.Stanford.EDU>
References: <es3eta$7em$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172707767 2085 127.0.0.1 (1 Mar 2007 00:09:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12015

> If I send a packet with 20 bytes of data across the network and I receive 
> the packet at the other end, can we assume that the packet will also have 
> 20 bytes of uncorrupted data at the other end?... this would make me very 
> happy.
This is my understanding, too.  However, the assignment warns that a 
malicious other end might put dangerous values in some of the header fields, 
so we are still advised to do sanity checking on them (one thing 
particularly mentioned is if the other end stayed within the advertised 
window of data).  Obviously, you can only check so much!

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 18:08:48 -0800
Lines: 53
Distribution: su
Message-ID: <es5cj9$88v$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172714921 8479 128.12.194.72 (1 Mar 2007 02:08:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es555h$1f2$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12017

I don't see why the receiver would ever want to shrink the sender's 
window once the size has been set. The receiver advertises a size based 
on its own data processing speed, which should really remain constant 
for the duration of the connection.

You probably just want to determine the sender's window size during 
handshaking and have it be fixed for the rest of the connection.

Disclaimer: I'm not a TA.

-Yangfan

manj wrote:
> maybe I did do explain the question properly.
> 
> If I have outstanding bytes (unacked data) and now I receive an ACK, which 
> just acknowledges a small amount of
> data and also *shrinks* the window (= the value from the window field in the 
> tcp packet). Some portion of the data
> still remains uack'ed.
> 
> The window is now shrinked by an amount that is not enough to accommodate 
> all the sender's oustanding data ....But, the fact that we have accepted
> this data already from the application, we cannot discard this data, and 
> have to keep it around until the window increases in size again.
> 
> Is this understanding correct?
> 
> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:es53u3$1t$2@news.Stanford.EDU...
> 
>>manj wrote:
>>
>>>If I have 3072 outstanding bytes of data (which haven't been acked).
>>>
>>>Now I get an ACK, which just moves my window by 1 (i.e just acknowldeges 
>>>the oldest bytes).
>>>
>>>But the advertised window now becomes say 1000. What should I do with the 
>>>3072 - 1 - 1000 bytes of data?
>>>
>>>Can I discard them? I think NO, but the result is that I have to keep 
>>>many buffers lying around since I have to retransmit this sometime later 
>>>on...
>>
>>If I understand your question right, there is no reason to maintain data 
>>that has been acked, once your window moves past the ack'd data you just 
>>toss it.
>>
>>-David 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: clock_gettime + gettimeofday()
Date: Wed, 28 Feb 2007 18:11:00 -0800
Lines: 28
Distribution: su
Message-ID: <es5cnd$88v$2@news.Stanford.EDU>
References: <es520q$rkq$1@news.Stanford.EDU> <es52kd$s1q$1@news.Stanford.EDU> <es53b7$suj$1@news.Stanford.EDU> <es53qf$1t$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172715053 8479 128.12.194.72 (1 Mar 2007 02:10:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es53qf$1t$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12018

David Erickson wrote:
> manj wrote:
> 
>>       struct timespec {
>>                time_t   tv_sec;        /* seconds */
>>                long     tv_nsec;       /* nanoseconds */
>>        };
>>
>> while gettimeofday() returns:
>>        struct timeval {
>>                time_t         tv_sec;        /* seconds */
>>                suseconds_t    tv_usec;  /* microseconds */
>>        };
>>
>> In both the time is the time spent since Epoch.
>>
>> But, obviously they operate at different granularities. So, how can we 
>> use them in a compatible way.
>>
> 
> It shouldn't be a problem converting from microseconds to nanoseconds 
> for passing to the method, right?
> 
> -David

Yeah. You'll lose some precision with gettimeofday(). Not a big deal.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: FIN and oustanding bytes
Date: Wed, 28 Feb 2007 18:11:35 -0800
Lines: 18
Distribution: su
Message-ID: <es5coq$8i4$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab422649.stanford.edu
X-Trace: news.Stanford.EDU 1172715098 8772 171.66.38.73 (1 Mar 2007 02:11:38 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12019

1)
If I get an APP_CLOSE_REQUESTED, when there are still outstanding bytes in 
the sender window,
what is the semanitcs to handle this case?
  - should I discard these bytes and send out a FIN.
  - or, should I wait until the other side accepts and ack's all the data 
before sending out a FIN.

2)
If I get a FIN, when there are still outstanding bytes in my send window, 
which are not ack'ed by this FIN,
what should I do?
  - can I discard the oustanding bytes, since the receiver will anyhow not 
accept it.

- Manju 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: FIN and oustanding bytes
Date: Wed, 28 Feb 2007 18:48:36 -0800
Lines: 31
Distribution: su
Message-ID: <es5etu$9p0$1@news.Stanford.EDU>
References: <es5coq$8i4$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172717310 10016 128.12.194.72 (1 Mar 2007 02:48:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es5coq$8i4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12020

manj wrote:
> 1)
> If I get an APP_CLOSE_REQUESTED, when there are still outstanding bytes in 
> the sender window,
> what is the semanitcs to handle this case?
>   - should I discard these bytes and send out a FIN.
>   - or, should I wait until the other side accepts and ack's all the data 
> before sending out a FIN.
> 
You should probably wait until the other side has ack'ed all the data 
that your app has given you to send, before sending the FIN. Otherwise, 
the data would be lost.

> 2)
> If I get a FIN, when there are still outstanding bytes in my send window, 
> which are not ack'ed by this FIN,
> what should I do?
>   - can I discard the oustanding bytes, since the receiver will anyhow not 
> accept it.
> 
> - Manju 
> 
> 

Nope, you should still send them. If a host sends a FIN to you, that 
indicates that it will not send more data, but it will still accept data 
from you until it sees a FIN sent by you.

Disclaimer: I'm not a TA.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: FIN and oustanding bytes
Date: Wed, 28 Feb 2007 18:53:03 -0800
Lines: 27
Distribution: su
Message-ID: <es5f6h$a4f$1@news.Stanford.EDU>
References: <es5coq$8i4$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172717585 10383 127.0.0.1 (1 Mar 2007 02:53:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:12021

Interesting...

> 1)
> If I get an APP_CLOSE_REQUESTED, when there are still outstanding bytes in 
> the sender window,
> what is the semanitcs to handle this case?
>  - should I discard these bytes and send out a FIN.

If we do that, what will we use as the sequence number for FIN?

>  - or, should I wait until the other side accepts and ack's all the data 
> before sending out a FIN.

But, how long?

>
> 2)
> If I get a FIN, when there are still outstanding bytes in my send window, 
> which are not ack'ed by this FIN,
> what should I do?
>  - can I discard the oustanding bytes, since the receiver will anyhow not 
> accept it.

Sending a FIN only means that the sender will not send any more data. It 
does not mean that it will not receive any more data. 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS3 Q2
Date: Wed, 28 Feb 2007 19:00:41 -0800
Lines: 11
Distribution: su
Message-ID: <es5fka$ah8$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172718026 10792 171.64.74.36 (1 Mar 2007 03:00:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:12022

Hi guys,

For this question, what is p? Is it the probability of loss due to the
drop from congestion which happens only when W reaches Wmax? i.e. is the
loss we are considering the one-packet drop when W=Wmax?

And for part c, when we say RTT is changing with W, is this the change
due to the non-zero transmission time?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: timeout + 0 send window size
Date: Wed, 28 Feb 2007 21:01:13 -0800
Lines: 10
Distribution: su
Message-ID: <es5mms$faf$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab422649.stanford.edu
X-Trace: news.Stanford.EDU 1172725276 15695 171.66.38.73 (1 Mar 2007 05:01:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12023

If I get a TIMEOUT event, and I find that my send window size is zero. How 
should I handle this?

 -  should I treat this as a retry, and just bump up the retry count, even 
though I am not sending
     any packets.
-   or should I wait again with the same rto, until the send-window opens 
up? 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 21:23:01 -0800
Lines: 25
Distribution: su
Message-ID: <es5nu0$g2q$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172726528 16474 127.0.0.1 (1 Mar 2007 05:22:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12024

>I don't see why the receiver would ever want to shrink the sender's window 
>once the size has been set. The receiver advertises a size based on its own 
>data processing speed, which should really remain constant for the duration 
>of the connection.
Not necessarily:
1. Buffers shared between multiple connections.  The server opens up another 
connection and redistributes his buffers.
2. You unplug your laptop, and it powers down processing power.
3. Failure of computer with a hot backup, and the new computer has smaller 
buffers (okay, it's not likely to maintain the TCP window.
4. The grading script is writen to do this :-).  (No, I don't know if it 
is.)
5. The app had to go run a 10 second query and it stops reading from the 
network buffers for that time.  The last is probably pretty common.

> You probably just want to determine the sender's window size during 
> handshaking and have it be fixed for the rest of the connection.
I don't recommend that!

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout + 0 send window size
Date: Wed, 28 Feb 2007 22:14:49 -0800
Lines: 16
Distribution: su
Message-ID: <es5r0i$htk$1@news.Stanford.EDU>
References: <es5mms$faf$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172729682 18356 128.12.194.72 (1 Mar 2007 06:14:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es5mms$faf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12025

manj wrote:
> If I get a TIMEOUT event, and I find that my send window size is zero. How 
> should I handle this?
> 
>  -  should I treat this as a retry, and just bump up the retry count, even 
> though I am not sending
>      any packets.
> -   or should I wait again with the same rto, until the send-window opens 
> up? 
> 
> 
You should "turn off" your timer if your send window is empty.

Disclaimer: I'm not a TA.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 22:24:00 -0800
Lines: 45
Distribution: su
Message-ID: <es5rhp$i8t$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172730233 18717 128.12.194.72 (1 Mar 2007 06:23:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es5nu0$g2q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12026

That's a good point, but I view the advertised receive window size 
during handshaking as a contract between the two hosts. If any of the 
events you listed (besides 4) happens, the host that is reducing the 
advertised window size can always teardown the connection and start a 
new one.

As I just re-read the FAQ this afternoon, I'm pretty sure this one isn't 
covered. Perhaps a TA can clarify this?

Randy Jennings wrote:
>>I don't see why the receiver would ever want to shrink the sender's window 
>>once the size has been set. The receiver advertises a size based on its own 
>>data processing speed, which should really remain constant for the duration 
>>of the connection.
> 
> Not necessarily:
> 1. Buffers shared between multiple connections.  The server opens up another 
> connection and redistributes his buffers.
> 2. You unplug your laptop, and it powers down processing power.
> 3. Failure of computer with a hot backup, and the new computer has smaller 
> buffers (okay, it's not likely to maintain the TCP window.
> 4. The grading script is writen to do this :-).  (No, I don't know if it 
> is.)

Now, Randy, I must mention that I'm against the practice of offering the 
TAs crazy corner cases in the hopes of them adding them to their grading 
scripts. It's mean to the other students. :)

> 5. The app had to go run a 10 second query and it stops reading from the 
> network buffers for that time.  The last is probably pretty common.
> 
> 
>>You probably just want to determine the sender's window size during 
>>handshaking and have it be fixed for the rest of the connection.
> 
> I don't recommend that!
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Wed, 28 Feb 2007 22:29:17 -0800
Lines: 13
Distribution: su
Message-ID: <es5rrm$id8$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172730551 18856 128.12.194.72 (1 Mar 2007 06:29:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <es5nu0$g2q$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12027

Randy Jennings wrote:

> 5. The app had to go run a 10 second query and it stops reading from the 
> network buffers for that time.  The last is probably pretty common.

So we... reduce the advertised window size to 0?

Good gravy! I believe you just found another TCP exploit! We can open 
TCP connections and make them lock up! :)

Well, I hope that regular TCP implementations are not that gullible. :p

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout + 0 send window size
Date: Thu, 1 Mar 2007 01:42:06 -0500
Lines: 26
Distribution: su
Message-ID: <es5sk2$j0c$1@news.Stanford.EDU>
References: <es5mms$faf$1@news.Stanford.EDU> <es5r0i$htk$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172731330 19468 127.0.0.1 (1 Mar 2007 06:42:10 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12028

Remember, if the other side is not generating data and you don't send any 
data to it, you will never get a new datagram with a new window size and you 
will be locked in to a 0 window forever.  This is bad.  The RFC says that, 
even if you have a receive window of zero you must always be able to accept 
a datagram with a payload of one byte.

-Seth

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:es5r0i$htk$1@news.Stanford.EDU...
> manj wrote:
>> If I get a TIMEOUT event, and I find that my send window size is zero. 
>> How should I handle this?
>>
>>  -  should I treat this as a retry, and just bump up the retry count, 
>> even though I am not sending
>>      any packets.
>> -   or should I wait again with the same rto, until the send-window opens 
>> up?
> You should "turn off" your timer if your send window is empty.
>
> Disclaimer: I'm not a TA.
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout + 0 send window size
Date: Thu, 1 Mar 2007 01:48:58 -0500
Lines: 40
Distribution: su
Message-ID: <es5t0s$j6i$1@news.Stanford.EDU>
References: <es5mms$faf$1@news.Stanford.EDU> <es5r0i$htk$1@news.Stanford.EDU> <es5sk2$j0c$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172731740 19666 127.0.0.1 (1 Mar 2007 06:49:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12029

You know what, I wrote that off the top of my head, then went to verify it 
(should have done that earlier) and can't actually find it anywhere.  I 
still think I remember reading that but don't know where.  The only thing I 
found in the RFC was that even with a zero receive window, you need to 
respond to RST and URG flags (although we don't recognize those in STCP).

Ah well.

-Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:es5sk2$j0c$1@news.Stanford.EDU...
> Remember, if the other side is not generating data and you don't send any 
> data to it, you will never get a new datagram with a new window size and 
> you will be locked in to a 0 window forever.  This is bad.  The RFC says 
> that, even if you have a receive window of zero you must always be able to 
> accept a datagram with a payload of one byte.
>
> -Seth
>
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:es5r0i$htk$1@news.Stanford.EDU...
>> manj wrote:
>>> If I get a TIMEOUT event, and I find that my send window size is zero. 
>>> How should I handle this?
>>>
>>>  -  should I treat this as a retry, and just bump up the retry count, 
>>> even though I am not sending
>>>      any packets.
>>> -   or should I wait again with the same rto, until the send-window 
>>> opens up?
>> You should "turn off" your timer if your send window is empty.
>>
>> Disclaimer: I'm not a TA.
>>
>> -Yangfan
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: intial RTO value
Date: Wed, 28 Feb 2007 23:25:18 -0800
Lines: 29
Distribution: su
Message-ID: <es5v4u$kja$1@news.Stanford.EDU>
References: <es53g1$t1a$1@news.Stanford.EDU> <es5403$1t$3@news.Stanford.EDU> <es54i2$s8$1@news.Stanford.EDU> <es54su$12v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172733918 21098 127.0.0.1 (1 Mar 2007 07:25:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es54su$12v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12031

manj wrote:
> FYI:
> 
> I looked at rfc 1122. And it states the following:
> 
>             The following values SHOULD be used to initialize the
>             estimation parameters for a new connection:
> 
>             (a)  RTT = 0 seconds.
> 
>             (b)  RTO = 3 seconds.  (The smoothed variance is to be
>                  initialized to the value that will result in this RTO).
> 
>             The recommended upper and lower bounds on the RTO are known
>             to be inadequate on large internets.  The lower bound SHOULD
>             be measured in fractions of a second (to accommodate high
>             speed LANs) and the upper bound should be 2*MSL, i.e., 240
>             seconds.
> 
>             DISCUSSION:
>                  Experience has shown that these initialization values
>                  are reasonable, and that in any case the Karn and
>                  Jacobson algorithms make TCP behavior reasonably
>                  insensitive to the initial parameter choices."manj" 


Good footwork, and sounds good to me.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: repost: packet length
Date: Wed, 28 Feb 2007 23:26:16 -0800
Lines: 20
Distribution: su
Message-ID: <es5v6o$kja$2@news.Stanford.EDU>
References: <es55ct$1o5$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172733976 21098 127.0.0.1 (1 Mar 2007 07:26:16 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es55ct$1o5$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12032

Tom Deane wrote:
> If I send a packet with 20 bytes of data across the network and I receive
> the packet at the other end, can we assume that the packet will also have 20
> bytes of uncorrupted data at the other end?... this would make me very
> happy.
> 
> I found something related in the FAQ but it talks about the packet length in
> the tcp header.... however,  I don't see any length field in the tcp header
> (i might be blind). I think the only way we are calculating length right now
> is by looking at the number of bytes we get from network_recv... so i guess
> my question is if that length will always be the one intended.
> 
> Tom 
> 
> 

Ya we aren't purposely corrupting your data, you can count on it being 
dropped or reordered however.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout + 0 send window size
Date: Wed, 28 Feb 2007 23:33:40 -0800
Lines: 15
Distribution: su
Message-ID: <es5vkl$kv1$1@news.Stanford.EDU>
References: <es5mms$faf$1@news.Stanford.EDU> <es5r0i$htk$1@news.Stanford.EDU> <es5sk2$j0c$1@news.Stanford.EDU> <es5t0s$j6i$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172734421 21473 127.0.0.1 (1 Mar 2007 07:33:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es5t0s$j6i$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12033

Seth Wright wrote:
> You know what, I wrote that off the top of my head, then went to verify it 
> (should have done that earlier) and can't actually find it anywhere.  I 
> still think I remember reading that but don't know where.  The only thing I 
> found in the RFC was that even with a zero receive window, you need to 
> respond to RST and URG flags (although we don't recognize those in STCP).
> 
> Ah well.
> 
> -Seth

If you check the bottom of page 248 of the Kurose book it describes the 
situation.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q2
Date: Wed, 28 Feb 2007 23:37:18 -0800
Lines: 17
Distribution: su
Message-ID: <es5vre$kuv$1@news.Stanford.EDU>
References: <es5fka$ah8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172734638 21471 127.0.0.1 (1 Mar 2007 07:37:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es5fka$ah8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12034

Jad Naous wrote:
> Hi guys,
> 
> For this question, what is p? Is it the probability of loss due to the
> drop from congestion which happens only when W reaches Wmax? i.e. is the
> loss we are considering the one-packet drop when W=Wmax?

Yes, p is one drop per 'cycle', a cycle being the time from when the 
sawtooth is at the bottom until it reaches the max.

> And for part c, when we say RTT is changing with W, is this the change
> due to the non-zero transmission time?

Think more about what happens as RTT goes up and down.. what that does 
to your flows speed, and in turn how that affects W.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: timeout + 0 send window size
Date: Thu, 1 Mar 2007 00:54:10 -0700
Lines: 24
Distribution: su
Message-ID: <es60r4$nqj$1@news.Stanford.EDU>
References: <es5mms$faf$1@news.Stanford.EDU> <es5r0i$htk$1@news.Stanford.EDU> <es5sk2$j0c$1@news.Stanford.EDU> <es5t0s$j6i$1@news.Stanford.EDU> <es5vkl$kv1$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172735653 24403 127.0.0.1 (1 Mar 2007 07:54:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12035

See also RFC 793 at p. 42.

--Kevin

"David Erickson" <derickso@stanford.edu> wrote in message 
news:es5vkl$kv1$1@news.Stanford.EDU...
> Seth Wright wrote:
>> You know what, I wrote that off the top of my head, then went to verify 
>> it (should have done that earlier) and can't actually find it anywhere. 
>> I still think I remember reading that but don't know where.  The only 
>> thing I found in the RFC was that even with a zero receive window, you 
>> need to respond to RST and URG flags (although we don't recognize those 
>> in STCP).
>>
>> Ah well.
>>
>> -Seth
>
> If you check the bottom of page 248 of the Kurose book it describes the 
> situation.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q2
Date: Thu, 1 Mar 2007 02:59:20 -0500
Lines: 28
Distribution: su
Message-ID: <es614t$o34$1@news.Stanford.EDU>
References: <es5fka$ah8$1@news.Stanford.EDU> <es5vre$kuv$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172735966 24676 127.0.0.1 (1 Mar 2007 07:59:26 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12036

Just to be extra clear, p is the probability that there is just one drop per 
cycle.  (I had originally read it that p was the probability that any one 
packet would get dropped or rather be un-acked)

-Seth


"David Erickson" <derickso@stanford.edu> wrote in message 
news:es5vre$kuv$1@news.Stanford.EDU...
> Jad Naous wrote:
>> Hi guys,
>>
>> For this question, what is p? Is it the probability of loss due to the
>> drop from congestion which happens only when W reaches Wmax? i.e. is the
>> loss we are considering the one-packet drop when W=Wmax?
>
> Yes, p is one drop per 'cycle', a cycle being the time from when the 
> sawtooth is at the bottom until it reaches the max.
>
>> And for part c, when we say RTT is changing with W, is this the change
>> due to the non-zero transmission time?
>
> Think more about what happens as RTT goes up and down.. what that does to 
> your flows speed, and in turn how that affects W.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q2
Date: Thu, 1 Mar 2007 03:00:21 -0500
Lines: 37
Distribution: su
Message-ID: <es616o$oa3$1@news.Stanford.EDU>
References: <es5fka$ah8$1@news.Stanford.EDU> <es5vre$kuv$1@news.Stanford.EDU> <es614t$o34$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172736024 24899 127.0.0.1 (1 Mar 2007 08:00:24 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12037

That was supposed to be a question. i.e. "Just to be extra clear, p is the 
probability that there is just one drop per cycle?"

-Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:es614t$o34$1@news.Stanford.EDU...
> Just to be extra clear, p is the probability that there is just one drop 
> per cycle.  (I had originally read it that p was the probability that any 
> one packet would get dropped or rather be un-acked)
>
> -Seth
>
>
> "David Erickson" <derickso@stanford.edu> wrote in message 
> news:es5vre$kuv$1@news.Stanford.EDU...
>> Jad Naous wrote:
>>> Hi guys,
>>>
>>> For this question, what is p? Is it the probability of loss due to the
>>> drop from congestion which happens only when W reaches Wmax? i.e. is the
>>> loss we are considering the one-packet drop when W=Wmax?
>>
>> Yes, p is one drop per 'cycle', a cycle being the time from when the 
>> sawtooth is at the bottom until it reaches the max.
>>
>>> And for part c, when we say RTT is changing with W, is this the change
>>> due to the non-zero transmission time?
>>
>> Think more about what happens as RTT goes up and down.. what that does to 
>> your flows speed, and in turn how that affects W.
>>
>> -David
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q2
Date: Thu, 01 Mar 2007 00:08:48 -0800
Lines: 10
Distribution: su
Message-ID: <es61mg$ogt$1@news.Stanford.EDU>
References: <es5fka$ah8$1@news.Stanford.EDU> <es5vre$kuv$1@news.Stanford.EDU> <es614t$o34$1@news.Stanford.EDU> <es616o$oa3$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172736528 25117 127.0.0.1 (1 Mar 2007 08:08:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <es616o$oa3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12038

Seth Wright wrote:
> That was supposed to be a question. i.e. "Just to be extra clear, p is the 
> probability that there is just one drop per cycle?"
> 
> -Seth
> 

Correct, one per cycle.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS3 4b
Date: Thu, 1 Mar 2007 02:52:06 -0800
Lines: 17
Distribution: su
Message-ID: <es6b9b$1p5$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1172746347 1829 171.64.75.59 (1 Mar 2007 10:52:27 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12039


Hi,

I'm having trouble understanding a part of problem 4b.
The problem seems to imply that you can decrease the
minimum packet size by "expanding" the network.

What do you mean by expanding the network?
I don't see how adding more computers or
increasing the data rates can decrease the minimum
packet size.

Obviously, I am missing something ..

- Steven


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Thu, 1 Mar 2007 09:26:47 -0800
Lines: 20
Distribution: su
Message-ID: <es72b0$ni2$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rrm$id8$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172769952 24130 127.0.0.1 (1 Mar 2007 17:25:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12040

>> 5. The app had to go run a 10 second query and it stops reading from the 
>> network buffers for that time.  The last is probably pretty common.
>
> So we... reduce the advertised window size to 0?
Yes.
>
> Good gravy! I believe you just found another TCP exploit! We can open TCP 
> connections and make them lock up! :)
Only the really bad ones.  I think you still run the timeouts, but I am not 
sure (someone else was asking about that).  In any case, TCP specifies that 
at regular intervals, if the window is 0, the TCP connection probes it with 
a one byte sequence.  I think the receiver is required to have some slush 
left over to handle these one byte probes, but I am not sure.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q2
Date: Thu, 1 Mar 2007 09:35:48 -0800
Lines: 25
Distribution: su
Message-ID: <es72ru$nvg$1@news.Stanford.EDU>
References: <es5fka$ah8$1@news.Stanford.EDU> <es5vre$kuv$1@news.Stanford.EDU> <es614t$o34$1@news.Stanford.EDU> <es616o$oa3$1@news.Stanford.EDU> <es61mg$ogt$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172770494 24560 127.0.0.1 (1 Mar 2007 17:34:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12041

>> That was supposed to be a question. i.e. "Just to be extra clear, p is 
>> the probability that there is just one drop per cycle?"
> Correct, one per cycle.

I think that there may be a misunderstanding about what it means to assign a 
probability to a deterministic cycle.  The probability that there is one 
drop per cycle is 1 (as specified in the problem).  The probability that the 
packet transmitted, when you get to W(hat), is dropped is 1.  The 
probability that a packet transmitted, before you get to W(hat), is dropped 
is 0.

I believe what the question is trying to get us to do is consider the cycle 
as a sample space.  Given that there is one drop in the cycle, choose one 
packet from that cycle uniformly, at random.  What is the probability that 
this particular packet is the one that is dropped?  This was never clearly 
stated in the lecture or assignment, but that is the only way I can rectify 
the question.  I do get the expected form of the answer when I consider it 
this way.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Thu, 01 Mar 2007 10:14:33 -0800
Lines: 15
Distribution: su
Message-ID: <C20C5809.8D93%jpettit@stanford.edu>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rrm$id8$1@news.Stanford.EDU> <es72b0$ni2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172772877 27497 127.0.0.1 (1 Mar 2007 18:14:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: sliding window
Thread-Index: AcdcLXY3tMhknsggEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12042

>> Good gravy! I believe you just found another TCP exploit! We can open TCP
>> connections and make them lock up! :)
> Only the really bad ones.  I think you still run the timeouts, but I am not
> sure (someone else was asking about that).  In any case, TCP specifies that
> at regular intervals, if the window is 0, the TCP connection probes it with
> a one byte sequence.  I think the receiver is required to have some slush
> left over to handle these one byte probes, but I am not sure.

All the books are a little unclear about the contents of this one byte
probe.  I asked Professor McKeown a couple of days ago, and he said that
it's not new data, but just the last byte that fit in the window that is
retransmitted.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS3 Q4
Date: Thu, 01 Mar 2007 10:17:15 -0800
Lines: 9
Distribution: su
Message-ID: <es757q$qtq$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172772922 27578 128.12.134.140 (1 Mar 2007 18:15:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:12043

Hi,

For this question, is it that only 1 packet should collide at a time?
You could make Transp as small as you like, but you will have multiple
packets colliding at a time and you might need some timers. Is this what
is meant by the question?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Thu, 01 Mar 2007 10:25:50 -0800
Lines: 16
Distribution: su
Message-ID: <C20C5AAE.8D99%jpettit@stanford.edu>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rhp$i8t$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172773553 28465 127.0.0.1 (1 Mar 2007 18:25:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: sliding window
Thread-Index: AcdcLwm9SCKgtMgiEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12044

> That's a good point, but I view the advertised receive window size
> during handshaking as a contract between the two hosts. If any of the
> events you listed (besides 4) happens, the host that is reducing the
> advertised window size can always teardown the connection and start a
> new one.
> 
> As I just re-read the FAQ this afternoon, I'm pretty sure this one isn't
> covered. Perhaps a TA can clarify this?

I'm not completely sure that I understand the question, but I'll take a stab
at it.  In TCP, the receiver window can change while the connection is
established.  However, in STCP, this value is fixed to 3072.  As described
in the assignment, we will only test your code with a fixed value of 3072.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Thu, 1 Mar 2007 11:21:47 -0800
Lines: 16
Distribution: su
Message-ID: <es792l$20s$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rrm$id8$1@news.Stanford.EDU> <es72b0$ni2$1@news.Stanford.EDU> <C20C5809.8D93%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172776853 2076 127.0.0.1 (1 Mar 2007 19:20:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12046

> All the books are a little unclear about the contents of this one byte
> probe.  I asked Professor McKeown a couple of days ago, and he said that
> it's not new data, but just the last byte that fit in the window that is
> retransmitted.
Ugh!  That makes sense, but that means you have to keep around one acked 
byte.  Definitely doable, but my structure is not built for it!  Hmm... I'll 
have to see if I can shoehorn it in.

Did he say how to do the timeouts in this case?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 Q4
Date: Thu, 01 Mar 2007 11:22:38 -0800
Lines: 12
Distribution: su
Message-ID: <C20C67FE.8DA7%jpettit@stanford.edu>
References: <es757q$qtq$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172776959 2117 127.0.0.1 (1 Mar 2007 19:22:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS3 Q4
Thread-Index: AcdcNvkRN7LyCMgqEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12047

> For this question, is it that only 1 packet should collide at a time?
> You could make Transp as small as you like, but you will have multiple
> packets colliding at a time and you might need some timers. Is this what
> is meant by the question?

You could do it that way, but there are some potential problems.  Question
4a is asking why is there a minimum packet size as opposed to some other
method like the one you described.  Don't over-think 4a, leave that for 4b.
:)

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Thu, 1 Mar 2007 11:30:32 -0800
Lines: 21
Distribution: su
Message-ID: <es79kr$2nq$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rrm$id8$1@news.Stanford.EDU> <es72b0$ni2$1@news.Stanford.EDU> <C20C5809.8D93%jpettit@stanford.edu> <es792l$20s$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172777435 2810 127.0.0.1 (1 Mar 2007 19:30:35 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:12048

Or you could just re-use an acked sequence number with some junk byte in it.

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:es792l$20s$1@news.Stanford.EDU...
>> All the books are a little unclear about the contents of this one byte
>> probe.  I asked Professor McKeown a couple of days ago, and he said that
>> it's not new data, but just the last byte that fit in the window that is
>> retransmitted.
> Ugh!  That makes sense, but that means you have to keep around one acked 
> byte.  Definitely doable, but my structure is not built for it!  Hmm... 
> I'll have to see if I can shoehorn it in.
>
> Did he say how to do the timeouts in this case?
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Peter Pawlowski <pawlowski@stanford.edu>
Newsgroups: su.class.cs244a
Subject: gcc v. g++
Date: Thu, 1 Mar 2007 12:44:34 -0800
Lines: 12
Distribution: su
Message-ID: <es7dvk$710$1@news.Stanford.EDU>
NNTP-Posting-Host: piotrek-laptop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1172781876 7200 128.12.104.76 (1 Mar 2007 20:44:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.7
Xref: shelby.stanford.edu su.class.cs244a:12049

Hello--

The provided Makefile uses g++ as CC, probably because the reference 
proxy was written in C++. However, this breaks some things in my code 
(mainly having to do with casts of pointers). Can we request that our 
transport layer be compiled with a C compiler (i.e., gcc), as opposed 
to a C++ one?

Thanks,
Peter


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gcc v. g++
Date: Thu, 01 Mar 2007 15:05:53 -0800
Lines: 12
Distribution: su
Message-ID: <C20C9C51.8DBF%jpettit@stanford.edu>
References: <es7dvk$710$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172790355 14472 127.0.0.1 (1 Mar 2007 23:05:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: gcc v. g++
Thread-Index: AcdcVikcZ7+C0MhJEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12050

> The provided Makefile uses g++ as CC, probably because the reference
> proxy was written in C++. However, this breaks some things in my code
> (mainly having to do with casts of pointers). Can we request that our
> transport layer be compiled with a C compiler (i.e., gcc), as opposed
> to a C++ one?

That's fine.  Can you put that in big bold letters at the top of your README
file for part C?

--Justin 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: gcc v. g++
Date: Thu, 01 Mar 2007 15:10:35 -0800
Lines: 16
Distribution: su
Message-ID: <C20C9D6B.8DC1%jpettit@stanford.edu>
References: <es7dvk$710$1@news.Stanford.EDU> <C20C9C51.8DBF%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172790639 14820 127.0.0.1 (1 Mar 2007 23:10:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: gcc v. g++
Thread-Index: AcdcVikcZ7+C0MhJEdum0QARJDbi7gAAKgUp
Xref: shelby.stanford.edu su.class.cs244a:12051

>> The provided Makefile uses g++ as CC, probably because the reference
>> proxy was written in C++. However, this breaks some things in my code
>> (mainly having to do with casts of pointers). Can we request that our
>> transport layer be compiled with a C compiler (i.e., gcc), as opposed
>> to a C++ one?
> 
> That's fine.  Can you put that in big bold letters at the top of your README
> file for part C?

Since you are required to supply a Makefile for that milestone, just have it
setup so that it builds it however is necessary.  Just remember to build
with -Wall!

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 4b
Date: Thu, 01 Mar 2007 21:26:29 -0800
Lines: 15
Distribution: su
Message-ID: <C20CF585.8DE1%jpettit@stanford.edu>
References: <es6b9b$1p5$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172813189 3855 127.0.0.1 (2 Mar 2007 05:26:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS3 4b
Thread-Index: Acdci1RtkzBN3sh+Edum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12052

 > I'm having trouble understanding a part of problem 4b.
> The problem seems to imply that you can decrease the
> minimum packet size by "expanding" the network.
> 
> What do you mean by expanding the network?
> I don't see how adding more computers or
> increasing the data rates can decrease the minimum
> packet size.

I'm not really clear on what is meant by that either.  You can still answer
the question by replacing "without expanding the network" with "without
modifying the physical properties of the network."

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 4b
Date: Thu, 1 Mar 2007 23:40:10 -0800
Lines: 21
Distribution: su
Message-ID: <es8kdh$9eb$1@news.Stanford.EDU>
References: <es6b9b$1p5$1@news.Stanford.EDU> <C20CF585.8DE1%jpettit@stanford.edu>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1172821233 9675 171.64.75.59 (2 Mar 2007 07:40:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12053


Maybe I'm the only one confused about this problem..
The PROP in equation (1) is the propagation time between the
furthest two nodes. I don't see how the propagation times between closer 
nodes
can affect the worst case where it takes 2*PROP time to detect a collision.
Do the nodes in the middle have some special functionality (for example,
acting like switches)?

-Steven


> I'm not really clear on what is meant by that either.  You can still 
> answer
> the question by replacing "without expanding the network" with "without
> modifying the physical properties of the network."
>
> --Justin
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 4b
Date: Fri, 02 Mar 2007 00:58:56 -0800
Lines: 14
Distribution: su
Message-ID: <C20D2750.8DE9%jpettit@stanford.edu>
References: <es6b9b$1p5$1@news.Stanford.EDU> <C20CF585.8DE1%jpettit@stanford.edu> <es8kdh$9eb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172825945 19591 127.0.0.1 (2 Mar 2007 08:59:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS3 4b
Thread-Index: AcdcqQI7QQVOBsicEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12055

> Maybe I'm the only one confused about this problem..
> The PROP in equation (1) is the propagation time between the
> furthest two nodes. I don't see how the propagation times between closer
> nodes
> can affect the worst case where it takes 2*PROP time to detect a collision.
> Do the nodes in the middle have some special functionality (for example,
> acting like switches)?

No, they're just regular nodes.  You just happen to know how far away the
closest one to you is.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS3 4b
Date: Fri, 2 Mar 2007 03:49:52 -0800
Lines: 13
Distribution: su
Message-ID: <es931o$sm9$1@news.Stanford.EDU>
References: <es6b9b$1p5$1@news.Stanford.EDU> <C20CF585.8DE1%jpettit@stanford.edu> <es8kdh$9eb$1@news.Stanford.EDU> <C20D2750.8DE9%jpettit@stanford.edu>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1172836216 29385 171.64.75.59 (2 Mar 2007 11:50:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12056


I finally got it.. thanks!
-Steven


> No, they're just regular nodes.  You just happen to know how far away the
> closest one to you is.
>
> --Justin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: RST flag and half open connections
Date: Fri, 02 Mar 2007 09:59:29 -0800
Lines: 6
Distribution: su
Message-ID: <es9oif$m7l$1@news.Stanford.EDU>
NNTP-Posting-Host: jadsdesktop.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172858256 22773 128.12.134.140 (2 Mar 2007 17:57:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:12057

The assignment says we are not required to handle the RST flag. So can I
assume that the other side of the STCP is behaving correctly? As in it
won't leave half open connections and mess up or crash, etc...?

Thanks
Jad
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: server/client in interactive mode
Date: Fri, 2 Mar 2007 11:03:57 -0800
Lines: 20
Distribution: su
Message-ID: <es9sd7$q86$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172862183 26886 127.0.0.1 (2 Mar 2007 19:03:03 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12058

When you start up the client in interactive mode, there is no way to quit 
out of the program (and it ignores one character inputs, but that does not 
matter much).

As such, I have been exiting with ^C.  Unfortunately, that means that the 
connection does not clean up correctly.  The server never gets a FIN, and it 
does not send a FIN after servicing the last request.  As such, the server 
transport thread sticks around waiting for another even.  Since it has no 
packets to send it never times out.  The other (network layer) thread does 
terminate.

I think leaking the thread is correct behavior as defined by our assignment. 
Is that reading correct?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "James Overton" <joverton@stanford.edu>
Newsgroups: su.class.cs244a
Subject: turning in problem set late
Date: Fri, 2 Mar 2007 15:01:16 -0800
Lines: 4
Distribution: su
Message-ID: <esaabs$aof$1@news.Stanford.EDU>
NNTP-Posting-Host: sae-03-s280-cl.stanford.edu
X-Trace: news.Stanford.EDU 1172876476 11023 128.12.76.244 (2 Mar 2007 23:01:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12059

I know the problem set was due at noon, if I take a late day can I turn it 
in by noon tomorrow, or does it have to be by five today? 


.

Path: shelby.stanford.edu!not-for-mail
From: "James Overton" <joverton@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: turning in problem set late
Date: Fri, 2 Mar 2007 15:17:33 -0800
Lines: 11
Distribution: su
Message-ID: <esabah$bfa$1@news.Stanford.EDU>
References: <esaabs$aof$1@news.Stanford.EDU>
NNTP-Posting-Host: sae-03-s280-cl.stanford.edu
X-Trace: news.Stanford.EDU 1172877457 11754 128.12.76.244 (2 Mar 2007 23:17:37 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12060

Ok, I got it.  So the five late deadline for ps2 was because the solutions 
had to be posted for the midterm. So do I turn it in my Judy Polenta's 
office or should I stop by one of the TA's?

"James Overton" <joverton@stanford.edu> wrote in message 
news:esaabs$aof$1@news.Stanford.EDU...
>I know the problem set was due at noon, if I take a late day can I turn it 
>in by noon tomorrow, or does it have to be by five today?
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: turning in problem set late
Date: Fri, 02 Mar 2007 16:10:00 -0800
Lines: 9
Distribution: su
Message-ID: <C20DFCD8.8E20%jpettit@stanford.edu>
References: <esaabs$aof$1@news.Stanford.EDU> <esabah$bfa$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172880607 14362 127.0.0.1 (3 Mar 2007 00:10:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: turning in problem set late
Thread-Index: AcddKEiDhyrfPckbEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12061

> Ok, I got it.  So the five late deadline for ps2 was because the solutions
> had to be posted for the midterm. So do I turn it in my Judy Polenta's
> office or should I stop by one of the TA's?

Drop them off in front of Judy Polenta's door (Gates 351) by noon tomorrow.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: server/client in interactive mode
Date: Fri, 2 Mar 2007 17:01:53 -0800
Lines: 25
Distribution: su
Message-ID: <esahc9$g7j$1@news.Stanford.EDU>
References: <es9sd7$q86$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172883657 16627 127.0.0.1 (3 Mar 2007 01:00:57 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12062

> When you start up the client in interactive mode, there is no way to quit 
> out of the program (and it ignores one character inputs, but that does not 
> matter much).
>
> As such, I have been exiting with ^C.  Unfortunately, that means that the 
> connection does not clean up correctly.  The server never gets a FIN, and 
> it does not send a FIN after servicing the last request.  As such, the 
> server transport thread sticks around waiting for another even.  Since it 
> has no packets to send it never times out.  The other (network layer) 
> thread does terminate.
>
> I think leaking the thread is correct behavior as defined by our 
> assignment. Is that reading correct?
Unfortunately, this means that the server network/transport layer will 
connect the client when it is run again, but the server will not respond to 
the request for file.  Both the client and the server are then hung.

This is a bug in the server code right?  Not our code?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: What to do after 5 retransmissions?
Date: Fri, 02 Mar 2007 22:45:55 -0500
Lines: 15
Distribution: su
Message-ID: <esar4s$njr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172893661 24187 127.0.0.1 (3 Mar 2007 03:47:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:12063

What happens after a packet has been retransmitted 5 times without 
acknowledgment?

a) Go to CLOSED state without sending any FIN packets

b) Send out a FIN packet and go to FIN_WAIT_1 state

c) Something else


If the answer is (b), what if the FIN packet itself is not acknowledged 
after 5 retransmissions?

Thanks,
Jin
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: What to do after 5 retransmissions?
Date: Fri, 2 Mar 2007 21:43:42 -0700
Lines: 29
Distribution: su
Message-ID: <esaun0$pqv$1@news.Stanford.EDU>
References: <esar4s$njr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172897346 26463 127.0.0.1 (3 Mar 2007 04:49:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12064

Hi Jin,

I think the answer has to be: go to CLOSED and set errno = ECONNABORTED or 
ETIMEDOUT.  (TA's: Can you let us know which of the two errors is expected 
here?)  The retransmissions part of the handout said "the network is assumed 
to have failed" under these circumstances.  To me, it doesn't make sense to 
do anything further once you've concluded nothing further will work.

--Kevin

"Jin Wang" <jinwang@stanford.edu> wrote in message 
news:esar4s$njr$1@news.Stanford.EDU...
> What happens after a packet has been retransmitted 5 times without 
> acknowledgment?
>
> a) Go to CLOSED state without sending any FIN packets
>
> b) Send out a FIN packet and go to FIN_WAIT_1 state
>
> c) Something else
>
>
> If the answer is (b), what if the FIN packet itself is not acknowledged 
> after 5 retransmissions?
>
> Thanks,
> Jin 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: What to do after 5 retransmissions?
Date: Fri, 2 Mar 2007 21:47:36 -0700
Lines: 31
Distribution: su
Message-ID: <esavgk$qcc$1@news.Stanford.EDU>
References: <esar4s$njr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172898133 27020 127.0.0.1 (3 Mar 2007 05:02:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12065

Hi Jin,

I think the answer has to be go to CLOSED and set errno = ECONNABORTED or 
ETIMEDOUT.  (TAs: Can you let us know which of the two errors is expected 
here?)

The retransmissions part of the handout says "the network is assumed to have 
failed" under these circumstances.  To me, it doesn't make sense to do 
anything further once you've concluded nothing further will work.

--Kevin

"Jin Wang" <jinwang@stanford.edu> wrote in message 
news:esar4s$njr$1@news.Stanford.EDU...
> What happens after a packet has been retransmitted 5 times without 
> acknowledgment?
>
> a) Go to CLOSED state without sending any FIN packets
>
> b) Send out a FIN packet and go to FIN_WAIT_1 state
>
> c) Something else
>
>
> If the answer is (b), what if the FIN packet itself is not acknowledged 
> after 5 retransmissions?
>
> Thanks,
> Jin 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: RST flag and half open connections
Date: Fri, 02 Mar 2007 23:59:24 -0800
Lines: 11
Distribution: su
Message-ID: <C20E6ADC.8E42%jpettit@stanford.edu>
References: <es9oif$m7l$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172908767 5718 127.0.0.1 (3 Mar 2007 07:59:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: RST flag and half open connections
Thread-Index: AcddaduQGioIocldEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12066

> The assignment says we are not required to handle the RST flag. So can I
> assume that the other side of the STCP is behaving correctly? As in it
> won't leave half open connections and mess up or crash, etc...?

We won't run any tests that involve sending or receiving resets.  If you try
interacting with real TCP (highly encouraged!), then it's certainly possible
that you could see them.  We won't test that, though.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Errors from stcp
Date: Sat, 3 Mar 2007 03:04:50 -0500
Lines: 44
Distribution: su
Message-ID: <esba73$5qe$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172909092 5966 127.0.0.1 (3 Mar 2007 08:04:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12067

I'm occasionally getting the following error spit out:
network_io_socket.c:247: void* network_recv_thread_func(void*): Assertion 
`!(fds[1].revents & 0x008)' failed.

The error doesn't really even look like something I could be causing.  The 
offending code is:
assert(!(fds[1].revents & POLLERR));

And comes from a wait loop for a thread trying to poll the socket for 
information and it looks like if an error occurs while polling, the stcp 
network implementation just punts rather than try and do anything graceful. 
I can't imagine what I'm doing wrong, but I wouldn't rule it out.  Is anyone 
else seeing this?

Additionally, when I run my code under valgrind I get the following error 
for what looks like every STCP datagram I send (here are the results for 
when I send a short 50KB file over the client/server program):
==19158== Syscall param write(buf) points to uninitialised byte(s)
==19158==    at 0x4000772: (within /lib/ld-2.3.6.so)
==19158==    by 0x804FA7B: _network_send_packet(network_context_t*, void 
const*, unsigned) (network_io_tcp.c:154)
==19158==    by 0x804D885: _network_send(int, void const*, unsigned) 
(network.c:46)
==19158==    by 0x804C8F5: stcp_network_send(int, void const*, unsigned, 
....) (stcp_api.c:234)
==19158==    by 0x804AA51: sendACK(int, context_t*) (transport.c:865)

Now, my call to stcp_network_send in sendACK looks like this:

stcp_network_send(sd,&header,sizeof(STCPHeader),NULL);

I followed the code in the stcp source files and it copies the data out of 
my passed in pointer immediately, so the fact that header (of type 
STCPHeader) is allocated on the stack shouldn't affect anything, but I'm 
still baffled.  Everything appears to be working correctly, but when you're 
in unreliable mode it can be hard to tell sometimes because it is, well, 
unreliable.

I'm mostly just wondering if anyone else is running into these problems. 
Finally, for both of these, I'm running in unreliable mode.

-Seth 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: What to do after 5 retransmissions?
Date: Sat, 03 Mar 2007 00:08:00 -0800
Lines: 15
Distribution: su
Message-ID: <C20E6CE0.8E44%jpettit@stanford.edu>
References: <esar4s$njr$1@news.Stanford.EDU> <esavgk$qcc$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172909284 6175 127.0.0.1 (3 Mar 2007 08:08:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: What to do after 5 retransmissions?
Thread-Index: Acddaw8gTY0CRsleEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12068

 > I think the answer has to be go to CLOSED and set errno = ECONNABORTED or
> ETIMEDOUT.  (TAs: Can you let us know which of the two errors is expected
> here?)

I'd go with ETIMEDOUT.

> The retransmissions part of the handout says "the network is assumed to have
> failed" under these circumstances.  To me, it doesn't make sense to do
> anything further once you've concluded nothing further will work.

Correct, if you can't send any new data, it is unlikely that you will be
able to start a properly close with FINs.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: server/client in interactive mode
Date: Sat, 03 Mar 2007 00:17:03 -0800
Lines: 30
Distribution: su
Message-ID: <C20E6EFF.8E49%jpettit@stanford.edu>
References: <es9sd7$q86$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172909828 6955 127.0.0.1 (3 Mar 2007 08:17:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: server/client in interactive mode
Thread-Index: AcddbFLHkYOkcslfEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12069

If you hit ^D, the client should gracefully exit.

--Justin


On 3/2/07 11:03 AM, in article es9sd7$q86$1@news.Stanford.EDU, "Randy
Jennings" <randyj@stanford.edu> wrote:

> When you start up the client in interactive mode, there is no way to quit
> out of the program (and it ignores one character inputs, but that does not
> matter much).
> 
> As such, I have been exiting with ^C.  Unfortunately, that means that the
> connection does not clean up correctly.  The server never gets a FIN, and it
> does not send a FIN after servicing the last request.  As such, the server
> transport thread sticks around waiting for another even.  Since it has no
> packets to send it never times out.  The other (network layer) thread does
> terminate.
> 
> I think leaking the thread is correct behavior as defined by our assignment.
> Is that reading correct?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dina Thomas <dinat@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: PA3 testing
Date: Sat, 3 Mar 2007 09:34:44 +0000 (UTC)
Lines: 24
Distribution: su
Message-ID: <esbffk$922$1@news.Stanford.EDU>
NNTP-Posting-Host: myth13.stanford.edu
X-Trace: news.Stanford.EDU 1172914484 9282 171.64.15.2 (3 Mar 2007 09:34:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12070


A few questions:

1. What is a good way to test for interoperability of the code?


2. (Repost) When I get a data packet with FIN flag set then the 
ACK sequence number == sequence number of last byte of data
received +1 ???


3. What does the following line mean from TEST 1.E for part 3.A:

* (/afs/ir.stanford.edu/users/p/t/ptarjan/cs244a-ta/pa3-grading/include/TESTDATA.2)
* Sender window not enforced (786521 bytes were outstanding, but the
* window size is 3072 bytes)

I dont understand how there can be 700KB data outstanding and what 
it has to do with the window size. I guess I am not setting some TCP
header fields correctly but the numbers dont make sense to me. 


Thanks,
Dina
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: questions on part C
Date: Sat, 03 Mar 2007 02:42:21 -0800
Lines: 6
Distribution: su
Message-ID: <esbje0$btl$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172918529 12213 128.12.194.72 (3 Mar 2007 10:42:09 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:12071

1. Do I compile my own proxy with "make your.proxy"? And if so:

2. The compiler is complaining about the main function in my proxy code. 
  Why?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: questions on part C
Date: Sat, 03 Mar 2007 02:56:54 -0800
Lines: 9
Distribution: su
Message-ID: <esbk99$cem$1@news.Stanford.EDU>
References: <esbje0$btl$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172919401 12758 128.12.194.72 (3 Mar 2007 10:56:41 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esbje0$btl$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12072

Scratch those two questions. I figured it out. :)

Yangfan Wang wrote:
> 1. Do I compile my own proxy with "make your.proxy"? And if so:
> 
> 2. The compiler is complaining about the main function in my proxy code. 
>  Why?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Weird crash within myread()
Date: Sat, 03 Mar 2007 03:21:03 -0800
Lines: 24
Distribution: su
Message-ID: <esblmi$dp0$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172920850 14112 128.12.194.72 (3 Mar 2007 11:20:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:12073

I'm getting this weird assertion failure within myread(). If it's 
something that I did, I could use some pointers on how to correct it.

#0  0xffffe410 in ?? ()
#1  0xbf9666ac in ?? ()
#2  0x00000006 in ?? ()
#3  0x00000ef3 in ?? ()
#4  0xb7cf49a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7cf62b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7cedf51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#7  0x0804bfd7 in verify_mysocket_descriptor (comp_ctx=0x0, my_sd=7) at 
mysock.c:408
#8  0x0804c057 in _mysock_get_context (sd=7) at mysock.c:74
#9  0x0804b50f in myread (sd=7, buf=0xbf9668eb, buf_len=1) at 
mysock_api.c:214
#10 0x0804fc58 in myRead (fd=7, buf=0xbf9668eb, count=1) at proxy.c:228
#11 0x0804fcda in myReadLine (fd=7, buf=0x8059ef0, maxLen=512) at 
proxy.c:268
#12 0x0805014e in onGoodRequest (serverFD=7, clientFD=1, 
firstLine=0x8058e80 "GET", secondLine=0x8059088 "Host: www.yahoo.com") 
at proxy.c:544
#13 0x0805073f in main (argc=2, argv=0xbf966a44) at proxy.c:80

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 testing
Date: Sat, 03 Mar 2007 05:21:59 -0800
Lines: 37
Distribution: su
Message-ID: <esbspo$l1p$1@news.Stanford.EDU>
References: <esbffk$922$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172928120 21561 128.12.133.106 (3 Mar 2007 13:22:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <esbffk$922$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12074

> 1. What is a good way to test for interoperability of the code?
Try different endianess machines (elaines have their bits stored in the 
opposite way from the myths).

Also, print out a log of each packet that is sent and received, then 
write down the flow and see if everything is being ACKed and things are 
happening the way you expect. Just following the control flow can save a 
ton of bugs (in log format, rather than in code).

> 2. (Repost) When I get a data packet with FIN flag set then the 
> ACK sequence number == sequence number of last byte of data
> received +1 ???
A FIN packets acts as a single byte in the stream. ACK it accordingly :)


> 
> 3. What does the following line mean from TEST 1.E for part 3.A:
> 
> * (/afs/ir.stanford.edu/users/p/t/ptarjan/cs244a-ta/pa3-grading/include/TESTDATA.2)
> * Sender window not enforced (786521 bytes were outstanding, but the
> * window size is 3072 bytes)
> 
> I dont understand how there can be 700KB data outstanding and what 
> it has to do with the window size. I guess I am not setting some TCP
> header fields correctly but the numbers dont make sense to me. 
Your numbers were probably backwards, so when you thought your sequence 
number was 0x00000001 the network layer saw it as 0x8000000000 and so 
on. Every ACK would have been misinterpreted, etc.

This is why they defined a "network byte order". Solaris has the same 
byte ordering as "network byte order", but linux does not, so you have 
to use honts and hontl to put it in network byte order.

> 
> 
> Thanks,
> Dina
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: faq question
Date: Sat, 3 Mar 2007 05:33:54 -0800
Lines: 17
Distribution: su
Message-ID: <esbtge$ldt$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172928846 21949 128.12.197.229 (3 Mar 2007 13:34:06 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12075

The FAQ says: "... 'close requested event' from stcp_wait_for_event(); this 
is your cue to send a FIN segment once all pending data has been 
successfully transmitted. "

Why do I need to wait until all pending data has been successfully 
tranmistted before sending the FIN?  At least in my implementation of STCP, 
the receiver will not process the FIN if it has not received all previous 
packets in-order (it will just go into the buffer and wait there).  Do we 
have to deal with an implementation of STCP/TCP that actually handles a FIN 
msg (i.e., it calls stcp_fin_received) even when the FIN packet is received 
out-of-order?


Thanks,
Tom


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: faq question
Date: Sat, 3 Mar 2007 05:46:36 -0800
Lines: 29
Distribution: su
Message-ID: <esbu88$m1a$1@news.Stanford.EDU>
References: <esbtge$ldt$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172929608 22570 128.12.197.229 (3 Mar 2007 13:46:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12076

Actually, the same FAQ question tells us that the FIN receiver should wait 
until "all expected data from the peer has been passed up to the 
application" before calling stcp_fin_received....
Again, if we can expect all implementations to follow that behavior, I don't 
see why the FIN sender needs to wait until all pending data has been acked 
before sending that FIN msg... am I missing something?


"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:esbtge$ldt$1@news.Stanford.EDU...
> The FAQ says: "... 'close requested event' from stcp_wait_for_event(); 
> this is your cue to send a FIN segment once all pending data has been 
> successfully transmitted. "
>
> Why do I need to wait until all pending data has been successfully 
> tranmistted before sending the FIN?  At least in my implementation of 
> STCP, the receiver will not process the FIN if it has not received all 
> previous packets in-order (it will just go into the buffer and wait 
> there).  Do we have to deal with an implementation of STCP/TCP that 
> actually handles a FIN msg (i.e., it calls stcp_fin_received) even when 
> the FIN packet is received out-of-order?
>
>
> Thanks,
> Tom
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Weird crash within myread()
Date: Sat, 3 Mar 2007 08:35:52 -0800
Lines: 31
Distribution: su
Message-ID: <esc85b$8u$1@news.Stanford.EDU>
References: <esblmi$dp0$1@news.Stanford.EDU>
NNTP-Posting-Host: zeus2.stanford.edu
X-Trace: news.Stanford.EDU 1172939755 286 128.12.137.163 (3 Mar 2007 16:35:55 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12077

use valgrind to figure out  the source of the problem.


"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:esblmi$dp0$1@news.Stanford.EDU...
> I'm getting this weird assertion failure within myread(). If it's 
> something that I did, I could use some pointers on how to correct it.
>
> #0  0xffffe410 in ?? ()
> #1  0xbf9666ac in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x00000ef3 in ?? ()
> #4  0xb7cf49a1 in raise () from /lib/tls/i686/cmov/libc.so.6
> #5  0xb7cf62b9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #6  0xb7cedf51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
> #7  0x0804bfd7 in verify_mysocket_descriptor (comp_ctx=0x0, my_sd=7) at 
> mysock.c:408
> #8  0x0804c057 in _mysock_get_context (sd=7) at mysock.c:74
> #9  0x0804b50f in myread (sd=7, buf=0xbf9668eb, buf_len=1) at 
> mysock_api.c:214
> #10 0x0804fc58 in myRead (fd=7, buf=0xbf9668eb, count=1) at proxy.c:228
> #11 0x0804fcda in myReadLine (fd=7, buf=0x8059ef0, maxLen=512) at 
> proxy.c:268
> #12 0x0805014e in onGoodRequest (serverFD=7, clientFD=1, 
> firstLine=0x8058e80 "GET", secondLine=0x8059088 "Host: www.yahoo.com") at 
> proxy.c:544
> #13 0x0805073f in main (argc=2, argv=0xbf966a44) at proxy.c:80
>
> -Yangfan 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: faq question
Date: Sat, 3 Mar 2007 13:57:50 -0500
Lines: 44
Distribution: su
Message-ID: <escgfh$816$1@news.Stanford.EDU>
References: <esbtge$ldt$1@news.Stanford.EDU> <esbu88$m1a$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172948273 8230 127.0.0.1 (3 Mar 2007 18:57:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12078

I read the faq as saying that you should put the FIN in your queue so that 
it gets sent in order with the data packets, but not that you have to have 
all data ACKed, just transmitted before you can send the FIN.  i.e. since 
the FIN takes up one byte you have to follow the receiver window rules as to 
when you can send a FIN so if you're past the end of the window, but you get 
a app close event, you don't send the FIN immediately, but rather once 
you've transmitted all pending data at least once.  At least that's how I 
understood the semantics.  TAs, any feedback?

-Seth

"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:esbu88$m1a$1@news.Stanford.EDU...
> Actually, the same FAQ question tells us that the FIN receiver should wait 
> until "all expected data from the peer has been passed up to the 
> application" before calling stcp_fin_received....
> Again, if we can expect all implementations to follow that behavior, I 
> don't see why the FIN sender needs to wait until all pending data has been 
> acked before sending that FIN msg... am I missing something?
>
>
> "Tom Deane" <tdeane@stanford.edu> wrote in message 
> news:esbtge$ldt$1@news.Stanford.EDU...
>> The FAQ says: "... 'close requested event' from stcp_wait_for_event(); 
>> this is your cue to send a FIN segment once all pending data has been 
>> successfully transmitted. "
>>
>> Why do I need to wait until all pending data has been successfully 
>> tranmistted before sending the FIN?  At least in my implementation of 
>> STCP, the receiver will not process the FIN if it has not received all 
>> previous packets in-order (it will just go into the buffer and wait 
>> there).  Do we have to deal with an implementation of STCP/TCP that 
>> actually handles a FIN msg (i.e., it calls stcp_fin_received) even when 
>> the FIN packet is received out-of-order?
>>
>>
>> Thanks,
>> Tom
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 3 Mar 2007 11:28:52 -0800
Lines: 68
Distribution: su
Message-ID: <esci7v$9jr$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172950080 9851 127.0.0.1 (3 Mar 2007 19:28:00 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12079

I am getting both of these issues even in reliable mode.

As best I can tell, the assert happens sometimes when the other side of the 
conn exits or terminates while the assert side is in the process of doing 
something on the network stack.  Usually, I get a SIGPIPE, and everything is 
hunky dory, but sometimes I get the ASSERT.  I do not think it is a problem 
with our code; I think it is a problem with the network layer.  However, 
this has not been confirmed by the TA's

As to the valgrind issue, it most likely comes from not clearing 
STCPHead::th_x2.  The STCPHead::th_urp is cleared by the layer below us, but 
this field is not touched.  I was going to leave it unset because we really 
do not care.  However, the standard on the net is "Set unused fields to 
zero, and ignore on reception" because that allows expansion of the protocol 
most easily.

HTH,
Randy Jennings

The squirrels are your friends!

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:esba73$5qe$1@news.Stanford.EDU...
> I'm occasionally getting the following error spit out:
> network_io_socket.c:247: void* network_recv_thread_func(void*): Assertion 
> `!(fds[1].revents & 0x008)' failed.
>
> The error doesn't really even look like something I could be causing.  The 
> offending code is:
> assert(!(fds[1].revents & POLLERR));
>
> And comes from a wait loop for a thread trying to poll the socket for 
> information and it looks like if an error occurs while polling, the stcp 
> network implementation just punts rather than try and do anything 
> graceful. I can't imagine what I'm doing wrong, but I wouldn't rule it 
> out.  Is anyone else seeing this?
>
> Additionally, when I run my code under valgrind I get the following error 
> for what looks like every STCP datagram I send (here are the results for 
> when I send a short 50KB file over the client/server program):
> ==19158== Syscall param write(buf) points to uninitialised byte(s)
> ==19158==    at 0x4000772: (within /lib/ld-2.3.6.so)
> ==19158==    by 0x804FA7B: _network_send_packet(network_context_t*, void 
> const*, unsigned) (network_io_tcp.c:154)
> ==19158==    by 0x804D885: _network_send(int, void const*, unsigned) 
> (network.c:46)
> ==19158==    by 0x804C8F5: stcp_network_send(int, void const*, unsigned, 
> ...) (stcp_api.c:234)
> ==19158==    by 0x804AA51: sendACK(int, context_t*) (transport.c:865)
>
> Now, my call to stcp_network_send in sendACK looks like this:
>
> stcp_network_send(sd,&header,sizeof(STCPHeader),NULL);
>
> I followed the code in the stcp source files and it copies the data out of 
> my passed in pointer immediately, so the fact that header (of type 
> STCPHeader) is allocated on the stack shouldn't affect anything, but I'm 
> still baffled.  Everything appears to be working correctly, but when 
> you're in unreliable mode it can be hard to tell sometimes because it is, 
> well, unreliable.
>
> I'm mostly just wondering if anyone else is running into these problems. 
> Finally, for both of these, I'm running in unreliable mode.
>
> -Seth
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: FIN bit with data
Date: Sat, 3 Mar 2007 11:34:22 -0800
Lines: 17
Distribution: su
Message-ID: <esciia$9th$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172950410 10161 127.0.0.1 (3 Mar 2007 19:33:30 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12080

This is related to the faq question thread just below (Seth, I think you are 
right, but I am not a TA).

Does the grading script correctly handle the case when the FIN bit is sent 
in a data packet?

The assignment said that such behavior was not required by STCP, but that it 
was allowed.  After failing every test regarding the FIN bit, I just wanted 
to verify this about the grading script. (Yes, I probably have some other 
issues, too.)

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: RST flag and half open connections
Date: Sat, 3 Mar 2007 11:34:49 -0800
Lines: 18
Distribution: su
Message-ID: <escij4$9tv$1@news.Stanford.EDU>
References: <es9oif$m7l$1@news.Stanford.EDU> <C20E6ADC.8E42%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172950436 10175 127.0.0.1 (3 Mar 2007 19:33:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12081


"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C20E6ADC.8E42%jpettit@stanford.edu...
>> The assignment says we are not required to handle the RST flag. So can I
>> assume that the other side of the STCP is behaving correctly? As in it
>> won't leave half open connections and mess up or crash, etc...?
>
> We won't run any tests that involve sending or receiving resets.  If you 
> try
> interacting with real TCP (highly encouraged!), then it's certainly 
> possible
> that you could see them.  We won't test that, though.
>
> --Justin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: RST flag and half open connections
Date: Sat, 3 Mar 2007 11:39:10 -0800
Lines: 22
Distribution: su
Message-ID: <escir9$a3c$1@news.Stanford.EDU>
References: <es9oif$m7l$1@news.Stanford.EDU> <C20E6ADC.8E42%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172950697 10348 127.0.0.1 (3 Mar 2007 19:38:17 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12082

Sorry about the previous empty post.  Finger slipped.
> We won't run any tests that involve sending or receiving resets.  If you 
> try
> interacting with real TCP (highly encouraged!), then it's certainly 
> possible
> that you could see them.  We won't test that, though.
Justin, I have been trying to think about how to do this.  I gave up when a 
previous post said only use STCP on one half of the proxy.  I thought it 
meant because STCP will not talk to TCP with the network strangeness.  Not 
having a sniffer available, I was not able to check the packet format on the 
wire.

Are we just sending out TCP packets with some fields set for us?  That might 
explain why sometimes the checksum fails when you go over the net from/to 
myth5 (and myth11, myth16 AIR).  The check should not be an ASSERT, then!

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: FIN bit with data
Date: Sat, 3 Mar 2007 11:51:23 -0800
Lines: 24
Distribution: su
Message-ID: <escji7$amp$1@news.Stanford.EDU>
References: <esciia$9th$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172951431 10969 127.0.0.1 (3 Mar 2007 19:50:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12083

Side comment: I am not sure if DATA+FIN can happen in part A (w/o an 
extremely invasive test harness), but I know it can happen in part B in my 
code.
"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:esciia$9th$1@news.Stanford.EDU...
> This is related to the faq question thread just below (Seth, I think you 
> are right, but I am not a TA).
>
> Does the grading script correctly handle the case when the FIN bit is sent 
> in a data packet?
>
> The assignment said that such behavior was not required by STCP, but that 
> it was allowed.  After failing every test regarding the FIN bit, I just 
> wanted to verify this about the grading script. (Yes, I probably have some 
> other issues, too.)
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: APP_CLOSE_REQUESTED && APP_DATA
Date: Sat, 3 Mar 2007 11:53:46 -0800
Lines: 24
Distribution: su
Message-ID: <escjmm$ao8$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172951574 11016 127.0.0.1 (3 Mar 2007 19:52:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12084

I just got an idea that could cause problems (though not with the a/b 
grading script, I think).

Can we get APP_CLOSE_REQUESTED and APP_DATA both set on the return from 
stcp_wait_for_event?

This is the scenario I envision:
I start with our rxWin completely unused.
The app does a write of 3073 bytes and then closes the connection.
I get these two flags set.
I read 3072 bytes from the app and then record the sequence number of the 
FIN bit.
I shut of looking for APP_DATA and APP_CLOSE_REQUESTED, thus ignoring the 
last byte of app data.

Now, I do not think this can happen because (AIR) the apps mywrite call 
blocks, preventing the myclose call from executing, but I am not sure.

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 testing
Date: Sat, 03 Mar 2007 12:10:25 -0800
Lines: 22
Distribution: su
Message-ID: <esckni$be6$1@news.Stanford.EDU>
References: <esbffk$922$1@news.Stanford.EDU> <esbspo$l1p$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172952626 11718 128.12.133.106 (3 Mar 2007 20:10:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esbspo$l1p$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12085

Sorry, I should never post when sleepy on a Friday night.
>>
>> I dont understand how there can be 700KB data outstanding and what it 
>> has to do with the window size. I guess I am not setting some TCP
>> header fields correctly but the numbers dont make sense to me. 
> Your numbers were probably backwards, so when you thought your sequence 
> number was 0x00000001 the network layer saw it as 0x8000000000 and so 
> on. Every ACK would have been misinterpreted, etc.

I should have said: 0x00000001 goes to 0x0100000000. The bits aren't 
reversed, just their ordering. Oops!
> 
> This is why they defined a "network byte order". Solaris has the same 
> byte ordering as "network byte order", but linux does not, so you have 
> to use honts and hontl to put it in network byte order.
Also, I meant that it is MACHINE independent (rather than OS). So 
Solaris isn't in "network byte order", it is SPARC that is. And Linux 
isn't in the opposite order, x86 is.

And I mistyped, it is htons and htonl.

Wow, 3 mistakes in one message. Sorry!
.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 3 Mar 2007 15:11:10 -0500
Lines: 90
Distribution: su
Message-ID: <esckp0$blm$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172952673 11958 127.0.0.1 (3 Mar 2007 20:11:13 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12086

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:esci7v$9jr$1@news.Stanford.EDU...
> As to the valgrind issue, it most likely comes from not clearing 
> STCPHead::th_x2.  The STCPHead::th_urp is cleared by the layer below us, 
> but this field is not touched.  I was going to leave it unset because we 
> really do not care.  However, the standard on the net is "Set unused 
> fields to zero, and ignore on reception" because that allows expansion of 
> the protocol most easily.

The thing is that I'm bzero-ing the header or using calloc which makes these 
zero anyway, so I'm assuming that this is just an error that can be ignored 
then.  I just wanted to make sure others are seeing this as to whether I 
should get worried about my code even though I'm not seeing any functional 
errors.

-Seth


"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:esci7v$9jr$1@news.Stanford.EDU...
>I am getting both of these issues even in reliable mode.
>
> As best I can tell, the assert happens sometimes when the other side of 
> the conn exits or terminates while the assert side is in the process of 
> doing something on the network stack.  Usually, I get a SIGPIPE, and 
> everything is hunky dory, but sometimes I get the ASSERT.  I do not think 
> it is a problem with our code; I think it is a problem with the network 
> layer.  However, this has not been confirmed by the TA's
>
> As to the valgrind issue, it most likely comes from not clearing 
> STCPHead::th_x2.  The STCPHead::th_urp is cleared by the layer below us, 
> but this field is not touched.  I was going to leave it unset because we 
> really do not care.  However, the standard on the net is "Set unused 
> fields to zero, and ignore on reception" because that allows expansion of 
> the protocol most easily.
>
> HTH,
> Randy Jennings
>
> The squirrels are your friends!
>
> "Seth Wright" <orion@cs.stanford.edu> wrote in message 
> news:esba73$5qe$1@news.Stanford.EDU...
>> I'm occasionally getting the following error spit out:
>> network_io_socket.c:247: void* network_recv_thread_func(void*): Assertion 
>> `!(fds[1].revents & 0x008)' failed.
>>
>> The error doesn't really even look like something I could be causing. 
>> The offending code is:
>> assert(!(fds[1].revents & POLLERR));
>>
>> And comes from a wait loop for a thread trying to poll the socket for 
>> information and it looks like if an error occurs while polling, the stcp 
>> network implementation just punts rather than try and do anything 
>> graceful. I can't imagine what I'm doing wrong, but I wouldn't rule it 
>> out.  Is anyone else seeing this?
>>
>> Additionally, when I run my code under valgrind I get the following error 
>> for what looks like every STCP datagram I send (here are the results for 
>> when I send a short 50KB file over the client/server program):
>> ==19158== Syscall param write(buf) points to uninitialised byte(s)
>> ==19158==    at 0x4000772: (within /lib/ld-2.3.6.so)
>> ==19158==    by 0x804FA7B: _network_send_packet(network_context_t*, void 
>> const*, unsigned) (network_io_tcp.c:154)
>> ==19158==    by 0x804D885: _network_send(int, void const*, unsigned) 
>> (network.c:46)
>> ==19158==    by 0x804C8F5: stcp_network_send(int, void const*, unsigned, 
>> ...) (stcp_api.c:234)
>> ==19158==    by 0x804AA51: sendACK(int, context_t*) (transport.c:865)
>>
>> Now, my call to stcp_network_send in sendACK looks like this:
>>
>> stcp_network_send(sd,&header,sizeof(STCPHeader),NULL);
>>
>> I followed the code in the stcp source files and it copies the data out 
>> of my passed in pointer immediately, so the fact that header (of type 
>> STCPHeader) is allocated on the stack shouldn't affect anything, but I'm 
>> still baffled.  Everything appears to be working correctly, but when 
>> you're in unreliable mode it can be hard to tell sometimes because it is, 
>> well, unreliable.
>>
>> I'm mostly just wondering if anyone else is running into these problems. 
>> Finally, for both of these, I'm running in unreliable mode.
>>
>> -Seth
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: faq question
Date: Sat, 3 Mar 2007 13:03:33 -0800
Lines: 56
Distribution: su
Message-ID: <escnrh$edv$1@news.Stanford.EDU>
References: <esbtge$ldt$1@news.Stanford.EDU> <esbu88$m1a$1@news.Stanford.EDU> <escgfh$816$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172955825 14783 128.12.197.229 (3 Mar 2007 21:03:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12087

That's what i'm doing but the wording "all pending data has been 
successfully transmitted" does seem to imply waiting for all ACKs to come 
back... at least to me. TAs please confirm if the approach we are taking is 
ok.

Tom


"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:escgfh$816$1@news.Stanford.EDU...
>I read the faq as saying that you should put the FIN in your queue so that 
>it gets sent in order with the data packets, but not that you have to have 
>all data ACKed, just transmitted before you can send the FIN.  i.e. since 
>the FIN takes up one byte you have to follow the receiver window rules as 
>to when you can send a FIN so if you're past the end of the window, but you 
>get a app close event, you don't send the FIN immediately, but rather once 
>you've transmitted all pending data at least once.  At least that's how I 
>understood the semantics.  TAs, any feedback?
>
> -Seth
>
> "Tom Deane" <tdeane@stanford.edu> wrote in message 
> news:esbu88$m1a$1@news.Stanford.EDU...
>> Actually, the same FAQ question tells us that the FIN receiver should 
>> wait until "all expected data from the peer has been passed up to the 
>> application" before calling stcp_fin_received....
>> Again, if we can expect all implementations to follow that behavior, I 
>> don't see why the FIN sender needs to wait until all pending data has 
>> been acked before sending that FIN msg... am I missing something?
>>
>>
>> "Tom Deane" <tdeane@stanford.edu> wrote in message 
>> news:esbtge$ldt$1@news.Stanford.EDU...
>>> The FAQ says: "... 'close requested event' from stcp_wait_for_event(); 
>>> this is your cue to send a FIN segment once all pending data has been 
>>> successfully transmitted. "
>>>
>>> Why do I need to wait until all pending data has been successfully 
>>> tranmistted before sending the FIN?  At least in my implementation of 
>>> STCP, the receiver will not process the FIN if it has not received all 
>>> previous packets in-order (it will just go into the buffer and wait 
>>> there).  Do we have to deal with an implementation of STCP/TCP that 
>>> actually handles a FIN msg (i.e., it calls stcp_fin_received) even when 
>>> the FIN packet is received out-of-order?
>>>
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Weird crash within myread()
Date: Sat, 03 Mar 2007 15:37:18 -0800
Lines: 39
Distribution: su
Message-ID: <esd0qv$kid$1@news.Stanford.EDU>
References: <esblmi$dp0$1@news.Stanford.EDU> <esc85b$8u$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172965023 21069 128.12.194.72 (3 Mar 2007 23:37:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esc85b$8u$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12088

I think I might be calling myread() on the server side of the proxy as 
well. That's probably it. I will ask again if I cannot resolve the problem.

-Yangfan

manj wrote:
> use valgrind to figure out  the source of the problem.
> 
> 
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:esblmi$dp0$1@news.Stanford.EDU...
> 
>>I'm getting this weird assertion failure within myread(). If it's 
>>something that I did, I could use some pointers on how to correct it.
>>
>>#0  0xffffe410 in ?? ()
>>#1  0xbf9666ac in ?? ()
>>#2  0x00000006 in ?? ()
>>#3  0x00000ef3 in ?? ()
>>#4  0xb7cf49a1 in raise () from /lib/tls/i686/cmov/libc.so.6
>>#5  0xb7cf62b9 in abort () from /lib/tls/i686/cmov/libc.so.6
>>#6  0xb7cedf51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
>>#7  0x0804bfd7 in verify_mysocket_descriptor (comp_ctx=0x0, my_sd=7) at 
>>mysock.c:408
>>#8  0x0804c057 in _mysock_get_context (sd=7) at mysock.c:74
>>#9  0x0804b50f in myread (sd=7, buf=0xbf9668eb, buf_len=1) at 
>>mysock_api.c:214
>>#10 0x0804fc58 in myRead (fd=7, buf=0xbf9668eb, count=1) at proxy.c:228
>>#11 0x0804fcda in myReadLine (fd=7, buf=0x8059ef0, maxLen=512) at 
>>proxy.c:268
>>#12 0x0805014e in onGoodRequest (serverFD=7, clientFD=1, 
>>firstLine=0x8058e80 "GET", secondLine=0x8059088 "Host: www.yahoo.com") at 
>>proxy.c:544
>>#13 0x0805073f in main (argc=2, argv=0xbf966a44) at proxy.c:80
>>
>>-Yangfan 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 3 Mar 2007 16:15:43 -0800
Lines: 16
Distribution: su
Message-ID: <esd31s$m1p$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172967292 22585 127.0.0.1 (4 Mar 2007 00:14:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12089

> As best I can tell, the assert happens sometimes when the other side of 
> the conn exits or terminates while the assert side is in the process of 
> doing something on the network stack.  Usually, I get a SIGPIPE, and 
> everything is hunky dory, but sometimes I get the ASSERT.  I do not think 
> it is a problem with our code; I think it is a problem with the network 
> layer.  However, this has not been confirmed by the TA's
The assert failure happens every time I timeout on one side of the 
connection.  I will modify my timeout to be a bit more generous, but it 
seems like this less-than-graceful behavior localized to the network layer.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: restarting timer
Date: Sat, 3 Mar 2007 17:00:31 -0800
Lines: 18
Distribution: su
Message-ID: <esd5np$nq3$1@news.Stanford.EDU>
NNTP-Posting-Host: amdrules.stanford.edu
X-Trace: news.Stanford.EDU 1172970041 24387 128.12.197.229 (4 Mar 2007 01:00:41 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12090

Out of curiosity: which of these two approaches are people taking? is one 
them wrong?

1.) Option 1: Keep a single timer for the first packet in the sender window. 
When you get an ACK, restart this timer.  This means that if 3 packets were 
sent back to back, and you got ACKs for 1 and 2, packet 3 will not timeout 
until 2RTT + RTO from the time it was sent.

2.) Option 2:  Record the time that every packet was sent out.  If you get 
an ACK, the new timeout value would be the time you sent the next unacked 
packet + RTO.  I guess this would be more accurate but there is obviously a 
lot more overhead.

Thanks,
Tom
 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 3 Mar 2007 17:37:31 -0800
Lines: 16
Distribution: su
Message-ID: <esd7r8$p2c$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172972200 25676 127.0.0.1 (4 Mar 2007 01:36:40 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12091

> The assert failure happens every time I timeout on one side of the 
> connection.  I will modify my timeout to be a bit more generous, but it 
> seems like this less-than-graceful behavior localized to the network 
> layer.
It was also happening most times proxyget finished (in reliable mode).

The only way I can get this occurrence to go away is by putting a 10 second 
timer before exiting the thread.  A pretty fragile network layer.  Is anyone 
else seeing this, too?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 3 Mar 2007 17:42:22 -0800
Lines: 20
Distribution: su
Message-ID: <esd84b$p99$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172972491 25897 127.0.0.1 (4 Mar 2007 01:41:31 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12092

Nope, the proxy still shuts down on the assert sometimes.
"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:esd7r8$p2c$1@news.Stanford.EDU...
>> The assert failure happens every time I timeout on one side of the 
>> connection.  I will modify my timeout to be a bit more generous, but it 
>> seems like this less-than-graceful behavior localized to the network 
>> layer.
> It was also happening most times proxyget finished (in reliable mode).
>
> The only way I can get this occurrence to go away is by putting a 10 
> second timer before exiting the thread.  A pretty fragile network layer. 
> Is anyone else seeing this, too?
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: sliding window
Date: Sat, 3 Mar 2007 17:46:01 -0800
Lines: 26
Distribution: su
Message-ID: <esd8cs$pd9$1@news.Stanford.EDU>
References: <Xns98E4E6DBD34DAchunkaiwstanfordedu@171.64.14.103> <es3qb1$flt$2@news.Stanford.EDU> <es52vv$sia$1@news.Stanford.EDU> <es53u3$1t$2@news.Stanford.EDU> <es555h$1f2$1@news.Stanford.EDU> <es5cj9$88v$1@news.Stanford.EDU> <es5nu0$g2q$1@news.Stanford.EDU> <es5rrm$id8$1@news.Stanford.EDU> <es72b0$ni2$1@news.Stanford.EDU> <C20C5809.8D93%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1172972765 26025 127.0.0.1 (4 Mar 2007 01:46:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12093

Do we need to implement this for our assignment? Will this be tested?
If yes, any suggestions on how I can test this?

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C20C5809.8D93%jpettit@stanford.edu...
>>> Good gravy! I believe you just found another TCP exploit! We can open 
>>> TCP
>>> connections and make them lock up! :)
>> Only the really bad ones.  I think you still run the timeouts, but I am 
>> not
>> sure (someone else was asking about that).  In any case, TCP specifies 
>> that
>> at regular intervals, if the window is 0, the TCP connection probes it 
>> with
>> a one byte sequence.  I think the receiver is required to have some slush
>> left over to handle these one byte probes, but I am not sure.
>
> All the books are a little unclear about the contents of this one byte
> probe.  I asked Professor McKeown a couple of days ago, and he said that
> it's not new data, but just the last byte that fit in the window that is
> retransmitted.
>
> --Justin
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: restarting timer
Date: Sat, 3 Mar 2007 18:12:13 -0800
Lines: 24
Distribution: su
Message-ID: <esd9u0$qf3$1@news.Stanford.EDU>
References: <esd5np$nq3$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1172974337 27107 127.0.0.1 (4 Mar 2007 02:12:17 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12094

Can one of the TA's please tell us if Option 1 is acceptable?

"Tom Deane" <tdeane@stanford.edu> wrote in message 
news:esd5np$nq3$1@news.Stanford.EDU...
> Out of curiosity: which of these two approaches are people taking? is one 
> them wrong?
>
> 1.) Option 1: Keep a single timer for the first packet in the sender 
> window. When you get an ACK, restart this timer.  This means that if 3 
> packets were sent back to back, and you got ACKs for 1 and 2, packet 3 
> will not timeout until 2RTT + RTO from the time it was sent.
>
> 2.) Option 2:  Record the time that every packet was sent out.  If you get 
> an ACK, the new timeout value would be the time you sent the next unacked 
> packet + RTO.  I guess this would be more accurate but there is obviously 
> a lot more overhead.
>
> Thanks,
> Tom
>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 4 Mar 2007 03:02:29 +0000 (UTC)
Lines: 35
Distribution: su
Message-ID: <esdcs5$rsb$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1172977349 28555 171.64.15.6 (4 Mar 2007 03:02:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12095


I'm getting following assert message :

server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
unsigned int, const timespec*): Assertion `0' failed.

Line stcp_api.c:107 is :
    106             case EINVAL:
    107                 assert(0);
    108                 break;

Is someone else getting this? What is EINVAL here?


Randy Jennings <randyj@stanford.edu> wrote:
> Nope, the proxy still shuts down on the assert sometimes.
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:esd7r8$p2c$1@news.Stanford.EDU...
> >> The assert failure happens every time I timeout on one side of the 
> >> connection.  I will modify my timeout to be a bit more generous, but it 
> >> seems like this less-than-graceful behavior localized to the network 
> >> layer.
> > It was also happening most times proxyget finished (in reliable mode).
> >
> > The only way I can get this occurrence to go away is by putting a 10 
> > second timer before exiting the thread.  A pretty fragile network layer. 
> > Is anyone else seeing this, too?
> >
> > Sincerely,
> > Randy Jennings
> >
> > The squirrels are your friends!
> > 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 03 Mar 2007 19:20:22 -0800
Lines: 39
Distribution: su
Message-ID: <esddr4$sk6$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esdcs5$rsb$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172978340 29318 127.0.0.1 (4 Mar 2007 03:19:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esdcs5$rsb$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12096

That means the timespec struct you passed in was invalid.

Greg

Dinesh Gupta wrote:
> I'm getting following assert message :
> 
> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
> unsigned int, const timespec*): Assertion `0' failed.
> 
> Line stcp_api.c:107 is :
>     106             case EINVAL:
>     107                 assert(0);
>     108                 break;
> 
> Is someone else getting this? What is EINVAL here?
> 
> 
> Randy Jennings <randyj@stanford.edu> wrote:
>> Nope, the proxy still shuts down on the assert sometimes.
>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
>> news:esd7r8$p2c$1@news.Stanford.EDU...
>>>> The assert failure happens every time I timeout on one side of the 
>>>> connection.  I will modify my timeout to be a bit more generous, but it 
>>>> seems like this less-than-graceful behavior localized to the network 
>>>> layer.
>>> It was also happening most times proxyget finished (in reliable mode).
>>>
>>> The only way I can get this occurrence to go away is by putting a 10 
>>> second timer before exiting the thread.  A pretty fragile network layer. 
>>> Is anyone else seeing this, too?
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> The squirrels are your friends!
>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 4 Mar 2007 03:23:53 +0000 (UTC)
Lines: 43
Distribution: su
Message-ID: <esde49$ssn$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esdcs5$rsb$1@news.Stanford.EDU> <esddr4$sk6$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1172978633 29591 171.64.15.6 (4 Mar 2007 03:23:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12097

Thanks Greg,  but I'm printing this structure and it sounds ok.
Anyways I'll debug it more..

Greg Nelson <grourk@stanford.edu> wrote:
> That means the timespec struct you passed in was invalid.

> Greg

> Dinesh Gupta wrote:
> > I'm getting following assert message :
> > 
> > server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
> > unsigned int, const timespec*): Assertion `0' failed.
> > 
> > Line stcp_api.c:107 is :
> >     106             case EINVAL:
> >     107                 assert(0);
> >     108                 break;
> > 
> > Is someone else getting this? What is EINVAL here?
> > 
> > 
> > Randy Jennings <randyj@stanford.edu> wrote:
> >> Nope, the proxy still shuts down on the assert sometimes.
> >> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> >> news:esd7r8$p2c$1@news.Stanford.EDU...
> >>>> The assert failure happens every time I timeout on one side of the 
> >>>> connection.  I will modify my timeout to be a bit more generous, but it 
> >>>> seems like this less-than-graceful behavior localized to the network 
> >>>> layer.
> >>> It was also happening most times proxyget finished (in reliable mode).
> >>>
> >>> The only way I can get this occurrence to go away is by putting a 10 
> >>> second timer before exiting the thread.  A pretty fragile network layer. 
> >>> Is anyone else seeing this, too?
> >>>
> >>> Sincerely,
> >>> Randy Jennings
> >>>
> >>> The squirrels are your friends!
> >>>
> > 
> > 
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 4 Mar 2007 03:53:31 +0000 (UTC)
Lines: 52
Distribution: su
Message-ID: <esdfrr$ch$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esdcs5$rsb$1@news.Stanford.EDU> <esddr4$sk6$1@news.Stanford.EDU> <esde49$ssn$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1172980411 401 171.64.15.6 (4 Mar 2007 03:53:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12098

Still not able to figure this out:

my cur time is :
cur_time(sec=1172980288,usec=928768)
calling wait_event(sd=1, event=2, (sec=1172980288,nsec=1028675000)

Is there any problem in above data?

Dinesh Gupta <dineshg@stanford.edu> wrote:
> Thanks Greg,  but I'm printing this structure and it sounds ok.
> Anyways I'll debug it more..

> Greg Nelson <grourk@stanford.edu> wrote:
> > That means the timespec struct you passed in was invalid.

> > Greg

> > Dinesh Gupta wrote:
> > > I'm getting following assert message :
> > > 
> > > server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
> > > unsigned int, const timespec*): Assertion `0' failed.
> > > 
> > > Line stcp_api.c:107 is :
> > >     106             case EINVAL:
> > >     107                 assert(0);
> > >     108                 break;
> > > 
> > > Is someone else getting this? What is EINVAL here?
> > > 
> > > 
> > > Randy Jennings <randyj@stanford.edu> wrote:
> > >> Nope, the proxy still shuts down on the assert sometimes.
> > >> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> > >> news:esd7r8$p2c$1@news.Stanford.EDU...
> > >>>> The assert failure happens every time I timeout on one side of the 
> > >>>> connection.  I will modify my timeout to be a bit more generous, but it 
> > >>>> seems like this less-than-graceful behavior localized to the network 
> > >>>> layer.
> > >>> It was also happening most times proxyget finished (in reliable mode).
> > >>>
> > >>> The only way I can get this occurrence to go away is by putting a 10 
> > >>> second timer before exiting the thread.  A pretty fragile network layer. 
> > >>> Is anyone else seeing this, too?
> > >>>
> > >>> Sincerely,
> > >>> Randy Jennings
> > >>>
> > >>> The squirrels are your friends!
> > >>>
> > > 
> > > 
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sat, 03 Mar 2007 20:03:53 -0800
Lines: 58
Distribution: su
Message-ID: <esdgcm$134$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esdcs5$rsb$1@news.Stanford.EDU> <esddr4$sk6$1@news.Stanford.EDU> <esde49$ssn$1@news.Stanford.EDU> <esdfrr$ch$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172980950 1124 127.0.0.1 (4 Mar 2007 04:02:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esdfrr$ch$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12099

I believe the tv_nsec field cannot be more than 1 billion.  You'll want 
to add one to the tv_sec field and subtract a billion from the tv_nsec 
field.

Greg

Dinesh Gupta wrote:
> Still not able to figure this out:
> 
> my cur time is :
> cur_time(sec=1172980288,usec=928768)
> calling wait_event(sd=1, event=2, (sec=1172980288,nsec=1028675000)
> 
> Is there any problem in above data?
> 
> Dinesh Gupta <dineshg@stanford.edu> wrote:
>> Thanks Greg,  but I'm printing this structure and it sounds ok.
>> Anyways I'll debug it more..
> 
>> Greg Nelson <grourk@stanford.edu> wrote:
>>> That means the timespec struct you passed in was invalid.
> 
>>> Greg
> 
>>> Dinesh Gupta wrote:
>>>> I'm getting following assert message :
>>>>
>>>> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
>>>> unsigned int, const timespec*): Assertion `0' failed.
>>>>
>>>> Line stcp_api.c:107 is :
>>>>     106             case EINVAL:
>>>>     107                 assert(0);
>>>>     108                 break;
>>>>
>>>> Is someone else getting this? What is EINVAL here?
>>>>
>>>>
>>>> Randy Jennings <randyj@stanford.edu> wrote:
>>>>> Nope, the proxy still shuts down on the assert sometimes.
>>>>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
>>>>> news:esd7r8$p2c$1@news.Stanford.EDU...
>>>>>>> The assert failure happens every time I timeout on one side of the 
>>>>>>> connection.  I will modify my timeout to be a bit more generous, but it 
>>>>>>> seems like this less-than-graceful behavior localized to the network 
>>>>>>> layer.
>>>>>> It was also happening most times proxyget finished (in reliable mode).
>>>>>>
>>>>>> The only way I can get this occurrence to go away is by putting a 10 
>>>>>> second timer before exiting the thread.  A pretty fragile network layer. 
>>>>>> Is anyone else seeing this, too?
>>>>>>
>>>>>> Sincerely,
>>>>>> Randy Jennings
>>>>>>
>>>>>> The squirrels are your friends!
>>>>>>
>>>>
.

Path: shelby.stanford.edu!not-for-mail
From: Matt Page <mpage@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ACK Behavior
Date: Sat, 03 Mar 2007 20:21:48 -0800
Lines: 14
Distribution: su
Message-ID: <esdhgs$1s5$1@news.Stanford.EDU>
NNTP-Posting-Host: wanderlust.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1172982109 1925 128.12.104.61 (4 Mar 2007 04:21:49 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5 (X11/20060313)
Xref: shelby.stanford.edu su.class.cs244a:12100

Since TCP has cumulative ACKs, what should we do if we get a pure ACK 
for something in the middle of our window?

That is, suppose the other side has a receive window of 3072 bytes. We 
send out 2k bytes and get back an ACK for byte 1001. Can we assume that 
the first 1k bytes we sent were ACKd? (Even though they were sent in 
discrete packets.)

It seems like we should, since most TCP stacks will wait to send out
ACKs until there is data ready to be sent.


Thanks,
Matt
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 4 Mar 2007 09:15:54 +0000 (UTC)
Lines: 61
Distribution: su
Message-ID: <ese2oa$e7d$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esdcs5$rsb$1@news.Stanford.EDU> <esddr4$sk6$1@news.Stanford.EDU> <esde49$ssn$1@news.Stanford.EDU> <esdfrr$ch$1@news.Stanford.EDU> <esdgcm$134$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1172999754 14573 171.64.15.6 (4 Mar 2007 09:15:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12101

Thanks Greg, this makes sense.

Greg Nelson <grourk@stanford.edu> wrote:
> I believe the tv_nsec field cannot be more than 1 billion.  You'll want 
> to add one to the tv_sec field and subtract a billion from the tv_nsec 
> field.

> Greg

> Dinesh Gupta wrote:
> > Still not able to figure this out:
> > 
> > my cur time is :
> > cur_time(sec=1172980288,usec=928768)
> > calling wait_event(sd=1, event=2, (sec=1172980288,nsec=1028675000)
> > 
> > Is there any problem in above data?
> > 
> > Dinesh Gupta <dineshg@stanford.edu> wrote:
> >> Thanks Greg,  but I'm printing this structure and it sounds ok.
> >> Anyways I'll debug it more..
> > 
> >> Greg Nelson <grourk@stanford.edu> wrote:
> >>> That means the timespec struct you passed in was invalid.
> > 
> >>> Greg
> > 
> >>> Dinesh Gupta wrote:
> >>>> I'm getting following assert message :
> >>>>
> >>>> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t,
> >>>> unsigned int, const timespec*): Assertion `0' failed.
> >>>>
> >>>> Line stcp_api.c:107 is :
> >>>>     106             case EINVAL:
> >>>>     107                 assert(0);
> >>>>     108                 break;
> >>>>
> >>>> Is someone else getting this? What is EINVAL here?
> >>>>
> >>>>
> >>>> Randy Jennings <randyj@stanford.edu> wrote:
> >>>>> Nope, the proxy still shuts down on the assert sometimes.
> >>>>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> >>>>> news:esd7r8$p2c$1@news.Stanford.EDU...
> >>>>>>> The assert failure happens every time I timeout on one side of the 
> >>>>>>> connection.  I will modify my timeout to be a bit more generous, but it 
> >>>>>>> seems like this less-than-graceful behavior localized to the network 
> >>>>>>> layer.
> >>>>>> It was also happening most times proxyget finished (in reliable mode).
> >>>>>>
> >>>>>> The only way I can get this occurrence to go away is by putting a 10 
> >>>>>> second timer before exiting the thread.  A pretty fragile network layer. 
> >>>>>> Is anyone else seeing this, too?
> >>>>>>
> >>>>>> Sincerely,
> >>>>>> Randy Jennings
> >>>>>>
> >>>>>> The squirrels are your friends!
> >>>>>>
> >>>>
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 04 Mar 2007 02:36:37 -0800
Lines: 50
Distribution: su
Message-ID: <ese7d1$h7h$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173004513 17649 127.0.0.1 (4 Mar 2007 10:35:13 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esba73$5qe$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12102

I'm seeing this a lot too.  It definitely occurs when the other side of 
the connection has already closed, but it's annoyingly intermittent.

Greg

Seth Wright wrote:
> I'm occasionally getting the following error spit out:
> network_io_socket.c:247: void* network_recv_thread_func(void*): Assertion 
> `!(fds[1].revents & 0x008)' failed.
> 
> The error doesn't really even look like something I could be causing.  The 
> offending code is:
> assert(!(fds[1].revents & POLLERR));
> 
> And comes from a wait loop for a thread trying to poll the socket for 
> information and it looks like if an error occurs while polling, the stcp 
> network implementation just punts rather than try and do anything graceful. 
> I can't imagine what I'm doing wrong, but I wouldn't rule it out.  Is anyone 
> else seeing this?
> 
> Additionally, when I run my code under valgrind I get the following error 
> for what looks like every STCP datagram I send (here are the results for 
> when I send a short 50KB file over the client/server program):
> ==19158== Syscall param write(buf) points to uninitialised byte(s)
> ==19158==    at 0x4000772: (within /lib/ld-2.3.6.so)
> ==19158==    by 0x804FA7B: _network_send_packet(network_context_t*, void 
> const*, unsigned) (network_io_tcp.c:154)
> ==19158==    by 0x804D885: _network_send(int, void const*, unsigned) 
> (network.c:46)
> ==19158==    by 0x804C8F5: stcp_network_send(int, void const*, unsigned, 
> ...) (stcp_api.c:234)
> ==19158==    by 0x804AA51: sendACK(int, context_t*) (transport.c:865)
> 
> Now, my call to stcp_network_send in sendACK looks like this:
> 
> stcp_network_send(sd,&header,sizeof(STCPHeader),NULL);
> 
> I followed the code in the stcp source files and it copies the data out of 
> my passed in pointer immediately, so the fact that header (of type 
> STCPHeader) is allocated on the stack shouldn't affect anything, but I'm 
> still baffled.  Everything appears to be working correctly, but when you're 
> in unreliable mode it can be hard to tell sometimes because it is, well, 
> unreliable.
> 
> I'm mostly just wondering if anyone else is running into these problems. 
> Finally, for both of these, I'm running in unreliable mode.
> 
> -Seth 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: window size in header
Date: Sun, 4 Mar 2007 11:24:24 +0000 (UTC)
Organization: Your Company
Lines: 3
Distribution: su
Message-ID: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173007464 17962 128.12.22.217 (4 Mar 2007 11:24:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12103

just to clarify with respect to window size.

in stcp, the window size in the TCP header should always be 3072 right?
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: restarting timer
Date: Sun, 04 Mar 2007 03:45:39 -0800
Lines: 35
Distribution: su
Message-ID: <esebgj$khf$1@news.Stanford.EDU>
References: <esd5np$nq3$1@news.Stanford.EDU> <esd9u0$qf3$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173008724 21039 128.12.194.72 (4 Mar 2007 11:45:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esd9u0$qf3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12104

I seem to recall one of the TAs telling me that option 1 was okay. I'm 
not sure though, and I don't want to put words in their mouths. :)

Option 1 was the method described in Kurose as well, so I don't 
personally see why it would be a problem.

-Yangfan

Riju Kallivalappil wrote:
> Can one of the TA's please tell us if Option 1 is acceptable?
> 
> "Tom Deane" <tdeane@stanford.edu> wrote in message 
> news:esd5np$nq3$1@news.Stanford.EDU...
> 
>>Out of curiosity: which of these two approaches are people taking? is one 
>>them wrong?
>>
>>1.) Option 1: Keep a single timer for the first packet in the sender 
>>window. When you get an ACK, restart this timer.  This means that if 3 
>>packets were sent back to back, and you got ACKs for 1 and 2, packet 3 
>>will not timeout until 2RTT + RTO from the time it was sent.
>>
>>2.) Option 2:  Record the time that every packet was sent out.  If you get 
>>an ACK, the new timeout value would be the time you sent the next unacked 
>>packet + RTO.  I guess this would be more accurate but there is obviously 
>>a lot more overhead.
>>
>>Thanks,
>>Tom
>>
>>
>>
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Ray Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: window size in header
Date: Sun, 04 Mar 2007 06:04:00 -0800
Lines: 15
Distribution: su
Message-ID: <esejkh$s3f$1@news.Stanford.EDU>
References: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173017041 28783 127.0.0.1 (4 Mar 2007 14:04:01 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12105

Chun Kai Wang wrote:
> just to clarify with respect to window size.
> 
> in stcp, the window size in the TCP header should always be 3072 right?

 From my understanding, the window size advertised from *your* implementation of 
STCP should always be 3072.

But be aware: your STCP may interact with other STCP implementations, whose 
windows may be of different size, and thus, they'd advertise something other 
than a 3072 window size in their headers.

Hope this helps.

- Ray
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: window size in header
Date: Sun, 4 Mar 2007 19:20:08 +0000 (UTC)
Organization: Your Company
Lines: 37
Distribution: su
Message-ID: <Xns98E973516101Fchunkaiwstanfordedu@171.64.14.103>
References: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103> <esejkh$s3f$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173036008 11251 128.12.22.217 (4 Mar 2007 19:20:08 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12106

So in our implementation of STCP, say, my incomming buffer has 3000 
bytes worth of data that cannot be properly ack-ed because the first 
byte is missing.

when i receive a data packet from a host, should i still use 3072 as the 
window size in my TCP header? or should i use 3072-3000???

that's the part i'm confused about...







Ray Thang <rlt5654@stanford.edu> wrote in
news:esejkh$s3f$1@news.Stanford.EDU: 

> Chun Kai Wang wrote:
>> just to clarify with respect to window size.
>> 
>> in stcp, the window size in the TCP header should always be 3072
>> right? 
> 
>  From my understanding, the window size advertised from *your*
>  implementation of 
> STCP should always be 3072.
> 
> But be aware: your STCP may interact with other STCP implementations,
> whose windows may be of different size, and thus, they'd advertise
> something other than a 3072 window size in their headers.
> 
> Hope this helps.
> 
> - Ray
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: window size in header
Date: Sun, 4 Mar 2007 12:30:48 -0800
Lines: 48
Distribution: su
Message-ID: <esfa9t$eb9$1@news.Stanford.EDU>
References: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103> <esejkh$s3f$1@news.Stanford.EDU> <Xns98E973516101Fchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1173040253 14697 127.0.0.1 (4 Mar 2007 20:30:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:12107

I believe that you still use 3072, and that it is the responsibility of 
the sender to know that it has 3000 unACKed bytes of data in the open 
that you are potentially buffering. In any event, you will start 
dropping bytes past 3072, and the sender will resend whatever data you 
drop until you give it an ACK, so I think it'll sort itself out 
eventually even if one of the implementations is misbehaving with 
regards to window sizes.




On 2007-03-04 11:20:08 -0800, Chun Kai Wang <chunkaiw@stanford.edu> said:

> So in our implementation of STCP, say, my incomming buffer has 3000 
> bytes worth of data that cannot be properly ack-ed because the first 
> byte is missing.
> 
> when i receive a data packet from a host, should i still use 3072 as 
> the window size in my TCP header? or should i use 3072-3000???
> 
> that's the part i'm confused about...
> 
> 
> 
> 
> 
> 
> 
> Ray Thang <rlt5654@stanford.edu> wrote in
> news:esejkh$s3f$1@news.Stanford.EDU:
>> Chun Kai Wang wrote:
>>> just to clarify with respect to window size.
>>> 
>>> in stcp, the window size in the TCP header should always be 3072
>>> right?
>> 
>> From my understanding, the window size advertised from *your*
>> implementation of STCP should always be 3072.
>> 
>> But be aware: your STCP may interact with other STCP implementations,
>> whose windows may be of different size, and thus, they'd advertise
>> something other than a 3072 window size in their headers.
>> 
>> Hope this helps.
>> 
>> - Ray


.

Path: shelby.stanford.edu!not-for-mail
From: Adam Cohen <adam.cohen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: APP_CLOSE_REQUESTED && APP_DATA
Date: Sun, 4 Mar 2007 12:33:47 -0800
Lines: 18
Distribution: su
Message-ID: <esfaff$ekv$1@news.Stanford.EDU>
References: <escjmm$ao8$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.Stanford.EDU 1173040431 15007 127.0.0.1 (4 Mar 2007 20:33:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Unison/1.7.5
Xref: shelby.stanford.edu su.class.cs244a:12108

You could just have a much bigger app-data buffer than 3072. there's no 
particular reason to lock it to that value (unless it's a rule that I'm 
missing).

On 2007-03-03 11:53:46 -0800, "Randy Jennings" <randyj@stanford.edu> said:

> I just got an idea that could cause problems (though not with the a/b 
> grading script, I think).
> 
> Can we get APP_CLOSE_REQUESTED and APP_DATA both set on the return from 
> stcp_wait_for_event?
> 
> This is the scenario I envision:
> I start with our rxWin completely unused.
> The app does a write of 3073 bytes and then closes the connection.
> I get these two flags set.


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: window size in header
Date: Sun, 4 Mar 2007 21:39:32 +0000 (UTC)
Organization: Your Company
Lines: 64
Distribution: su
Message-ID: <Xns98E98AF31BFCAchunkaiwstanfordedu@171.64.14.103>
References: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103> <esejkh$s3f$1@news.Stanford.EDU> <Xns98E973516101Fchunkaiwstanfordedu@171.64.14.103> <esfa9t$eb9$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173044372 17690 128.12.22.217 (4 Mar 2007 21:39:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12109

sounds reasonable. cool. thanks.







Adam Cohen <adam.cohen@stanford.edu> wrote in news:esfa9t$eb9$1
@news.Stanford.EDU:

> I believe that you still use 3072, and that it is the responsibility 
of 
> the sender to know that it has 3000 unACKed bytes of data in the open 
> that you are potentially buffering. In any event, you will start 
> dropping bytes past 3072, and the sender will resend whatever data you 
> drop until you give it an ACK, so I think it'll sort itself out 
> eventually even if one of the implementations is misbehaving with 
> regards to window sizes.
> 
> 
> 
> 
> On 2007-03-04 11:20:08 -0800, Chun Kai Wang <chunkaiw@stanford.edu> 
said:
> 
>> So in our implementation of STCP, say, my incomming buffer has 3000 
>> bytes worth of data that cannot be properly ack-ed because the first 
>> byte is missing.
>> 
>> when i receive a data packet from a host, should i still use 3072 as 
>> the window size in my TCP header? or should i use 3072-3000???
>> 
>> that's the part i'm confused about...
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Ray Thang <rlt5654@stanford.edu> wrote in
>> news:esejkh$s3f$1@news.Stanford.EDU:
>>> Chun Kai Wang wrote:
>>>> just to clarify with respect to window size.
>>>> 
>>>> in stcp, the window size in the TCP header should always be 3072
>>>> right?
>>> 
>>> From my understanding, the window size advertised from *your*
>>> implementation of STCP should always be 3072.
>>> 
>>> But be aware: your STCP may interact with other STCP 
implementations,
>>> whose windows may be of different size, and thus, they'd advertise
>>> something other than a 3072 window size in their headers.
>>> 
>>> Hope this helps.
>>> 
>>> - Ray
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: faq question
Date: Sun, 04 Mar 2007 13:47:57 -0800
Lines: 59
Distribution: su
Message-ID: <esfeqf$hhv$1@news.Stanford.EDU>
References: <esbtge$ldt$1@news.Stanford.EDU> <esbu88$m1a$1@news.Stanford.EDU> <escgfh$816$1@news.Stanford.EDU> <escnrh$edv$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173044879 17983 128.12.133.106 (4 Mar 2007 21:47:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <escnrh$edv$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12110

Just treat the FIN packet as a normal byte to be sent. It counts as a 
single byte in the stream and treat it as such. So you don't have to 
have all the data ACKed before you send it.

Tom Deane wrote:
> That's what i'm doing but the wording "all pending data has been 
> successfully transmitted" does seem to imply waiting for all ACKs to come 
> back... at least to me. TAs please confirm if the approach we are taking is 
> ok.
> 
> Tom
> 
> 
> "Seth Wright" <orion@cs.stanford.edu> wrote in message 
> news:escgfh$816$1@news.Stanford.EDU...
>> I read the faq as saying that you should put the FIN in your queue so that 
>> it gets sent in order with the data packets, but not that you have to have 
>> all data ACKed, just transmitted before you can send the FIN.  i.e. since 
>> the FIN takes up one byte you have to follow the receiver window rules as 
>> to when you can send a FIN so if you're past the end of the window, but you 
>> get a app close event, you don't send the FIN immediately, but rather once 
>> you've transmitted all pending data at least once.  At least that's how I 
>> understood the semantics.  TAs, any feedback?
>>
>> -Seth
>>
>> "Tom Deane" <tdeane@stanford.edu> wrote in message 
>> news:esbu88$m1a$1@news.Stanford.EDU...
>>> Actually, the same FAQ question tells us that the FIN receiver should 
>>> wait until "all expected data from the peer has been passed up to the 
>>> application" before calling stcp_fin_received....
>>> Again, if we can expect all implementations to follow that behavior, I 
>>> don't see why the FIN sender needs to wait until all pending data has 
>>> been acked before sending that FIN msg... am I missing something?
>>>
>>>
>>> "Tom Deane" <tdeane@stanford.edu> wrote in message 
>>> news:esbtge$ldt$1@news.Stanford.EDU...
>>>> The FAQ says: "... 'close requested event' from stcp_wait_for_event(); 
>>>> this is your cue to send a FIN segment once all pending data has been 
>>>> successfully transmitted. "
>>>>
>>>> Why do I need to wait until all pending data has been successfully 
>>>> tranmistted before sending the FIN?  At least in my implementation of 
>>>> STCP, the receiver will not process the FIN if it has not received all 
>>>> previous packets in-order (it will just go into the buffer and wait 
>>>> there).  Do we have to deal with an implementation of STCP/TCP that 
>>>> actually handles a FIN msg (i.e., it calls stcp_fin_received) even when 
>>>> the FIN packet is received out-of-order?
>>>>
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>>
>>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: FIN bit with data
Date: Sun, 04 Mar 2007 13:49:12 -0800
Lines: 4
Distribution: su
Message-ID: <esfesq$hhv$2@news.Stanford.EDU>
References: <esciia$9th$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173044954 17983 128.12.133.106 (4 Mar 2007 21:49:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esciia$9th$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12111

> Does the grading script correctly handle the case when the FIN bit is sent 
> in a data packet?
Yes. If you don't think it does, send me the code in question and I'll 
run the script on it and send you back the packet log as well.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: APP_CLOSE_REQUESTED && APP_DATA
Date: Sun, 04 Mar 2007 13:51:45 -0800
Lines: 15
Distribution: su
Message-ID: <esff1i$hhv$3@news.Stanford.EDU>
References: <escjmm$ao8$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173045106 17983 128.12.133.106 (4 Mar 2007 21:51:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <escjmm$ao8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12112

> Can we get APP_CLOSE_REQUESTED and APP_DATA both set on the return from 
> stcp_wait_for_event?
Test it out. I'm unsure of the internal workings. Just write a small c 
program:

int main() {
	int s = mysocket(...);
	char data[3073];
	memset(data, 42, 3073);
	mywrite(s, data, 3073);
	printf("Written data");
	myclose(s);
}

Or something like that.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: restarting timer
Date: Sun, 04 Mar 2007 13:57:13 -0800
Lines: 16
Distribution: su
Message-ID: <esffbr$htj$1@news.Stanford.EDU>
References: <esd5np$nq3$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173045435 18355 128.12.133.106 (4 Mar 2007 21:57:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esd5np$nq3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12113

> 1.) Option 1: Keep a single timer for the first packet in the sender window. 
> When you get an ACK, restart this timer.  This means that if 3 packets were 
> sent back to back, and you got ACKs for 1 and 2, packet 3 will not timeout 
> until 2RTT + RTO from the time it was sent.
Please don't do this way. We want to know if certain packets get lost in 
the network, not just if the network is down. Just add a time field into 
the data structure that you put into your queue and check that one. You 
can assume that the packets were sent (by your STCP) in order, so the 
first one to timeout would be the leftmost queue entry.
> 
> 2.) Option 2:  Record the time that every packet was sent out.  If you get 
> an ACK, the new timeout value would be the time you sent the next unacked 
> packet + RTO.  I guess this would be more accurate but there is obviously a 
> lot more overhead.
There isn't much overhead at all. It is just the leftmost entry in the 
queue, since the times are in increasing order.
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ACK Behavior
Date: Sun, 04 Mar 2007 13:57:46 -0800
Lines: 16
Distribution: su
Message-ID: <esffcr$htj$2@news.Stanford.EDU>
References: <esdhgs$1s5$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173045468 18355 128.12.133.106 (4 Mar 2007 21:57:48 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esdhgs$1s5$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12114

Matt Page wrote:
> Since TCP has cumulative ACKs, what should we do if we get a pure ACK 
> for something in the middle of our window?
> 
> That is, suppose the other side has a receive window of 3072 bytes. We 
> send out 2k bytes and get back an ACK for byte 1001. Can we assume that 
> the first 1k bytes we sent were ACKd? (Even though they were sent in 
> discrete packets.)
Yes.
> 
> It seems like we should, since most TCP stacks will wait to send out
> ACKs until there is data ready to be sent.
> 
> 
> Thanks,
> Matt
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: window size in header
Date: Sun, 04 Mar 2007 13:59:57 -0800
Lines: 11
Distribution: su
Message-ID: <esffgv$htj$3@news.Stanford.EDU>
References: <Xns98E922A95FC6Echunkaiwstanfordedu@171.64.14.103> <esejkh$s3f$1@news.Stanford.EDU> <Xns98E973516101Fchunkaiwstanfordedu@171.64.14.103> <esfa9t$eb9$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173045599 18355 128.12.133.106 (4 Mar 2007 21:59:59 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esfa9t$eb9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12115

Adam Cohen wrote:
> I believe that you still use 3072, and that it is the responsibility of 
> the sender to know that it has 3000 unACKed bytes of data in the open 
> that you are potentially buffering. In any event, you will start 
> dropping bytes past 3072, and the sender will resend whatever data you 
> drop until you give it an ACK, so I think it'll sort itself out 
> eventually even if one of the implementations is misbehaving with 
> regards to window sizes.
Correct. Whatever you advertise, you are only responsible for dealing 
with that much data. Anything past that window size, can and SHOULD be 
dropped by you.
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: packet overlap
Date: Sun, 4 Mar 2007 22:27:35 +0000 (UTC)
Organization: Your Company
Lines: 13
Distribution: su
Message-ID: <Xns98E99317EA9D8chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173047255 19411 128.12.22.217 (4 Mar 2007 22:27:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12116

can i assume that packets i receive do not overlap?

basically, i can assume i will NOT get this:

Packet 1: seq 100, length = 100
Packet 2: seq 99, length 200

right? since suppose i have to add packet 1 into my incomming buffer, since 
it is out of order, then if i receive packet 2, this will make my Insert 
function very complicated, since i can't just compare seq #.


thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: CLOSE_WAIT (received client's FIN)
Date: Sun, 4 Mar 2007 14:38:01 -0800
Lines: 10
Distribution: su
Message-ID: <esfhob$jg4$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1173047884 19972 128.12.83.54 (4 Mar 2007 22:38:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12117

In the case where we receive a FIN from the other side but we haven't sent 
one ourselves, what happens if the application on our side is not done 
sending data?  For example, if we are the server, the client sends its 
request and sends a FIN, and then we are expected to send all the data the 
client requested and then send the FIN?  How do we know when the application 
is done sending data?

--Alicia 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: APP_CLOSE_REQUESTED && APP_DATA
Date: Sun, 4 Mar 2007 17:53:28 -0500
Lines: 47
Distribution: su
Message-ID: <esfil8$k8e$1@news.Stanford.EDU>
References: <escjmm$ao8$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173048808 20750 127.0.0.1 (4 Mar 2007 22:53:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12118

In this case, though, wouldn't the app basically get told that the write 
only consumed 3072 bytes?  In which case, if they aren't checking the return 
value and just closing the socket and then wondering why not all 3073 bytes 
got sent it's really their problem?  The only way I can see for them to push 
data after a close requested would be to do:
write
close
write

which is wrong.  Additionally, if the OS (or in this case the stcp piece 
talking to us) is changing the order in which these notifications come in, 
isn't that a bug in the OS?  Basically, I just feel like if the semantics 
are to stop reading data from the app once it issues a close, the OS HAS to 
give us the app close requested event in the right order otherwise we can't 
do our job properly.

Just my 2 cents,
-Seth

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:escjmm$ao8$1@news.Stanford.EDU...
>I just got an idea that could cause problems (though not with the a/b 
>grading script, I think).
>
> Can we get APP_CLOSE_REQUESTED and APP_DATA both set on the return from 
> stcp_wait_for_event?
>
> This is the scenario I envision:
> I start with our rxWin completely unused.
> The app does a write of 3073 bytes and then closes the connection.
> I get these two flags set.
> I read 3072 bytes from the app and then record the sequence number of the 
> FIN bit.
> I shut of looking for APP_DATA and APP_CLOSE_REQUESTED, thus ignoring the 
> last byte of app data.
>
> Now, I do not think this can happen because (AIR) the apps mywrite call 
> blocks, preventing the myclose call from executing, but I am not sure.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: restarting timer
Date: Sun, 4 Mar 2007 18:00:28 -0500
Lines: 59
Distribution: su
Message-ID: <esfj2c$kia$1@news.Stanford.EDU>
References: <esd5np$nq3$1@news.Stanford.EDU> <esd9u0$qf3$1@news.Stanford.EDU> <esebgj$khf$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173049228 21066 127.0.0.1 (4 Mar 2007 23:00:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12119

I think the assignment says you can do timeouts however you wish - you just 
have to document the way you're doing it in the README.  From the 
retransmissions section, first bullet point:
"You may implement the timeout as you desire--e.g. a fixed timeout, the 
Karn-Partridge algorithm, etc. Whatever works for you. Note that a fixed RTO 
may not be sufficient--we strongly suggest that you implement RTT estimation 
in some form. (This is only a few lines of code)."

That said, if you are going to do what's recommended (RTT estimation) it 
would probably make the most sense to just do the estimation as described in 
the book, etc.  My recollection of what was in the book was more along the 
lines of each datagram having a timeout value associated with it, etc. 
Besides, how would you accurately estimate the RTTs of successful packets if 
you're not storing some sort of last sent time for each one?  I guess the 
overhead, ease, etc for how this goes is associated to your output buffer 
style (either a straight data buffer or a queue of outgoing datagrams, etc).

I guess that's just a long winded way of saying I'm doing option 2 (god 
knows if I've done it right, though).

-Seth

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:esebgj$khf$1@news.Stanford.EDU...
>I seem to recall one of the TAs telling me that option 1 was okay. I'm not 
>sure though, and I don't want to put words in their mouths. :)
>
> Option 1 was the method described in Kurose as well, so I don't personally 
> see why it would be a problem.
>
> -Yangfan
>
> Riju Kallivalappil wrote:
>> Can one of the TA's please tell us if Option 1 is acceptable?
>>
>> "Tom Deane" <tdeane@stanford.edu> wrote in message 
>> news:esd5np$nq3$1@news.Stanford.EDU...
>>
>>>Out of curiosity: which of these two approaches are people taking? is one 
>>>them wrong?
>>>
>>>1.) Option 1: Keep a single timer for the first packet in the sender 
>>>window. When you get an ACK, restart this timer.  This means that if 3 
>>>packets were sent back to back, and you got ACKs for 1 and 2, packet 3 
>>>will not timeout until 2RTT + RTO from the time it was sent.
>>>
>>>2.) Option 2:  Record the time that every packet was sent out.  If you 
>>>get an ACK, the new timeout value would be the time you sent the next 
>>>unacked packet + RTO.  I guess this would be more accurate but there is 
>>>obviously a lot more overhead.
>>>
>>>Thanks,
>>>Tom
>>>
>>>
>>>
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: CLOSE_WAIT (received client's FIN)
Date: Sun, 4 Mar 2007 18:12:17 -0500
Lines: 22
Distribution: su
Message-ID: <esfjog$l17$1@news.Stanford.EDU>
References: <esfhob$jg4$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173049936 21543 127.0.0.1 (4 Mar 2007 23:12:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12120

Look at AP_CLOSE_REQUESTED, as well as the TCP RFC for FINs as well as the 
various newsgroup threads about FINs.  Basically, a FIN just means that the 
side that sent it will not be sending more data, but does not restrict the 
other side from sending more data.  Additionally, FINs consume one byte of 
the data stream and should be sent in order with the other bytes in the 
stream.

-Seth

"Alicia Chen" <achen530@stanford.edu> wrote in message 
news:esfhob$jg4$1@news.Stanford.EDU...
> In the case where we receive a FIN from the other side but we haven't sent 
> one ourselves, what happens if the application on our side is not done 
> sending data?  For example, if we are the server, the client sends its 
> request and sends a FIN, and then we are expected to send all the data the 
> client requested and then send the FIN?  How do we know when the 
> application is done sending data?
>
> --Alicia
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: packet drop
Date: Sun, 4 Mar 2007 23:30:40 +0000 (UTC)
Organization: Your Company
Lines: 5
Distribution: su
Message-ID: <Xns98E99DCA1C665chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173051040 22252 128.12.22.217 (4 Mar 2007 23:30:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12121

what if a syn packet is dropped?

what if a fin packet is dropped?

in both cases, do i re-try 5x's?
.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet overlap
Date: Sun, 4 Mar 2007 16:47:18 -0800
Lines: 26
Distribution: su
Message-ID: <esfpar$ob7$1@news.Stanford.EDU>
References: <Xns98E99317EA9D8chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1173055643 24935 128.12.81.44 (5 Mar 2007 00:47:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12122

I'm going to guess that is a possible packet sequence. Why will it make your 
insert function complicated? When you receive packet 2, just copy the whole 
thing to your receive buffer. You will overwrite bytes [100,200] with the 
same values but this is ok right?

-- 
David Gobaud

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98E99317EA9D8chunkaiwstanfordedu@171.64.14.103...
> can i assume that packets i receive do not overlap?
>
> basically, i can assume i will NOT get this:
>
> Packet 1: seq 100, length = 100
> Packet 2: seq 99, length 200
>
> right? since suppose i have to add packet 1 into my incomming buffer, 
> since
> it is out of order, then if i receive packet 2, this will make my Insert
> function very complicated, since i can't just compare seq #.
>
>
> thanks. 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: retransmission failure
Date: Mon, 5 Mar 2007 00:53:11 +0000 (UTC)
Organization: Your Company
Lines: 9
Distribution: su
Message-ID: <Xns98E9ABC74E79Bchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173055991 25210 128.12.22.217 (5 Mar 2007 00:53:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12123

suppose i have 1000 packet queued up in the retransmission queue.

suppose acks for packet 100, 200, 300, 400, 500 are all dropped, thus we 
have 5 retranmissions for packet# 500 and greater.

in this case, do we declare a failure of network due to more than 5 
retransmitts for the 1000th packet? since everytime we retransmit, we 
retransmit everything, so the chance that 1000th packet is retransmitted 
more than 5 times is extremely high. 
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet overlap
Date: Mon, 5 Mar 2007 00:55:55 +0000 (UTC)
Organization: Your Company
Lines: 38
Distribution: su
Message-ID: <Xns98E9AC3E1540chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E99317EA9D8chunkaiwstanfordedu@171.64.14.103> <esfpar$ob7$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173056155 25210 128.12.22.217 (5 Mar 2007 00:55:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12124

it's complicated because my incomming buffer structure is a linklist. if 
u allow those packet sequence, u'll have a case where adding a packet 
might delete all other entries in that incomming buffer. 

such is the case when:

pakcet 1, seq 1, len 1
pakcet 2, seq 2, len 1
pakcet 3, seq 3, len 1
pakcet 4, seq 4, len 1
pakcet 5, seq 5, len 1
pakcet 6, seq 6, len 1
pakcet 7, seq 7, len 1
pakcet 8, seq 8, len 1
packet 9, seq 1, len 20

so when packet 9 comes, u delete packets 1-8 from the buffer...


basically, ti's complicated cuz there are alot of cases. what if it's 
not a full overlap? partial overlap on either ends?








"David Gobaud" <gobaudd@stanford.edu> wrote in
news:esfpar$ob7$1@news.Stanford.EDU: 

> I'm going to guess that is a possible packet sequence. Why will it
> make your insert function complicated? When you receive packet 2, just
> copy the whole thing to your receive buffer. You will overwrite bytes
> [100,200] with the same values but this is ok right?
> 

.

Path: shelby.stanford.edu!paun
From: Filip Paun <paun@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Failed Assertion
Date: Sun, 04 Mar 2007 17:03:34 -0800
Lines: 10
Distribution: su
Message-ID: <paun-46D856.17033404032007@nntp.stanford.edu>
NNTP-Posting-Host: zosomac.stanford.edu
X-Trace: news.Stanford.EDU 1173056617 25567 128.12.135.184 (5 Mar 2007 01:03:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: MT-NewsWatcher/3.5.2 (Intel Mac OS X)
Xref: shelby.stanford.edu su.class.cs244a:12125


I am getting the following failed assertion.  Did anybody else have 
problems with this one?

server: network_io_socket.c:247: void* network_recv_thread_func(void*): 
Assertion `!(fds[1].revents & 0x008)' failed.

Any input would be appreciated.

Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: fin packet
Date: Mon, 5 Mar 2007 02:15:57 +0000 (UTC)
Organization: Your Company
Lines: 21
Distribution: su
Message-ID: <Xns98E9B9CFE37EFchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173060957 28126 128.12.22.217 (5 Mar 2007 02:15:57 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12126

suppose i have:

Packet 1: seq 1, len 9
Packet 2: seq 10, len 1 => fin packet


suppose i send both to the client, but packet1 is dropped. what happens? 
what is the correct behavior?

i think there are 2 things we can do.

1.) do not send packet 2 until seq 9 has been ack-ed

2.) send packet 2, it doesn't matter because the receiver side will only 
look at packets with the correct seq # that it is expecting. Thus, packet 2 
will either be dropped or buffered. either way, it doesn't close the 
connection, so it's ok.




.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Failed Assertion
Date: Sun, 04 Mar 2007 18:40:55 -0800
Lines: 20
Distribution: su
Message-ID: <esfvss$s6b$1@news.Stanford.EDU>
References: <paun-46D856.17033404032007@nntp.stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173062365 28875 127.0.0.1 (5 Mar 2007 02:39:25 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <paun-46D856.17033404032007@nntp.stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:12127

There's some discussion about this under "Errors from stcp".  A lot of 
us are getting it.  It seems to be a problem with the underlying code 
and it happens when one side closes the connection (the actual TCP 
socket that's simulating the network layer, not STCP) before the other 
side is done.

No word from the TAs yet...

Greg

Filip Paun wrote:
> I am getting the following failed assertion.  Did anybody else have 
> problems with this one?
> 
> server: network_io_socket.c:247: void* network_recv_thread_func(void*): 
> Assertion `!(fds[1].revents & 0x008)' failed.
> 
> Any input would be appreciated.
> 
> Filip
.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: When to ACK and pass the data to application
Date: Sun, 04 Mar 2007 18:44:38 -0800
Lines: 15
Distribution: su
Message-ID: <esg06m$sfo$1@news.Stanford.EDU>
NNTP-Posting-Host: hr-chyoon-1158559642.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173062678 29176 171.66.147.181 (5 Mar 2007 02:44:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Xref: shelby.stanford.edu su.class.cs244a:12128

Hi,

so if I received, say, five (4 STCP_MSS size packets + 1) packets from 
the network and need to pass this to the application. When do I pass the 
buffered data to the application?

I assume this can be done when I have no more data to receive from 
stcp_network_recv()?

And when sending ACK for this received data, can I just sent one ACK 
with the last byte or do I need to send five different ACKs?


Best,
Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: Ray Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Respecting already present code...?
Date: Sun, 04 Mar 2007 20:48:13 -0800
Lines: 36
Distribution: su
Message-ID: <esg7ee$3ti$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173070094 4018 127.0.0.1 (5 Mar 2007 04:48:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
Xref: shelby.stanford.edu su.class.cs244a:12129

Regarding two instances of code that was present in the version of transport.c 
given to us:

1) within the context_t struct:
     bool_t done;    /* TRUE once connection is closed */

2) within the generate_initial_seq_num(ctx) function:
#ifdef FIXED_INITNUM
     /* please don't change this! */
     ctx->initial_sequence_num = 1;

How important is it to respect these structures/preserve the original structure 
of the code?


For example, I don't actually use the initial_sequence_num member in my code, 
except for its use in the generate_initial_seq_num function.  Immediately after 
assignment, I use the value set to initialize my data structures (and after 
that, I'll never touch initial_sequence_num again).

I'm thinking about removing the initial_sequence_num member from my context_t 
struct altogether; of course, I'll still support the functionality of 
force-tying the initial sequence to 1, but I just want to know how vital to 
testing the initial_sequence_num member is.


As for the done boolean, I was planning on asserting done at times to signify 
other things than the connection being closed.  Is it important to assert done 
*only* when the connection is closed, or are we free to do as we will with the 
variable?

TIA,
- Ray

PS. I'm completely aware of/currently using ways around my proposed "remedies" 
above; I just want to keep the struct/code compact.
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: CLOSE_WAIT (received client's FIN)
Date: Sun, 4 Mar 2007 20:49:06 -0800
Lines: 35
Distribution: su
Message-ID: <esg7ga$3vh$1@news.Stanford.EDU>
References: <esfhob$jg4$1@news.Stanford.EDU> <esfjog$l17$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1173070154 4081 128.12.83.54 (5 Mar 2007 04:49:14 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12130

I guess I'm having trouble with the APP_CLOSE.  My server is never calling 
APP_CLOSE since it seems to be waiting for

rc = get_nvt_line(sd, line);
if (rc < 0 || !*line)
            goto done;

which never seems to happen.  Am I missing something?

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:esfjog$l17$1@news.Stanford.EDU...
> Look at AP_CLOSE_REQUESTED, as well as the TCP RFC for FINs as well as the 
> various newsgroup threads about FINs.  Basically, a FIN just means that 
> the side that sent it will not be sending more data, but does not restrict 
> the other side from sending more data.  Additionally, FINs consume one 
> byte of the data stream and should be sent in order with the other bytes 
> in the stream.
>
> -Seth
>
> "Alicia Chen" <achen530@stanford.edu> wrote in message 
> news:esfhob$jg4$1@news.Stanford.EDU...
>> In the case where we receive a FIN from the other side but we haven't 
>> sent one ourselves, what happens if the application on our side is not 
>> done sending data?  For example, if we are the server, the client sends 
>> its request and sends a FIN, and then we are expected to send all the 
>> data the client requested and then send the FIN?  How do we know when the 
>> application is done sending data?
>>
>> --Alicia
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: What to do after 5 retransmissions?
Date: Sun, 04 Mar 2007 21:28:21 -0800
Lines: 22
Distribution: su
Message-ID: <esg9pb$5d2$1@news.Stanford.EDU>
References: <esar4s$njr$1@news.Stanford.EDU> <esavgk$qcc$1@news.Stanford.EDU> <C20E6CE0.8E44%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173072492 5538 127.0.0.1 (5 Mar 2007 05:28:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <C20E6CE0.8E44%jpettit@stanford.edu>
Xref: shelby.stanford.edu su.class.cs244a:12131

Justin Pettit wrote:
>  > I think the answer has to be go to CLOSED and set errno = ECONNABORTED or
>> ETIMEDOUT.  (TAs: Can you let us know which of the two errors is expected
>> here?)
> 
> I'd go with ETIMEDOUT.
> 
>> The retransmissions part of the handout says "the network is assumed to have
>> failed" under these circumstances.  To me, it doesn't make sense to do
>> anything further once you've concluded nothing further will work.
> 
> Correct, if you can't send any new data, it is unlikely that you will be
> able to start a properly close with FINs.
> 
> --Justin
> 

In that case, the other side will not exit gracefully as no FIN is being 
sent across. Is it not? Is that the expected behavior?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: fin packet
Date: Mon, 5 Mar 2007 05:46:51 +0000 (UTC)
Organization: Your Company
Lines: 34
Distribution: su
Message-ID: <Xns98E9DD917F899chunkaiwstanfordedu@171.64.14.103>
References: <Xns98E9B9CFE37EFchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173073611 6101 128.12.22.217 (5 Mar 2007 05:46:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12132

also, 

what should you do if you receive an out of order fin packet?





Chun Kai Wang <chunkaiw@stanford.edu> wrote in
news:Xns98E9B9CFE37EFchunkaiwstanfordedu@171.64.14.103: 

> suppose i have:
> 
> Packet 1: seq 1, len 9
> Packet 2: seq 10, len 1 => fin packet
> 
> 
> suppose i send both to the client, but packet1 is dropped. what
> happens? what is the correct behavior?
> 
> i think there are 2 things we can do.
> 
> 1.) do not send packet 2 until seq 9 has been ack-ed
> 
> 2.) send packet 2, it doesn't matter because the receiver side will
> only look at packets with the correct seq # that it is expecting.
> Thus, packet 2 will either be dropped or buffered. either way, it
> doesn't close the connection, so it's ok.
> 
> 
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: What to do after 5 retransmissions?
Date: Sun, 04 Mar 2007 22:34:03 -0800
Lines: 15
Distribution: su
Message-ID: <C210F9DB.8EEF%jpettit@stanford.edu>
References: <esar4s$njr$1@news.Stanford.EDU> <esavgk$qcc$1@news.Stanford.EDU> <C20E6CE0.8E44%jpettit@stanford.edu> <esg9pb$5d2$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173076451 8108 127.0.0.1 (5 Mar 2007 06:34:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: What to do after 5 retransmissions?
Thread-Index: Acde8EQJgp+NksrjEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12133

>> Correct, if you can't send any new data, it is unlikely that you will be
>> able to start a properly close with FINs.
> 
> In that case, the other side will not exit gracefully as no FIN is being
> sent across. Is it not? Is that the expected behavior?

Sorry, my original post wasn't very clear.  It was supposed to read "start a
*proper* close with FINs."  Since you cannot communicate with the other
side, you won't be able to start a proper close.  If you go away, the other
side will eventually timeout.  It's not graceful, but there's not much you
can do.  TCP behaves in the same manner, but just waits much longer before
giving up.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Sun, 4 Mar 2007 23:29:54 -0800
Lines: 28
Distribution: su
Message-ID: <esggts$a7e$1@news.Stanford.EDU>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1173079804 10478 128.12.83.54 (5 Mar 2007 07:30:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12134

I am having this problem as well.  TAs?

--Alicia

"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:esd84b$p99$1@news.Stanford.EDU...
> Nope, the proxy still shuts down on the assert sometimes.
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:esd7r8$p2c$1@news.Stanford.EDU...
>>> The assert failure happens every time I timeout on one side of the 
>>> connection.  I will modify my timeout to be a bit more generous, but it 
>>> seems like this less-than-graceful behavior localized to the network 
>>> layer.
>> It was also happening most times proxyget finished (in reliable mode).
>>
>> The only way I can get this occurrence to go away is by putting a 10 
>> second timer before exiting the thread.  A pretty fragile network layer. 
>> Is anyone else seeing this, too?
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends!
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: REPOST: Re: sliding window
Date: Mon, 5 Mar 2007 00:04:55 -0800
Lines: 27
Distribution: su
Message-ID: <esgiv8$dna$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173081896 14058 127.0.0.1 (5 Mar 2007 08:04:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12135

Do we need to implement this for our assignment? Will this be tested?
If yes, any suggestions on how I can test this?

"Justin Pettit" <jpettit@stanford.edu> wrote in message
news:C20C5809.8D93%jpettit@stanford.edu...
>>> Good gravy! I believe you just found another TCP exploit! We can open
>>> TCP
>>> connections and make them lock up! :)
>> Only the really bad ones.  I think you still run the timeouts, but I am
>> not
>> sure (someone else was asking about that).  In any case, TCP specifies
>> that
>> at regular intervals, if the window is 0, the TCP connection probes it
>> with
>> a one byte sequence.  I think the receiver is required to have some slush
>> left over to handle these one byte probes, but I am not sure.
>
> All the books are a little unclear about the contents of this one byte
> probe.  I asked Professor McKeown a couple of days ago, and he said that
> it's not new data, but just the last byte that fit in the window that is
> retransmitted.
>
> --Justin
>



.

Path: shelby.stanford.edu!not-for-mail
From: "Ajay Martin" <ajaym@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Killed. Couldn't get registers: No such process
Date: Mon, 5 Mar 2007 00:05:09 -0800
Lines: 26
Distribution: su
Message-ID: <esgivr$dnk$1@news.Stanford.EDU>
NNTP-Posting-Host: paxy.stanford.edu
X-Trace: news.Stanford.EDU 1173081915 14068 128.12.137.162 (5 Mar 2007 08:05:15 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12136

So, I'm facing an issue which I havent come across before, any pointers if 
anybody has come across this would be useful.


When I let the server running for a while, it stops abruptly without any 
indication as to what happened except for a message that goes
"Killed"

On running through gdb, after a similar amount of time, gdb stops saying 
this:
"Couldn't get registers: No such process"

any further actions like bt/where gives
"Cannot fetch general-purpose registers for thread -1227662416: generic 
error"


I'm guessing its some sort of a protected region access violation, (which is 
hard to find) and the kernel is just terminating the process.
this doesnt come up as a segment fault, and valgrind doest show any memory 
overruns too.

Any guesses on what could be up, and how I could point myself to the error?
Ajay 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: REPOST: Re: sliding window
Date: Mon, 05 Mar 2007 00:25:20 -0800
Lines: 37
Distribution: su
Message-ID: <C21113F0.8EFC%jpettit@stanford.edu>
References: <esgiv8$dna$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173083123 15681 127.0.0.1 (5 Mar 2007 08:25:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: REPOST: Re: sliding window
Thread-Index: Acde/8/XDnwd48rzEdum0QARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12137

You do not need to worry about this for the purposes of the assignment.

--Justin


On 3/5/07 12:04 AM, in article esgiv8$dna$1@news.Stanford.EDU, "Riju
Kallivalappil" <riju@stanford.edu> wrote:

> Do we need to implement this for our assignment? Will this be tested?
> If yes, any suggestions on how I can test this?
> 
> "Justin Pettit" <jpettit@stanford.edu> wrote in message
> news:C20C5809.8D93%jpettit@stanford.edu...
>>>> Good gravy! I believe you just found another TCP exploit! We can open
>>>> TCP
>>>> connections and make them lock up! :)
>>> Only the really bad ones.  I think you still run the timeouts, but I am
>>> not
>>> sure (someone else was asking about that).  In any case, TCP specifies
>>> that
>>> at regular intervals, if the window is 0, the TCP connection probes it
>>> with
>>> a one byte sequence.  I think the receiver is required to have some slush
>>> left over to handle these one byte probes, but I am not sure.
>> 
>> All the books are a little unclear about the contents of this one byte
>> probe.  I asked Professor McKeown a couple of days ago, and he said that
>> it's not new data, but just the last byte that fit in the window that is
>> retransmitted.
>> 
>> --Justin
>> 
> 
> 
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: restarting timer
Date: Mon, 05 Mar 2007 00:42:39 -0800
Lines: 26
Distribution: su
Message-ID: <esgl5m$g6v$1@news.Stanford.EDU>
References: <esd5np$nq3$1@news.Stanford.EDU> <esffbr$htj$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173084150 16607 127.0.0.1 (5 Mar 2007 08:42:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esffbr$htj$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12138

Paul Tarjan (TA) wrote:
>> 1.) Option 1: Keep a single timer for the first packet in the sender 
>> window. When you get an ACK, restart this timer.  This means that if 3 
>> packets were sent back to back, and you got ACKs for 1 and 2, packet 3 
>> will not timeout until 2RTT + RTO from the time it was sent.
> Please don't do this way. We want to know if certain packets get lost in 
> the network, not just if the network is down. Just add a time field into 
> the data structure that you put into your queue and check that one. You 
> can assume that the packets were sent (by your STCP) in order, so the 
> first one to timeout would be the leftmost queue entry.
>>
>> 2.) Option 2:  Record the time that every packet was sent out.  If you 
>> get an ACK, the new timeout value would be the time you sent the next 
>> unacked packet + RTO.  I guess this would be more accurate but there 
>> is obviously a lot more overhead.
> There isn't much overhead at all. It is just the leftmost entry in the 
> queue, since the times are in increasing order.

Just need to confirm if what I am doing is right:
When we retransmit multiple packets in the retransmit queue according to 
go back N, should we increment the retransmission count for all the 
packets we retransmit together or should we increment the count only for 
the first packet in the retransmit queue ?

Thanks
Neelima
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors from stcp
Date: Mon, 5 Mar 2007 10:22:12 +0000 (UTC)
Organization: Your Company
Lines: 35
Distribution: su
Message-ID: <Xns98EA181C8209Cchunkaiwstanfordedu@171.64.14.103>
References: <esba73$5qe$1@news.Stanford.EDU> <esci7v$9jr$1@news.Stanford.EDU> <esd31s$m1p$1@news.Stanford.EDU> <esd7r8$p2c$1@news.Stanford.EDU> <esd84b$p99$1@news.Stanford.EDU> <esggts$a7e$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173090132 21318 128.12.22.217 (5 Mar 2007 10:22:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12139

me too...

"Alicia Chen" <achen530@stanford.edu> wrote in
news:esggts$a7e$1@news.Stanford.EDU: 

> I am having this problem as well.  TAs?
> 
> --Alicia
> 
> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:esd84b$p99$1@news.Stanford.EDU...
>> Nope, the proxy still shuts down on the assert sometimes.
>> "Randy Jennings" <randyj@stanford.edu> wrote in message 
>> news:esd7r8$p2c$1@news.Stanford.EDU...
>>>> The assert failure happens every time I timeout on one side of the 
>>>> connection.  I will modify my timeout to be a bit more generous,
>>>> but it seems like this less-than-graceful behavior localized to the
>>>> network layer.
>>> It was also happening most times proxyget finished (in reliable
>>> mode). 
>>>
>>> The only way I can get this occurrence to go away is by putting a 10
>>> second timer before exiting the thread.  A pretty fragile network
>>> layer. Is anyone else seeing this, too?
>>>
>>> Sincerely,
>>> Randy Jennings
>>>
>>> The squirrels are your friends!
>>>
>>
>> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Termination
Date: Mon, 5 Mar 2007 03:07:19 -0800
Lines: 31
Distribution: su
Message-ID: <esgtm3$nlf$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1173092867 24239 171.64.75.59 (5 Mar 2007 11:07:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12140


Hi,
I am having some trouble terminating the STCP connection.

Suppose the client is in the FINWAIT2 state and the server in the
LASTACK state. This means that the server has sent a FIN|ACK to
the client and is waiting for an ACK. Since packets tend to drop often,
the server may repeatedly send the FIN|ACK to the client until it gets
the ACK.

If the client sends an ACK and immediately closes and the ACK drops
in the middle, the server will not be able to communicate anymore and
an error occurs. If the client instead stays around for like 30 seconds,
enabling the server to eventually receive its ACK, then the server will
close first. Since the client is still waiting and accepting packets from
the server, an error occurs when the client tries to receive packets.

I believe the latter approach is the way to go. However, I can't stop the
error from occuring from the network level. The error message

_tcp_io rc: 0
couldn't read packet len: 0

is immediately printed out when the server closes its connection.
I think I am missing something .. Is there a way to gracefully close the 
client
even if the server closes the connection?

-Steven


.

Path: shelby.stanford.edu!not-for-mail
From: Ray Thang <rlt5654@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Errors to report to the user
Date: Mon, 05 Mar 2007 03:43:33 -0800
Lines: 14
Distribution: su
Message-ID: <esgvp6$p5t$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173095014 25789 127.0.0.1 (5 Mar 2007 11:43:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
Xref: shelby.stanford.edu su.class.cs244a:12141

I'm having a little trouble figuring out all the errors that we should be 
notifying the user of.  So far, I've come up with one:

ETIMEDOUT (for when things time out (apologies if this is overly obvious0)

Are there anymore that people can think of?

In the STCP stub code, it makes reference to an ECONNREFUSED error, but I can't 
of anywhere that this error applies (only instances of "refuse" I encountered in 
RFC 793 have to do with the RST flag, which STCP doesn't not handle).

TIA

- Ray
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Errors to report to the user
Date: Mon, 05 Mar 2007 09:38:30 -0800
Lines: 23
Distribution: su
Message-ID: <eshkif$igu$1@news.Stanford.EDU>
References: <esgvp6$p5t$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173116303 18974 127.0.0.1 (5 Mar 2007 17:38:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esgvp6$p5t$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12142

Ray Thang wrote:
> I'm having a little trouble figuring out all the errors that we should 
> be notifying the user of.  So far, I've come up with one:
> 
> ETIMEDOUT (for when things time out (apologies if this is overly obvious0)
> 
> Are there anymore that people can think of?
> 
> In the STCP stub code, it makes reference to an ECONNREFUSED error, but 
> I can't of anywhere that this error applies (only instances of "refuse" 
> I encountered in RFC 793 have to do with the RST flag, which STCP 
> doesn't not handle).
> 
> TIA
> 
> - Ray

I did some googling and it appears ECONNREFUSED is an error you would 
pass up if you sent out a SYN and got back an ICMP message like port 
unreachable or what not.  I don't believe it is possible to receive ICMP 
messages in this assignment.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Mon, 05 Mar 2007 10:00:19 -0800
Lines: 37
Distribution: su
Message-ID: <eshlre$jvt$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173117614 20477 127.0.0.1 (5 Mar 2007 18:00:14 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esgtm3$nlf$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12143

Euijong Whang wrote:
> Hi,
> I am having some trouble terminating the STCP connection.
> 
> Suppose the client is in the FINWAIT2 state and the server in the
> LASTACK state. This means that the server has sent a FIN|ACK to
> the client and is waiting for an ACK. Since packets tend to drop often,
> the server may repeatedly send the FIN|ACK to the client until it gets
> the ACK.
> 
> If the client sends an ACK and immediately closes and the ACK drops
> in the middle, the server will not be able to communicate anymore and
> an error occurs. If the client instead stays around for like 30 seconds,
> enabling the server to eventually receive its ACK, then the server will
> close first. Since the client is still waiting and accepting packets from
> the server, an error occurs when the client tries to receive packets.
> 
> I believe the latter approach is the way to go. However, I can't stop the
> error from occuring from the network level. The error message
> 
> _tcp_io rc: 0
> couldn't read packet len: 0
> 
> is immediately printed out when the server closes its connection.
> I think I am missing something .. Is there a way to gracefully close the 
> client
> even if the server closes the connection?
> 
> -Steven
> 
> 

I believe since you are not required to implement time-wait that the 
former is acceptable, once the client transmits the ack it will exit, 
and when the server receives the error it should gracefully close and exit.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: FIN bit with data
Date: Mon, 5 Mar 2007 12:04:59 -0800
Lines: 13
Distribution: su
Message-ID: <esht3k$rp5$1@news.Stanford.EDU>
References: <esciia$9th$1@news.Stanford.EDU> <esfesq$hhv$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173125044 28453 127.0.0.1 (5 Mar 2007 20:04:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12144

Just verifying (more for the second assignment).  I found the problem in my 
code (should have done my own log sooner).

Sincerely,
Randy Jennings
"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:esfesq$hhv$2@news.Stanford.EDU...
>> Does the grading script correctly handle the case when the FIN bit is 
>> sent in a data packet?
> Yes. If you don't think it does, send me the code in question and I'll run 
> the script on it and send you back the packet log as well. 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Mon, 5 Mar 2007 12:21:11 -0800
Lines: 33
Distribution: su
Message-ID: <eshu20$snp$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU> <eshlre$jvt$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173126016 29433 127.0.0.1 (5 Mar 2007 20:20:16 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12145

>> If the client sends an ACK and immediately closes and the ACK drops
>> in the middle, the server will not be able to communicate anymore and
>> an error occurs. If the client instead stays around for like 30 seconds,
>> enabling the server to eventually receive its ACK, then the server will
>> close first. Since the client is still waiting and accepting packets from
>> the server, an error occurs when the client tries to receive packets.
>>
>> I believe the latter approach is the way to go. However, I can't stop the
>> error from occuring from the network level. The error message
>>
>> _tcp_io rc: 0
>> couldn't read packet len: 0
I think you are not sending the TCP header.
>>
>> is immediately printed out when the server closes its connection.
>> I think I am missing something .. Is there a way to gracefully close the 
>> client
>> even if the server closes the connection?
>>
> I believe since you are not required to implement time-wait that the 
> former is acceptable, once the client transmits the ack it will exit, and 
> when the server receives the error it should gracefully close and exit.
That would be nice, but see Errors from stcp thread.  No TA has commented on 
what we are observing; it is anything but graceful.

I can make it happen every time if you need a test case.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Mon, 05 Mar 2007 12:36:13 -0800
Lines: 40
Distribution: su
Message-ID: <eshuvn$78$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU> <eshlre$jvt$1@news.Stanford.EDU> <eshu20$snp$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173126967 232 127.0.0.1 (5 Mar 2007 20:36:07 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <eshu20$snp$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12146

Randy Jennings wrote:
>>> If the client sends an ACK and immediately closes and the ACK drops
>>> in the middle, the server will not be able to communicate anymore and
>>> an error occurs. If the client instead stays around for like 30 seconds,
>>> enabling the server to eventually receive its ACK, then the server will
>>> close first. Since the client is still waiting and accepting packets from
>>> the server, an error occurs when the client tries to receive packets.
>>>
>>> I believe the latter approach is the way to go. However, I can't stop the
>>> error from occuring from the network level. The error message
>>>
>>> _tcp_io rc: 0
>>> couldn't read packet len: 0
> I think you are not sending the TCP header.
>>> is immediately printed out when the server closes its connection.
>>> I think I am missing something .. Is there a way to gracefully close the 
>>> client
>>> even if the server closes the connection?
>>>
>> I believe since you are not required to implement time-wait that the 
>> former is acceptable, once the client transmits the ack it will exit, and 
>> when the server receives the error it should gracefully close and exit.
> That would be nice, but see Errors from stcp thread.  No TA has commented on 
> what we are observing; it is anything but graceful.
> 
> I can make it happen every time if you need a test case.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 

Euijong is saying he is getting an ungraceful exit when the (what he 
terms the client) waits to be sure the server received the ack, and the 
server exits ahead of the client.  I am responding and saying he should 
go with the former method mentioned.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Connection Tear Down on Client Side
Date: Mon, 05 Mar 2007 13:12:44 -0800
Lines: 6
Distribution: su
Message-ID: <esi14e$2du$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173129166 2494 127.0.0.1 (5 Mar 2007 21:12:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
Xref: shelby.stanford.edu su.class.cs244a:12147

When should the client tear down the connection?  If it is not sending 
any packets, it cannot use the 5 timeouts rule.  However, if the other 
side is down, it will just hang there waiting for incoming network data.

Thanks,
Yuliya
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Connection Tear Down on Client Side
Date: Mon, 05 Mar 2007 13:44:34 -0800
Lines: 13
Distribution: su
Message-ID: <esi302$3tt$1@news.Stanford.EDU>
References: <esi14e$2du$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173131074 4029 127.0.0.1 (5 Mar 2007 21:44:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esi14e$2du$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12148

Yuliya Sarkisyan wrote:
> When should the client tear down the connection?  If it is not sending 
> any packets, it cannot use the 5 timeouts rule.  However, if the other 
> side is down, it will just hang there waiting for incoming network data.
> 
> Thanks,
> Yuliya

When the application gives you the close event, or after the other side 
initiates the tear down, you notify the above layer, and the above layer 
agrees to tear it down.  Or if there is an error.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: When to ACK and pass the data to application
Date: Mon, 05 Mar 2007 13:48:39 -0800
Lines: 23
Distribution: su
Message-ID: <esi37n$3tt$2@news.Stanford.EDU>
References: <esg06m$sfo$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173131319 4029 127.0.0.1 (5 Mar 2007 21:48:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esg06m$sfo$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12149

Chee-Hyung Yoon wrote:
> Hi,
> 
> so if I received, say, five (4 STCP_MSS size packets + 1) packets from 
> the network and need to pass this to the application. When do I pass the 
> buffered data to the application?

You should be able to pass the data up as soon as you receive it if you 
have passed up all the previous data, and it is in order.

> 
> I assume this can be done when I have no more data to receive from 
> stcp_network_recv()?
> 
> And when sending ACK for this received data, can I just sent one ACK 
> with the last byte or do I need to send five different ACKs?
> 

Please read the ack section of the assignment, but in summary you should 
send an ack every time you receive data if it is the next set of data 
you are expecting.  Etc.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Respecting already present code...?
Date: Mon, 05 Mar 2007 13:52:34 -0800
Lines: 43
Distribution: su
Message-ID: <esi3f2$3tt$3@news.Stanford.EDU>
References: <esg7ee$3ti$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173131554 4029 127.0.0.1 (5 Mar 2007 21:52:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esg7ee$3ti$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12150

Ray Thang wrote:
> Regarding two instances of code that was present in the version of 
> transport.c given to us:
> 
> 1) within the context_t struct:
>     bool_t done;    /* TRUE once connection is closed */
> 
> 2) within the generate_initial_seq_num(ctx) function:
> #ifdef FIXED_INITNUM
>     /* please don't change this! */
>     ctx->initial_sequence_num = 1;
> 
> How important is it to respect these structures/preserve the original 
> structure of the code?
> 
> 
> For example, I don't actually use the initial_sequence_num member in my 
> code, except for its use in the generate_initial_seq_num function.  
> Immediately after assignment, I use the value set to initialize my data 
> structures (and after that, I'll never touch initial_sequence_num again).
> 
> I'm thinking about removing the initial_sequence_num member from my 
> context_t struct altogether; of course, I'll still support the 
> functionality of force-tying the initial sequence to 1, but I just want 
> to know how vital to testing the initial_sequence_num member is.
> 
> 
> As for the done boolean, I was planning on asserting done at times to 
> signify other things than the connection being closed.  Is it important 
> to assert done *only* when the connection is closed, or are we free to 
> do as we will with the variable?
> 
> TIA,
> - Ray
> 
> PS. I'm completely aware of/currently using ways around my proposed 
> "remedies" above; I just want to keep the struct/code compact.

You are welcome to change what you want in transport.c, but realize that 
  modifying the things in it may affect underlying test structures and 
harnesses, so do it at your own peril :)

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet drop
Date: Mon, 05 Mar 2007 13:54:11 -0800
Lines: 12
Distribution: su
Message-ID: <esi3i3$3tt$4@news.Stanford.EDU>
References: <Xns98E99DCA1C665chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173131651 4029 127.0.0.1 (5 Mar 2007 21:54:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <Xns98E99DCA1C665chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12151

Chun Kai Wang wrote:
> what if a syn packet is dropped?
> 
> what if a fin packet is dropped?
> 
> in both cases, do i re-try 5x's?

This is covered in the retransmissions section of the assignment.

http://www.stanford.edu/class/cs244a/hw3/hw3.html

-David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: retransmission failure
Date: Mon, 05 Mar 2007 13:55:50 -0800
Lines: 15
Distribution: su
Message-ID: <esi3l6$3tt$5@news.Stanford.EDU>
References: <Xns98E9ABC74E79Bchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173131750 4029 127.0.0.1 (5 Mar 2007 21:55:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <Xns98E9ABC74E79Bchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12152

Chun Kai Wang wrote:
> suppose i have 1000 packet queued up in the retransmission queue.
> 
> suppose acks for packet 100, 200, 300, 400, 500 are all dropped, thus we 
> have 5 retranmissions for packet# 500 and greater.
> 
> in this case, do we declare a failure of network due to more than 5 
> retransmitts for the 1000th packet? since everytime we retransmit, we 
> retransmit everything, so the chance that 1000th packet is retransmitted 
> more than 5 times is extremely high. 

No, I believe the 5x retransmission is per packet, so if any single 
packet fails after 5 retransmissions then you abort the connection.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: CLOSE_WAIT (received client's FIN)
Date: Mon, 5 Mar 2007 14:02:53 -0800
Lines: 44
Distribution: su
Message-ID: <esi42i$57f$1@news.Stanford.EDU>
References: <esfhob$jg4$1@news.Stanford.EDU> <esfjog$l17$1@news.Stanford.EDU> <esg7ga$3vh$1@news.Stanford.EDU>
NNTP-Posting-Host: boxy.stanford.edu
X-Trace: news.Stanford.EDU 1173132178 5359 128.12.83.54 (5 Mar 2007 22:02:58 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12153

haha, sorry, wasn't calling stcp_fin_received.  Note to self: read FAQs. 
Note to TAs: put HW3 FAQ link on the course FAQ webpage...

--Alicia

"Alicia Chen" <achen530@stanford.edu> wrote in message 
news:esg7ga$3vh$1@news.Stanford.EDU...
>I guess I'm having trouble with the APP_CLOSE.  My server is never calling 
>APP_CLOSE since it seems to be waiting for
>
> rc = get_nvt_line(sd, line);
> if (rc < 0 || !*line)
>            goto done;
>
> which never seems to happen.  Am I missing something?
>
> "Seth Wright" <orion@cs.stanford.edu> wrote in message 
> news:esfjog$l17$1@news.Stanford.EDU...
>> Look at AP_CLOSE_REQUESTED, as well as the TCP RFC for FINs as well as 
>> the various newsgroup threads about FINs.  Basically, a FIN just means 
>> that the side that sent it will not be sending more data, but does not 
>> restrict the other side from sending more data.  Additionally, FINs 
>> consume one byte of the data stream and should be sent in order with the 
>> other bytes in the stream.
>>
>> -Seth
>>
>> "Alicia Chen" <achen530@stanford.edu> wrote in message 
>> news:esfhob$jg4$1@news.Stanford.EDU...
>>> In the case where we receive a FIN from the other side but we haven't 
>>> sent one ourselves, what happens if the application on our side is not 
>>> done sending data?  For example, if we are the server, the client sends 
>>> its request and sends a FIN, and then we are expected to send all the 
>>> data the client requested and then send the FIN?  How do we know when 
>>> the application is done sending data?
>>>
>>> --Alicia
>>>
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Yuliya Sarkisyan <yuliya@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Connection Tear Down on Client Side
Date: Mon, 05 Mar 2007 14:07:16 -0800
Lines: 26
Distribution: su
Message-ID: <esi4am$5b7$1@news.Stanford.EDU>
References: <esi14e$2du$1@news.Stanford.EDU> <esi302$3tt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173132438 5479 127.0.0.1 (5 Mar 2007 22:07:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esi302$3tt$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12154

David Erickson wrote:
> Yuliya Sarkisyan wrote:
>> When should the client tear down the connection?  If it is not sending 
>> any packets, it cannot use the 5 timeouts rule.  However, if the other 
>> side is down, it will just hang there waiting for incoming network data.
>>
>> Thanks,
>> Yuliya
> 
> When the application gives you the close event, or after the other side 
> initiates the tear down, you notify the above layer, and the above layer 
> agrees to tear it down.  Or if there is an error.
> 
> -David

My question was more along the lines of what if there was a client (that 
only reads data) and a server, and what if the server was suddenly just 
gone (it did not initiate the connection tear down, but for some reason 
shut down - for example if I control-C'd it).  The client's application 
will not initiate a close (because it thinks there is more data), but no 
more data arrives.  What should we do in this case?  Should we count the 
number of timeouts in which no event occurs (no network data, no app 
data, no close request) and close the connection with errno = ETIMEDOUT 
(although we weren't sending any data)?

Thanks.
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Connection Tear Down on Client Side
Date: Mon, 05 Mar 2007 14:24:42 -0800
Lines: 39
Distribution: su
Message-ID: <esi5ba$5rp$1@news.Stanford.EDU>
References: <esi14e$2du$1@news.Stanford.EDU> <esi302$3tt$1@news.Stanford.EDU> <esi4am$5b7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173133482 6009 127.0.0.1 (5 Mar 2007 22:24:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esi4am$5b7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12155

Yuliya Sarkisyan wrote:
> David Erickson wrote:
>> Yuliya Sarkisyan wrote:
>>> When should the client tear down the connection?  If it is not 
>>> sending any packets, it cannot use the 5 timeouts rule.  However, if 
>>> the other side is down, it will just hang there waiting for incoming 
>>> network data.
>>>
>>> Thanks,
>>> Yuliya
>>
>> When the application gives you the close event, or after the other 
>> side initiates the tear down, you notify the above layer, and the 
>> above layer agrees to tear it down.  Or if there is an error.
>>
>> -David
> 
> My question was more along the lines of what if there was a client (that 
> only reads data) and a server, and what if the server was suddenly just 
> gone (it did not initiate the connection tear down, but for some reason 
> shut down - for example if I control-C'd it).  The client's application 
> will not initiate a close (because it thinks there is more data), but no 
> more data arrives.  What should we do in this case?  Should we count the 
> number of timeouts in which no event occurs (no network data, no app 
> data, no close request) and close the connection with errno = ETIMEDOUT 
> (although we weren't sending any data)?
> 
> Thanks.

I believe this is an application design issue more than a problem with 
the transport layer, ie if there is no outstanding data in the network, 
and the other side disappears, there is no course of action that the 
transport layer can take because it is unaware of the loss until it 
actually sends data.  So at some point if you dont receive any data then 
your application should send a heartbeat to the other side, at which 
point it would discover the other side is gone.  Something along those 
lines.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: packet overlap
Date: Mon, 05 Mar 2007 14:32:54 -0800
Lines: 46
Distribution: su
Message-ID: <esi5pk$6f4$1@news.Stanford.EDU>
References: <Xns98E99317EA9D8chunkaiwstanfordedu@171.64.14.103> <esfpar$ob7$1@news.Stanford.EDU> <Xns98E9AC3E1540chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: paralax.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173133940 6628 172.24.74.102 (5 Mar 2007 22:32:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <Xns98E9AC3E1540chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12156

These cases can and will happen. But you can assume that the overlapping 
data will be the same in all packets. That means you can deal with it 
however you like (using the first packet you saw, or the last one, or 
whatever).

Overlaps can be partial, or full.

Chun Kai Wang wrote:
> it's complicated because my incomming buffer structure is a linklist. if 
> u allow those packet sequence, u'll have a case where adding a packet 
> might delete all other entries in that incomming buffer. 
> 
> such is the case when:
> 
> pakcet 1, seq 1, len 1
> pakcet 2, seq 2, len 1
> pakcet 3, seq 3, len 1
> pakcet 4, seq 4, len 1
> pakcet 5, seq 5, len 1
> pakcet 6, seq 6, len 1
> pakcet 7, seq 7, len 1
> pakcet 8, seq 8, len 1
> packet 9, seq 1, len 20
> 
> so when packet 9 comes, u delete packets 1-8 from the buffer...
> 
> 
> basically, ti's complicated cuz there are alot of cases. what if it's 
> not a full overlap? partial overlap on either ends?
> 
> 
> 
> 
> 
> 
> 
> 
> "David Gobaud" <gobaudd@stanford.edu> wrote in
> news:esfpar$ob7$1@news.Stanford.EDU: 
> 
>> I'm going to guess that is a possible packet sequence. Why will it
>> make your insert function complicated? When you receive packet 2, just
>> copy the whole thing to your receive buffer. You will overwrite bytes
>> [100,200] with the same values but this is ok right?
>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Failed Assertion
Date: Mon, 05 Mar 2007 14:34:51 -0800
Lines: 14
Distribution: su
Message-ID: <esi5t9$6f4$2@news.Stanford.EDU>
References: <paun-46D856.17033404032007@nntp.stanford.edu> <esfvss$s6b$1@news.Stanford.EDU>
NNTP-Posting-Host: paralax.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173134057 6628 172.24.74.102 (5 Mar 2007 22:34:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esfvss$s6b$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12157

Greg Nelson wrote:
> There's some discussion about this under "Errors from stcp".  A lot of 
> us are getting it.  It seems to be a problem with the underlying code 
> and it happens when one side closes the connection (the actual TCP 
> socket that's simulating the network layer, not STCP) before the other 
> side is done.
> 
> No word from the TAs yet...

We are unable to reproduce this problem. Could you send me a test case 
that causes this assertion on every run?

If anyone finds out the issue and can make a patch, please also send 
that to me :)
.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Mon, 5 Mar 2007 15:45:39 -0800
Lines: 62
Distribution: su
Message-ID: <esia40$a0t$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU> <eshlre$jvt$1@news.Stanford.EDU> <eshu20$snp$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1173138368 10269 171.64.75.59 (5 Mar 2007 23:46:08 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12158


Hi Randy,

I fixed my problem: I was always putting a NULL in the second argument
of stcp_wait_for_event, making it stall forever when the other side closed 
its
connection. Instead, I am giving 5 seconds when the connection_state of the
client (which initiated the termination) becomes TIMEWAIT.

Implementing TIMEWAIT is not much work and pretty much guarantees a
clean termination. Since the client is waiting for 30 seconds, the server 
has
plenty of time to terminate first. The client then terminates by itself. My 
mistake
was that the client couldn't terminate because it was stalling at 
stcp_wait_for_event
indefinitely even though the server had closed its connection.

Termination is smooth even if 50% of packets are dropped.

-Steven



"Randy Jennings" <randyj@stanford.edu> wrote in message 
news:eshu20$snp$1@news.Stanford.EDU...
>>> If the client sends an ACK and immediately closes and the ACK drops
>>> in the middle, the server will not be able to communicate anymore and
>>> an error occurs. If the client instead stays around for like 30 seconds,
>>> enabling the server to eventually receive its ACK, then the server will
>>> close first. Since the client is still waiting and accepting packets 
>>> from
>>> the server, an error occurs when the client tries to receive packets.
>>>
>>> I believe the latter approach is the way to go. However, I can't stop 
>>> the
>>> error from occuring from the network level. The error message
>>>
>>> _tcp_io rc: 0
>>> couldn't read packet len: 0
> I think you are not sending the TCP header.
>>>
>>> is immediately printed out when the server closes its connection.
>>> I think I am missing something .. Is there a way to gracefully close the 
>>> client
>>> even if the server closes the connection?
>>>
>> I believe since you are not required to implement time-wait that the 
>> former is acceptable, once the client transmits the ack it will exit, and 
>> when the server receives the error it should gracefully close and exit.
> That would be nice, but see Errors from stcp thread.  No TA has commented 
> on what we are observing; it is anything but graceful.
>
> I can make it happen every time if you need a test case.
>
> Sincerely,
> Randy Jennings
>
> The squirrels are your friends!
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Tue, 6 Mar 2007 00:08:04 +0000 (UTC)
Lines: 72
Distribution: su
Message-ID: <esibd4$au1$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU> <eshlre$jvt$1@news.Stanford.EDU> <eshu20$snp$1@news.Stanford.EDU> <esia40$a0t$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1173139684 11201 171.64.15.6 (6 Mar 2007 00:08:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12159

Hi Steven,

Is it possible that DEBUG flag is on in your makefile.
If I on this flag, I also get the same message printed, but if I off
it then I don't see these messages.

Thanks,
Dinesh

Euijong Whang <euijong@stanford.edu> wrote:

> Hi Randy,

> I fixed my problem: I was always putting a NULL in the second argument
> of stcp_wait_for_event, making it stall forever when the other side closed 
> its
> connection. Instead, I am giving 5 seconds when the connection_state of the
> client (which initiated the termination) becomes TIMEWAIT.

> Implementing TIMEWAIT is not much work and pretty much guarantees a
> clean termination. Since the client is waiting for 30 seconds, the server 
> has
> plenty of time to terminate first. The client then terminates by itself. My 
> mistake
> was that the client couldn't terminate because it was stalling at 
> stcp_wait_for_event
> indefinitely even though the server had closed its connection.

> Termination is smooth even if 50% of packets are dropped.

> -Steven



> "Randy Jennings" <randyj@stanford.edu> wrote in message 
> news:eshu20$snp$1@news.Stanford.EDU...
> >>> If the client sends an ACK and immediately closes and the ACK drops
> >>> in the middle, the server will not be able to communicate anymore and
> >>> an error occurs. If the client instead stays around for like 30 seconds,
> >>> enabling the server to eventually receive its ACK, then the server will
> >>> close first. Since the client is still waiting and accepting packets 
> >>> from
> >>> the server, an error occurs when the client tries to receive packets.
> >>>
> >>> I believe the latter approach is the way to go. However, I can't stop 
> >>> the
> >>> error from occuring from the network level. The error message
> >>>
> >>> _tcp_io rc: 0
> >>> couldn't read packet len: 0
> > I think you are not sending the TCP header.
> >>>
> >>> is immediately printed out when the server closes its connection.
> >>> I think I am missing something .. Is there a way to gracefully close the 
> >>> client
> >>> even if the server closes the connection?
> >>>
> >> I believe since you are not required to implement time-wait that the 
> >> former is acceptable, once the client transmits the ack it will exit, and 
> >> when the server receives the error it should gracefully close and exit.
> > That would be nice, but see Errors from stcp thread.  No TA has commented 
> > on what we are observing; it is anything but graceful.
> >
> > I can make it happen every time if you need a test case.
> >
> > Sincerely,
> > Randy Jennings
> >
> > The squirrels are your friends!
> > 


.

Path: shelby.stanford.edu!not-for-mail
From: "Euijong Whang" <euijong@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Termination
Date: Mon, 5 Mar 2007 16:11:04 -0800
Lines: 25
Distribution: su
Message-ID: <esibjl$b6j$1@news.Stanford.EDU>
References: <esgtm3$nlf$1@news.Stanford.EDU> <eshlre$jvt$1@news.Stanford.EDU> <eshu20$snp$1@news.Stanford.EDU> <esia40$a0t$1@news.Stanford.EDU> <esibd4$au1$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab404b3b.stanford.edu
X-Trace: news.Stanford.EDU 1173139893 11475 171.64.75.59 (6 Mar 2007 00:11:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12160


Hi Dinesh,

Yes, you don't get those messages when DEBUG is off.
My problem was not about the message itself but that the client
(initiator of termination) was stalling, due to my mistake I mentioned 
above.

Thanks,
Steven


"Dinesh Gupta" <dineshg@Stanford.EDU> wrote in message 
news:esibd4$au1$1@news.Stanford.EDU...
> Hi Steven,
>
> Is it possible that DEBUG flag is on in your makefile.
> If I on this flag, I also get the same message printed, but if I off
> it then I don't see these messages.
>
> Thanks,
> Dinesh
>


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns EINVAL
Date: Mon, 5 Mar 2007 16:56:13 -0800
Lines: 29
Distribution: su
Message-ID: <esie7k$cvt$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1173142580 13309 128.12.81.44 (6 Mar 2007 00:56:20 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12161

Hi,

I'm getting the following

server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t, 
unsigned int, const timespec*): Assertion `0' failed.
Abort

The assertion is caused in stcp_api.c line 107 when pthread_cond_timedwait 
returns EINVAL docs say it can be a mutex/condition variable problem or a 
timeout problem. I'm calculating timeout with

        timeval tv_timeout;
        timespec timeout;

            gettimeofday(&tv_timeout, NULL);
            timeout.tv_sec = tv_timeout.tv_sec;
            timeout.tv_nsec = tv_timeout.tv_usec * 1000;

            timeout.tv_sec += ctx->rto / 1000000;
            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;

am I missing something?

-- 
Thank you,
David Gobaud


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: APP_CLOSE_REQUESTED && APP_DATA
Date: Mon, 5 Mar 2007 17:10:30 -0800
Lines: 24
Distribution: su
Message-ID: <esif0e$dmf$1@news.Stanford.EDU>
References: <escjmm$ao8$1@news.Stanford.EDU> <esff1i$hhv$3@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173143375 14031 127.0.0.1 (6 Mar 2007 01:09:35 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12162

>> Can we get APP_CLOSE_REQUESTED and APP_DATA both set on the return from 
>> stcp_wait_for_event?
> Test it out. I'm unsure of the internal workings. Just write a small c 
> program:
>
> int main() {
> int s = mysocket(...);
> char data[3073];
> memset(data, 42, 3073);
> mywrite(s, data, 3073);
> printf("Written data");
> myclose(s);
> }
That's a good idea.  However, it seems like it would be a race condition 
between threads, so it would be hard to determine reliably by just running 
the code.  I think I am going to bet on it not happening, and I will (with 
some probability) be okay.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns EINVAL
Date: Mon, 5 Mar 2007 17:11:41 -0800
Lines: 34
Distribution: su
Message-ID: <esif2l$dq7$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173143445 14151 127.0.0.1 (6 Mar 2007 01:10:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12163

See previous thread, "Failed Assertion".
"David Gobaud" <gobaudd@stanford.edu> wrote in message 
news:esie7k$cvt$1@news.Stanford.EDU...
> Hi,
>
> I'm getting the following
>
> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t, 
> unsigned int, const timespec*): Assertion `0' failed.
> Abort
>
> The assertion is caused in stcp_api.c line 107 when pthread_cond_timedwait 
> returns EINVAL docs say it can be a mutex/condition variable problem or a 
> timeout problem. I'm calculating timeout with
>
>        timeval tv_timeout;
>        timespec timeout;
>
>            gettimeofday(&tv_timeout, NULL);
>            timeout.tv_sec = tv_timeout.tv_sec;
>            timeout.tv_nsec = tv_timeout.tv_usec * 1000;
>
>            timeout.tv_sec += ctx->rto / 1000000;
>            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;
>
> am I missing something?
>
> -- 
> Thank you,
> David Gobaud
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns
 EINVAL
Date: Mon, 05 Mar 2007 17:52:17 -0800
Lines: 44
Distribution: su
Message-ID: <esihde$fd3$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU> <esif2l$dq7$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173145838 15779 127.0.0.1 (6 Mar 2007 01:50:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esif2l$dq7$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12164

I think that's a different assertion, Randy.

The EINVAL thing is probably due to the tv_nsec field being greater than 
1 billion in the timespec struct you pass as abstime to 
stcp_wait_for_event.  Make sure you "carry" the 1 second to the tv_sec 
field and subtract it from the tv_nsec field.

Greg

Randy Jennings wrote:
> See previous thread, "Failed Assertion".
> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
> news:esie7k$cvt$1@news.Stanford.EDU...
>> Hi,
>>
>> I'm getting the following
>>
>> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t, 
>> unsigned int, const timespec*): Assertion `0' failed.
>> Abort
>>
>> The assertion is caused in stcp_api.c line 107 when pthread_cond_timedwait 
>> returns EINVAL docs say it can be a mutex/condition variable problem or a 
>> timeout problem. I'm calculating timeout with
>>
>>        timeval tv_timeout;
>>        timespec timeout;
>>
>>            gettimeofday(&tv_timeout, NULL);
>>            timeout.tv_sec = tv_timeout.tv_sec;
>>            timeout.tv_nsec = tv_timeout.tv_usec * 1000;
>>
>>            timeout.tv_sec += ctx->rto / 1000000;
>>            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;
>>
>> am I missing something?
>>
>> -- 
>> Thank you,
>> David Gobaud
>>
>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns
   EINVAL
Date: Mon, 05 Mar 2007 18:26:43 -0800
Lines: 53
Distribution: su
Message-ID: <esije0$hu6$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU> <esif2l$dq7$1@news.Stanford.EDU> <esihde$fd3$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173147904 18374 127.0.0.1 (6 Mar 2007 02:25:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
In-Reply-To: <esihde$fd3$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12165

Sorry, I didn't look close enough at the code you posted.  It looks like 
you are doing that...  In that case, I don't know what it could be.  I'd 
double check the values before you call stcp_wait_for_event and make 
sure they're not negative or something.

Greg

Greg Nelson wrote:
> I think that's a different assertion, Randy.
> 
> The EINVAL thing is probably due to the tv_nsec field being greater than 
> 1 billion in the timespec struct you pass as abstime to 
> stcp_wait_for_event.  Make sure you "carry" the 1 second to the tv_sec 
> field and subtract it from the tv_nsec field.
> 
> Greg
> 
> Randy Jennings wrote:
>> See previous thread, "Failed Assertion".
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:esie7k$cvt$1@news.Stanford.EDU...
>>> Hi,
>>>
>>> I'm getting the following
>>>
>>> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t, 
>>> unsigned int, const timespec*): Assertion `0' failed.
>>> Abort
>>>
>>> The assertion is caused in stcp_api.c line 107 when 
>>> pthread_cond_timedwait returns EINVAL docs say it can be a 
>>> mutex/condition variable problem or a timeout problem. I'm 
>>> calculating timeout with
>>>
>>>        timeval tv_timeout;
>>>        timespec timeout;
>>>
>>>            gettimeofday(&tv_timeout, NULL);
>>>            timeout.tv_sec = tv_timeout.tv_sec;
>>>            timeout.tv_nsec = tv_timeout.tv_usec * 1000;
>>>
>>>            timeout.tv_sec += ctx->rto / 1000000;
>>>            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;
>>>
>>> am I missing something?
>>>
>>> -- 
>>> Thank you,
>>> David Gobaud
>>>
>>>
>>
>>
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: timeout ----- HELP!!!
Date: Tue, 6 Mar 2007 03:13:24 +0000 (UTC)
Organization: Your Company
Lines: 36
Distribution: su
Message-ID: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173150804 20033 128.12.22.217 (6 Mar 2007 03:13:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12166

so, is this correct?

suppose RTT = 2 seconds, and RTO = 2*RTT

packet 1 sent at 1 sec 
packet 2 sent at 1.1 sec
packet 3 sent at 1.2 sec
packet 4 sent at 1.3 sec
packet 5 sent at 1.4 sec
packet 6 sent at 1.5 sec


suppose packet 1 is dropped.

since packet 1 is dropped, even if 2-6 reach the destination, they 
cannot be acknowledged, thus,

packet 1 will be retransmitted when RTO,

then packet 2 will timeout before packet 1 since packet 1's retransmit 
was after packet 2's first transmit,

thus, when packet 2 timesout, packet 1 and 2 are sent again, even if 
packet 1 has not timed out yet.

this will cascade, and the link will fail just because packet 1 was 
dropped, since # times packet 1 was retransmitted > 5.


is this what is suppose to happen?

because if it is, i think it makes more sense to have 1 timeout value, 
and resend everything in the buffer when timeout occurs, and reset 
timeout when a useful ack (ack where it decreases the out-buffer) has 
been received. this will minimize the amount of traffic... and is more 
efficient no?
.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Mon, 05 Mar 2007 23:29:29 -0500
Lines: 42
Distribution: su
Message-ID: <esiqqp$n4v$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173155481 23711 127.0.0.1 (6 Mar 2007 04:31:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
In-Reply-To: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12167

Chun Kai Wang wrote:
> so, is this correct?
> 
> suppose RTT = 2 seconds, and RTO = 2*RTT
> 
> packet 1 sent at 1 sec 
> packet 2 sent at 1.1 sec
> packet 3 sent at 1.2 sec
> packet 4 sent at 1.3 sec
> packet 5 sent at 1.4 sec
> packet 6 sent at 1.5 sec
> 
> 
> suppose packet 1 is dropped.
> 
> since packet 1 is dropped, even if 2-6 reach the destination, they 
> cannot be acknowledged, thus,
> 
> packet 1 will be retransmitted when RTO,
> 
> then packet 2 will timeout before packet 1 since packet 1's retransmit 
> was after packet 2's first transmit,
> 
> thus, when packet 2 timesout, packet 1 and 2 are sent again, even if 
> packet 1 has not timed out yet.
> 
> this will cascade, and the link will fail just because packet 1 was 
> dropped, since # times packet 1 was retransmitted > 5.
> 
> 
> is this what is suppose to happen?

No

> 
> because if it is, i think it makes more sense to have 1 timeout value, 
> and resend everything in the buffer when timeout occurs, and reset 
> timeout when a useful ack (ack where it decreases the out-buffer) has 
> been received. this will minimize the amount of traffic... and is more 
> efficient no?

This alternative is actually what is supposed to happen.
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns EINVAL
Date: Mon, 5 Mar 2007 20:36:15 -0800
Lines: 5
Distribution: su
Message-ID: <esir28$n9k$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU> <esif2l$dq7$1@news.Stanford.EDU> <esihde$fd3$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173155720 23860 127.0.0.1 (6 Mar 2007 04:35:20 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12168

>I think that's a different assertion, Randy.

Sorry, my bad.  I'm not sure then. 


.

Path: shelby.stanford.edu!not-for-mail
From: Jitendra Nath Pandey <jnpandey@gmail.com>
Newsgroups: su.class.cs244a
Subject: Deliverable for 3C
Date: Mon, 05 Mar 2007 21:38:16 -0800
Lines: 5
Distribution: su
Message-ID: <esiunt$phh$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173159485 26161 127.0.0.1 (6 Mar 2007 05:38:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
Xref: shelby.stanford.edu su.class.cs244a:12169

In 3C, are we required to submit our own proxy, or is it optional?

please confirm.

thanks
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 6 Mar 2007 06:00:39 +0000 (UTC)
Organization: Your Company
Lines: 62
Distribution: su
Message-ID: <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173160839 26545 128.12.22.217 (6 Mar 2007 06:00:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12170

But if we use implementation 2, we might be re-transmitting packet 6 
more than 5 times. no?

suppose packet 1 is dropped 4x and packet 3 is dropped 4x, then that 
means packet 6 is retransmitted 8x at least but since we reset the 
counter every useful ack, we will be able to do this... that's ok?






Jin Wang <jinwang@stanford.edu> wrote in news:esiqqp$n4v$1
@news.Stanford.EDU:

> Chun Kai Wang wrote:
>> so, is this correct?
>> 
>> suppose RTT = 2 seconds, and RTO = 2*RTT
>> 
>> packet 1 sent at 1 sec 
>> packet 2 sent at 1.1 sec
>> packet 3 sent at 1.2 sec
>> packet 4 sent at 1.3 sec
>> packet 5 sent at 1.4 sec
>> packet 6 sent at 1.5 sec
>> 
>> 
>> suppose packet 1 is dropped.
>> 
>> since packet 1 is dropped, even if 2-6 reach the destination, they 
>> cannot be acknowledged, thus,
>> 
>> packet 1 will be retransmitted when RTO,
>> 
>> then packet 2 will timeout before packet 1 since packet 1's 
retransmit 
>> was after packet 2's first transmit,
>> 
>> thus, when packet 2 timesout, packet 1 and 2 are sent again, even if 
>> packet 1 has not timed out yet.
>> 
>> this will cascade, and the link will fail just because packet 1 was 
>> dropped, since # times packet 1 was retransmitted > 5.
>> 
>> 
>> is this what is suppose to happen?
> 
> No
> 
>> 
>> because if it is, i think it makes more sense to have 1 timeout 
value, 
>> and resend everything in the buffer when timeout occurs, and reset 
>> timeout when a useful ack (ack where it decreases the out-buffer) has 
>> been received. this will minimize the amount of traffic... and is 
more 
>> efficient no?
> 
> This alternative is actually what is supposed to happen.
> 

.

Path: shelby.stanford.edu!not-for-mail
From: Jitendra Nath Pandey <jnpandey@gmail.com>
Newsgroups: su.class.cs244a
Subject: Re: Failed Assertion
Date: Mon, 05 Mar 2007 22:04:37 -0800
Lines: 20
Distribution: su
Message-ID: <esj092$qjv$1@news.Stanford.EDU>
References: <paun-46D856.17033404032007@nntp.stanford.edu> <esfvss$s6b$1@news.Stanford.EDU> <esi5t9$6f4$2@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173161058 27263 127.0.0.1 (6 Mar 2007 06:04:18 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
In-Reply-To: <esi5t9$6f4$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12171

I think, this problem happens in the absence of TIME-WAIT. I put in a 
wait time after one side sends the final ack and this problem seems to 
have dissappeared. Did someone else notice it too?

Paul Tarjan (TA) wrote:

> Greg Nelson wrote:
>> There's some discussion about this under "Errors from stcp".  A lot of 
>> us are getting it.  It seems to be a problem with the underlying code 
>> and it happens when one side closes the connection (the actual TCP 
>> socket that's simulating the network layer, not STCP) before the other 
>> side is done.
>>
>> No word from the TAs yet...
> 
> We are unable to reproduce this problem. Could you send me a test case 
> that causes this assertion on every run?
> 
> If anyone finds out the issue and can make a patch, please also send 
> that to me :)
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns EINVAL
Date: Tue, 6 Mar 2007 06:08:24 +0000 (UTC)
Lines: 23
Distribution: su
Message-ID: <esj0go$qkr$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU> <esif2l$dq7$1@news.Stanford.EDU> <esihde$fd3$1@news.Stanford.EDU> <esir28$n9k$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1173161304 27291 171.64.15.6 (6 Mar 2007 06:08:24 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12172


I think it's the same issue. 

 timeval tv_timeout;
>        timespec timeout;
>
>            gettimeofday(&tv_timeout, NULL);
>            timeout.tv_sec = tv_timeout.tv_sec;
>            timeout.tv_nsec = tv_timeout.tv_usec * 1000;
>
>            timeout.tv_sec += ctx->rto / 1000000;
>            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;

Above you should check if timeout.tv_nsec is > 1 billion.
Then subtract 1 billion from tv_nsec and 1 to sec.


Randy Jennings <randyj@stanford.edu> wrote:
> >I think that's a different assertion, Randy.

> Sorry, my bad.  I'm not sure then. 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxy get
Date: Tue, 6 Mar 2007 06:09:51 +0000 (UTC)
Organization: Your Company
Lines: 8
Distribution: su
Message-ID: <Xns98EAE1775659Achunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173161391 26545 128.12.22.217 (6 Mar 2007 06:09:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12173

hi, (for unreliable mode)

my server/client works perfectly,


but my proxyget sometimes times out... why?


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Mon, 05 Mar 2007 22:32:27 -0800
Lines: 66
Distribution: su
Message-ID: <esj1tj$rhn$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173162740 28215 127.0.0.1 (6 Mar 2007 06:32:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12174

Chun Kai Wang wrote:
> But if we use implementation 2, we might be re-transmitting packet 6 
> more than 5 times. no?
> 
> suppose packet 1 is dropped 4x and packet 3 is dropped 4x, then that 
> means packet 6 is retransmitted 8x at least but since we reset the 
> counter every useful ack, we will be able to do this... that's ok?
> 
> 
> 
> 
> 
> 
> Jin Wang <jinwang@stanford.edu> wrote in news:esiqqp$n4v$1
> @news.Stanford.EDU:
> 
>> Chun Kai Wang wrote:
>>> so, is this correct?
>>>
>>> suppose RTT = 2 seconds, and RTO = 2*RTT
>>>
>>> packet 1 sent at 1 sec 
>>> packet 2 sent at 1.1 sec
>>> packet 3 sent at 1.2 sec
>>> packet 4 sent at 1.3 sec
>>> packet 5 sent at 1.4 sec
>>> packet 6 sent at 1.5 sec
>>>
>>>
>>> suppose packet 1 is dropped.
>>>
>>> since packet 1 is dropped, even if 2-6 reach the destination, they 
>>> cannot be acknowledged, thus,
>>>
>>> packet 1 will be retransmitted when RTO,
>>>
>>> then packet 2 will timeout before packet 1 since packet 1's 
> retransmit 
>>> was after packet 2's first transmit,
>>>
>>> thus, when packet 2 timesout, packet 1 and 2 are sent again, even if 
>>> packet 1 has not timed out yet.
>>>
>>> this will cascade, and the link will fail just because packet 1 was 
>>> dropped, since # times packet 1 was retransmitted > 5.
>>>
>>>
>>> is this what is suppose to happen?
>> No
>>
>>> because if it is, i think it makes more sense to have 1 timeout 
> value, 
>>> and resend everything in the buffer when timeout occurs, and reset 
>>> timeout when a useful ack (ack where it decreases the out-buffer) has 
>>> been received. this will minimize the amount of traffic... and is 
> more 
>>> efficient no?
>> This alternative is actually what is supposed to happen.
>>
> 

You use one counter per packet, but you only increment it if IT is the 
packet that times out, but you do resend everything outstanding when you 
get a time out waiting for an ack.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Deliverable for 3C
Date: Mon, 05 Mar 2007 23:19:49 -0800
Lines: 9
Distribution: su
Message-ID: <C2125615.8F9F%jpettit@stanford.edu>
References: <esiunt$phh$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173165591 310 127.0.0.1 (6 Mar 2007 07:19:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Deliverable for 3C
Thread-Index: Acdfv9MxEYuymcuzEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12175

> In 3C, are we required to submit our own proxy, or is it optional?

Don't bother if you didn't make the changes to make it work with STCP.
However, please note in your README that you want to use the reference proxy
for this milestone.

--Justin


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 6 Mar 2007 00:23:14 -0700
Lines: 77
Distribution: su
Message-ID: <esj4t5$iu$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173165798 606 127.0.0.1 (6 Mar 2007 07:23:18 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12176

David,

I must be misinterpreting your post.  The third bullet point in the 
"retransmissions" section of the handout essentially says that no packet can 
ever be transmitted more than six times.  Don't you agree?

--Kevin

"David Erickson" <derickso@stanford.edu> wrote in message 
news:esj1tj$rhn$1@news.Stanford.EDU...
> Chun Kai Wang wrote:
>> But if we use implementation 2, we might be re-transmitting packet 6 more 
>> than 5 times. no?
>>
>> suppose packet 1 is dropped 4x and packet 3 is dropped 4x, then that 
>> means packet 6 is retransmitted 8x at least but since we reset the 
>> counter every useful ack, we will be able to do this... that's ok?
>>
>>
>>
>>
>>
>>
>> Jin Wang <jinwang@stanford.edu> wrote in news:esiqqp$n4v$1
>> @news.Stanford.EDU:
>>
>>> Chun Kai Wang wrote:
>>>> so, is this correct?
>>>>
>>>> suppose RTT = 2 seconds, and RTO = 2*RTT
>>>>
>>>> packet 1 sent at 1 sec packet 2 sent at 1.1 sec
>>>> packet 3 sent at 1.2 sec
>>>> packet 4 sent at 1.3 sec
>>>> packet 5 sent at 1.4 sec
>>>> packet 6 sent at 1.5 sec
>>>>
>>>>
>>>> suppose packet 1 is dropped.
>>>>
>>>> since packet 1 is dropped, even if 2-6 reach the destination, they 
>>>> cannot be acknowledged, thus,
>>>>
>>>> packet 1 will be retransmitted when RTO,
>>>>
>>>> then packet 2 will timeout before packet 1 since packet 1's
>> retransmit
>>>> was after packet 2's first transmit,
>>>>
>>>> thus, when packet 2 timesout, packet 1 and 2 are sent again, even if 
>>>> packet 1 has not timed out yet.
>>>>
>>>> this will cascade, and the link will fail just because packet 1 was 
>>>> dropped, since # times packet 1 was retransmitted > 5.
>>>>
>>>>
>>>> is this what is suppose to happen?
>>> No
>>>
>>>> because if it is, i think it makes more sense to have 1 timeout
>> value,
>>>> and resend everything in the buffer when timeout occurs, and reset 
>>>> timeout when a useful ack (ack where it decreases the out-buffer) has 
>>>> been received. this will minimize the amount of traffic... and is
>> more
>>>> efficient no?
>>> This alternative is actually what is supposed to happen.
>>>
>>
>
> You use one counter per packet, but you only increment it if IT is the 
> packet that times out, but you do resend everything outstanding when you 
> get a time out waiting for an ack.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Deliverable for 3C
Date: Mon, 5 Mar 2007 23:38:48 -0800
Lines: 18
Distribution: su
Message-ID: <esj5qb$12r$1@news.Stanford.EDU>
References: <esiunt$phh$1@news.Stanford.EDU> <C2125615.8F9F%jpettit@stanford.edu>
X-Trace: news.Stanford.EDU 1173166731 1115 127.0.0.1 (6 Mar 2007 07:38:51 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12177

Just to be sure... The only task in 3C is to make our proxy work with STCP, 
right? Or to put it in a different way... those who choose to use the 
reference proxy have nothing to do for 3C?

"Justin Pettit" <jpettit@stanford.edu> wrote in message 
news:C2125615.8F9F%jpettit@stanford.edu...
>> In 3C, are we required to submit our own proxy, or is it optional?
>
> Don't bother if you didn't make the changes to make it work with STCP.
> However, please note in your README that you want to use the reference 
> proxy
> for this milestone.
>
> --Justin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Deliverable for 3C
Date: Mon, 05 Mar 2007 23:44:09 -0800
Lines: 10
Distribution: su
Message-ID: <C2125BC9.8FA9%jpettit@stanford.edu>
References: <esiunt$phh$1@news.Stanford.EDU> <C2125615.8F9F%jpettit@stanford.edu> <esj5qb$12r$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173167052 1362 127.0.0.1 (6 Mar 2007 07:44:12 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Deliverable for 3C
Thread-Index: AcdfwzlseEEMOsu2EduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12178

> Just to be sure... The only task in 3C is to make our proxy work with STCP,
> right? Or to put it in a different way... those who choose to use the
> reference proxy have nothing to do for 3C?

Correct.  Just make sure that your transport.c works VERY well with the
reference proxy that you were given in the source tarball.

--Justin 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Mon, 05 Mar 2007 23:50:53 -0800
Lines: 16
Distribution: su
Message-ID: <esj6gl$1ao$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU> <esj4t5$iu$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173167445 1368 127.0.0.1 (6 Mar 2007 07:50:46 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esj4t5$iu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12179

Kevin Hart wrote:
> David,
> 
> I must be misinterpreting your post.  The third bullet point in the 
> "retransmissions" section of the handout essentially says that no packet can 
> ever be transmitted more than six times.  Don't you agree?

Woops missed that FAQ entry, take the FAQ as gospel.  I do disagree with 
it though, if you have a particularly lossy connection you could hit a 
bad spell with a lot of outstanding stuff real quickly and imo you 
wouldnt want to terminate the connection just because a packet was 
retransmitted 6 times, where it was not the one that was lost and 
awaiting acks, but happened to be retransmitted because previous packets 
were lost, and it was in flight.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PROXY...
Date: Tue, 6 Mar 2007 08:22:50 +0000 (UTC)
Organization: Your Company
Lines: 1
Distribution: su
Message-ID: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173169370 4205 128.12.22.217 (6 Mar 2007 08:22:50 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12180

how come my proxyget works but i can't see websites on firefox????
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PROXY...
Date: Tue, 6 Mar 2007 00:26:36 -0800
Lines: 7
Distribution: su
Message-ID: <esj8jv$61s$1@news.Stanford.EDU>
References: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103>
X-Trace: news.Stanford.EDU 1173169599 6204 127.0.0.1 (6 Mar 2007 08:26:39 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12181

Because firefox doesn't use STCP.

"Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
news:Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103...
> how come my proxyget works but i can't see websites on firefox???? 


.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PROXY...
Date: Tue, 6 Mar 2007 08:29:45 +0000 (UTC)
Organization: Your Company
Lines: 17
Distribution: su
Message-ID: <Xns98EB50B73E4Fchunkaiwstanfordedu@171.64.14.103>
References: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103> <esj8jv$61s$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173169785 4205 128.12.22.217 (6 Mar 2007 08:29:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12182

.... then how do i test it? just use proxyget??? i thought putting in so 
much work will get me to use everything all together?



"Riju Kallivalappil" <riju@stanford.edu> wrote in news:esj8jv$61s$1
@news.Stanford.EDU:

> Because firefox doesn't use STCP.
> 
> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
> news:Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103...
>> how come my proxyget works but i can't see websites on firefox???? 
> 
> 
> 

.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 6 Mar 2007 00:30:40 -0800
Lines: 23
Distribution: su
Message-ID: <esj8ri$68i$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU> <esj4t5$iu$1@news.Stanford.EDU> <esj6gl$1ao$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173169842 6418 127.0.0.1 (6 Mar 2007 08:30:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12183

In the Go-back-N model, I don't see how the number of retransmissions of a 
newer packet could ever be more than that of an older packet.

"David Erickson" <derickso@stanford.edu> wrote in message 
news:esj6gl$1ao$1@news.Stanford.EDU...
> Kevin Hart wrote:
>> David,
>>
>> I must be misinterpreting your post.  The third bullet point in the 
>> "retransmissions" section of the handout essentially says that no packet 
>> can ever be transmitted more than six times.  Don't you agree?
>
> Woops missed that FAQ entry, take the FAQ as gospel.  I do disagree with 
> it though, if you have a particularly lossy connection you could hit a bad 
> spell with a lot of outstanding stuff real quickly and imo you wouldnt 
> want to terminate the connection just because a packet was retransmitted 6 
> times, where it was not the one that was lost and awaiting acks, but 
> happened to be retransmitted because previous packets were lost, and it 
> was in flight.
>
> -David 


.

Path: shelby.stanford.edu!not-for-mail
From: "David Gobaud" <gobaudd@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: STCP bug in stcp_wait_for_event -> pthread_cond_timedwait returns EINVAL
Date: Tue, 6 Mar 2007 00:32:40 -0800
Lines: 56
Distribution: su
Message-ID: <esj8vg$6bb$1@news.Stanford.EDU>
References: <esie7k$cvt$1@news.Stanford.EDU> <esif2l$dq7$1@news.Stanford.EDU> <esihde$fd3$1@news.Stanford.EDU>
NNTP-Posting-Host: norad.stanford.edu
X-Trace: news.Stanford.EDU 1173169968 6507 128.12.81.44 (6 Mar 2007 08:32:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12184

That fixed it! Thank you!! That was the most annoying problem all quarter!! 
Wasted at least 2 hours trying to find the problem... Not only that but 
these uint64_ts... seems one can't just put 1000000000 in code and use them 
but you have to cast them to uint64_ts or something is getting cut off or 
something... VERY annoying.

-- 
David Gobaud

"Greg Nelson" <grourk@stanford.edu> wrote in message 
news:esihde$fd3$1@news.Stanford.EDU...
>I think that's a different assertion, Randy.
>
> The EINVAL thing is probably due to the tv_nsec field being greater than 1 
> billion in the timespec struct you pass as abstime to stcp_wait_for_event. 
> Make sure you "carry" the 1 second to the tv_sec field and subtract it 
> from the tv_nsec field.
>
> Greg
>
> Randy Jennings wrote:
>> See previous thread, "Failed Assertion".
>> "David Gobaud" <gobaudd@stanford.edu> wrote in message 
>> news:esie7k$cvt$1@news.Stanford.EDU...
>>> Hi,
>>>
>>> I'm getting the following
>>>
>>> server: stcp_api.c:107: unsigned int stcp_wait_for_event(mysocket_t, 
>>> unsigned int, const timespec*): Assertion `0' failed.
>>> Abort
>>>
>>> The assertion is caused in stcp_api.c line 107 when 
>>> pthread_cond_timedwait returns EINVAL docs say it can be a 
>>> mutex/condition variable problem or a timeout problem. I'm calculating 
>>> timeout with
>>>
>>>        timeval tv_timeout;
>>>        timespec timeout;
>>>
>>>            gettimeofday(&tv_timeout, NULL);
>>>            timeout.tv_sec = tv_timeout.tv_sec;
>>>            timeout.tv_nsec = tv_timeout.tv_usec * 1000;
>>>
>>>            timeout.tv_sec += ctx->rto / 1000000;
>>>            timeout.tv_nsec += (ctx->rto % 1000000) * 1000;
>>>
>>> am I missing something?
>>>
>>> -- 
>>> Thank you,
>>> David Gobaud
>>>
>>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Chun Kai Wang <chunkaiw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA4 due date
Date: Tue, 6 Mar 2007 10:01:58 +0000 (UTC)
Organization: Your Company
Lines: 1
Distribution: su
Message-ID: <Xns98EB14ADF827Dchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: rescomp-06-59601.stanford.edu
X-Trace: news.Stanford.EDU 1173175318 11064 128.12.22.217 (6 Mar 2007 10:01:58 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Xnews/5.04.25
Xref: shelby.stanford.edu su.class.cs244a:12185

just to make sure, PA4 is due march 16 5pm right?
.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: reference proxy behavior
Date: Tue, 06 Mar 2007 07:25:38 -0800
Lines: 12
Distribution: su
Message-ID: <esk15k$e9$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab423a50.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173194740 457 171.66.58.80 (6 Mar 2007 15:25:40 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
Xref: shelby.stanford.edu su.class.cs244a:12186

Hi,

it seems like the reference proxy is massaging the message passed by 
proxyget somehow. For websites like www.cnn.com or www.stanford.edu, if 
I just pass the http request passed from proxyget, I get 400 bad request 
error (and I get the same result if I telnet and manually pass the 
request to those sites). But if I use the reference proxy, I get the 
correct response from the server. What am I missing here and are we 
supposed to have this functionality or is it okay to just pass the 
message as passed by proxyget?

Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: "manj" <manj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxyget + www.google.com
Date: Tue, 6 Mar 2007 08:35:20 -0800
Lines: 13
Distribution: su
Message-ID: <esk58d$4er$1@news.Stanford.EDU>
NNTP-Posting-Host: zeus2.stanford.edu
X-Trace: news.Stanford.EDU 1173198925 4571 128.12.137.163 (6 Mar 2007 16:35:25 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12187

Hi,

I am facing this weird bug, where whenever I try to connect to google.com 
using proxyget,  the server never closes the connection (i.e. I never get 
the event APP_CLOSE_REQUESTED and hence there is no connection tear down).

This occurs to me even in the reliable mode. Other websites work just fine.

Is anyone facing the same bug? Any clues as what could be wrong.

Manju 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA4 due date
Date: Tue, 06 Mar 2007 09:43:16 -0800
Lines: 6
Distribution: su
Message-ID: <C212E834.8FD2%jpettit@stanford.edu>
References: <Xns98EB14ADF827Dchunkaiwstanfordedu@171.64.14.103>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173202999 8773 127.0.0.1 (6 Mar 2007 17:43:19 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA4 due date
Thread-Index: AcdgFuuBKdIpcswKEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12188

> just to make sure, PA4 is due march 16 5pm right?

Yes.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 06 Mar 2007 10:57:43 -0800
Lines: 17
Distribution: su
Message-ID: <eskdiv$cmh$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU> <esj4t5$iu$1@news.Stanford.EDU> <esj6gl$1ao$1@news.Stanford.EDU> <esj8ri$68i$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173207455 13009 127.0.0.1 (6 Mar 2007 18:57:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esj8ri$68i$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12189

Riju Kallivalappil wrote:
> In the Go-back-N model, I don't see how the number of retransmissions of a 
> newer packet could ever be more than that of an older packet.

It depends on what you mean by older packet.  But imagine the situation 
that 1-10 are sent, and lets imagine 1-6 are all lost.  Thus 1-10 get 
retransmitted.  On the retransmission 2-7 are lost, so 2-10 get 
retransmitted.  Etc.  By continuing that you get to the point that 10 
has been retransmitted 5 times, but it may never have been lost, or only 
lost once, and you can move things around such that no previous packet 
was actually itself lost 5 times, but it was retransmitted more than 5 
times since previous packets being lost caused it to be retransmitted. 
And you wouldn't want to dump your connection just because of 5 packets 
being lost and retransmitted.  Anyway its a moot point, follow the faq 
for this assignment =)

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 6 Mar 2007 11:30:49 -0800
Lines: 25
Distribution: su
Message-ID: <eskfhb$egt$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU> <esj4t5$iu$1@news.Stanford.EDU> <esj6gl$1ao$1@news.Stanford.EDU> <esj8ri$68i$1@news.Stanford.EDU> <eskdiv$cmh$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173209452 14877 127.0.0.1 (6 Mar 2007 19:30:52 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12190

>> In the Go-back-N model, I don't see how the number of retransmissions of 
>> a newer packet could ever be more than that of an older packet.
>
> It depends on what you mean by older packet.  But imagine the situation 
> that 1-10 are sent, and lets imagine 1-6 are all lost.  Thus 1-10 get 
> retransmitted.  On the retransmission 2-7 are lost, so 2-10 get 
> retransmitted.  Etc.  By continuing that you get to the point that 10 has 
> been retransmitted 5 times, but it may never have been lost, or only lost 
> once, and you can move things around such that no previous packet was 
> actually itself lost 5 times, but it was retransmitted more than 5 times 
> since previous packets being lost caused it to be retransmitted. And you 
> wouldn't want to dump your connection just because of 5 packets being lost 
> and retransmitted.  Anyway its a moot point, follow the faq for this 
> assignment =)
>

But, the retransmission count for all packets (starting from the lost 
packet) before 10 will also be incremented. Hence, the retransmission count 
for an older packet (packet number < 10, in this case) will always be >= the 
retransmission count for packet 10. Keep in mind that the receiver buffers 
out of order packets. Am I missing something here?

I'm just trying to say that the FAQ makes perfect sense... :) 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: timeout ----- HELP!!!
Date: Tue, 06 Mar 2007 12:19:37 -0800
Lines: 37
Distribution: su
Message-ID: <eskicg$gv5$1@news.Stanford.EDU>
References: <Xns98EAC38D37EC7chunkaiwstanfordedu@171.64.14.103> <esiqqp$n4v$1@news.Stanford.EDU> <Xns98EADFE89F2C7chunkaiwstanfordedu@171.64.14.103> <esj1tj$rhn$1@news.Stanford.EDU> <esj4t5$iu$1@news.Stanford.EDU> <esj6gl$1ao$1@news.Stanford.EDU> <esj8ri$68i$1@news.Stanford.EDU> <eskdiv$cmh$1@news.Stanford.EDU> <eskfhb$egt$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173212369 17381 127.0.0.1 (6 Mar 2007 20:19:29 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <eskfhb$egt$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12191

Riju Kallivalappil wrote:
>>> In the Go-back-N model, I don't see how the number of retransmissions of 
>>> a newer packet could ever be more than that of an older packet.
>> It depends on what you mean by older packet.  But imagine the situation 
>> that 1-10 are sent, and lets imagine 1-6 are all lost.  Thus 1-10 get 
>> retransmitted.  On the retransmission 2-7 are lost, so 2-10 get 
>> retransmitted.  Etc.  By continuing that you get to the point that 10 has 
>> been retransmitted 5 times, but it may never have been lost, or only lost 
>> once, and you can move things around such that no previous packet was 
>> actually itself lost 5 times, but it was retransmitted more than 5 times 
>> since previous packets being lost caused it to be retransmitted. And you 
>> wouldn't want to dump your connection just because of 5 packets being lost 
>> and retransmitted.  Anyway its a moot point, follow the faq for this 
>> assignment =)
>>
> 
> But, the retransmission count for all packets (starting from the lost 
> packet) before 10 will also be incremented. Hence, the retransmission count 
> for an older packet (packet number < 10, in this case) will always be >= the 
> retransmission count for packet 10. Keep in mind that the receiver buffers 
> out of order packets. Am I missing something here?
> 
> I'm just trying to say that the FAQ makes perfect sense... :) 
> 
> 

My argument centers around my opinion that there is no reason to 
increment the retransmission count of any packets save the one that was 
actually lost in the network, indicated by a duplicate ack from the 
remote side, or a timeout, because I am of the opinion that that packet 
is the only one the sender knows for sure was lost, so just because its 
an optimization to send the rest that were in flight after it as well, 
does not mean the rest of them need to have their retransmission 
counters increased, since the other side may very well have them just 
fine its buffer.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: segv in proxyget
Date: Tue, 6 Mar 2007 20:35:26 +0000 (UTC)
Lines: 3
Distribution: su
Message-ID: <eskjae$hp0$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1173213326 18208 171.64.15.6 (6 Mar 2007 20:35:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12192


If I run proxyget -U m/c:port  without giving url then it seg faults.

.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PROXY...
Date: Tue, 06 Mar 2007 14:53:41 -0800
Lines: 26
Distribution: su
Message-ID: <eskrft$o6m$1@news.Stanford.EDU>
References: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103> <esj8jv$61s$1@news.Stanford.EDU> <Xns98EB50B73E4Fchunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173221693 24790 171.64.74.54 (6 Mar 2007 22:54:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98EB50B73E4Fchunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12193

The proxy, proxyget, your STCP, and external websites should all work 
together (plus your router, when you get to assignment 4).  The TCP 
stack on your machine may be slightly picky or buggy, resulting in 
Firefox being unable to talk through everything else.  It can still 
provide some useful debugging information if you can look at why Firefox 
isn't showing pages.

Clay

Chun Kai Wang wrote:
> ... then how do i test it? just use proxyget??? i thought putting in so 
> much work will get me to use everything all together?
> 
> 
> 
> "Riju Kallivalappil" <riju@stanford.edu> wrote in news:esj8jv$61s$1
> @news.Stanford.EDU:
> 
>> Because firefox doesn't use STCP.
>>
>> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
>> news:Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103...
>>> how come my proxyget works but i can't see websites on firefox???? 
>>
>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxy get
Date: Tue, 06 Mar 2007 14:54:53 -0800
Lines: 15
Distribution: su
Message-ID: <eskri4$o6m$2@news.Stanford.EDU>
References: <Xns98EAE1775659Achunkaiwstanfordedu@171.64.14.103>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173221765 24790 171.64.74.54 (6 Mar 2007 22:56:05 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <Xns98EAE1775659Achunkaiwstanfordedu@171.64.14.103>
Xref: shelby.stanford.edu su.class.cs244a:12194

It's hard to say without knowing more specifics.  Is it a particular 
server/domain that causes it to time out?  Large pages?  After things 
have been running for a while?  etc...

Clay

Chun Kai Wang wrote:
> hi, (for unreliable mode)
> 
> my server/client works perfectly,
> 
> 
> but my proxyget sometimes times out... why?
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: reference proxy behavior
Date: Tue, 06 Mar 2007 14:56:31 -0800
Lines: 19
Distribution: su
Message-ID: <eskrl6$o6m$3@news.Stanford.EDU>
References: <esk15k$e9$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173221863 24790 171.64.74.54 (6 Mar 2007 22:57:43 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esk15k$e9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12195

If your proxy passed the tests for assignment 1, there are no other 
changes that you need to make.  What exactly is the request that is 
causing the discrepancy?

Clay

Chee-Hyung Yoon wrote:
> Hi,
> 
> it seems like the reference proxy is massaging the message passed by 
> proxyget somehow. For websites like www.cnn.com or www.stanford.edu, if 
> I just pass the http request passed from proxyget, I get 400 bad request 
> error (and I get the same result if I telnet and manually pass the 
> request to those sites). But if I use the reference proxy, I get the 
> correct response from the server. What am I missing here and are we 
> supposed to have this functionality or is it okay to just pass the 
> message as passed by proxyget?
> 
> Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Gain Eternal Fame
Date: Tue, 06 Mar 2007 15:03:50 -0800
Lines: 22
Distribution: su
Message-ID: <esks2u$oqn$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173222302 25431 171.64.74.54 (6 Mar 2007 23:05:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:12196

At this point in the course, you've all had a chance to work with VNS, 
the system that we use to enable the sr router assignment.  VNS is 
actually used by a number of other schools around the country, and is 
currently in the planning stages of a major upgrade.  As part of this 
process, we're looking for a new name for the system.  VNS (Virtual 
Network System) is a little stodgy and boring.  It also doesn't really 
explain what VNS really is (or will be): a neat way to provide students 
and researchers with an environment in which they can play with 
low-level networking without needing to learn hardware design or kernel 
coding.

We're hoping to come up with something more descriptive and more 
whimsical as part of our new design.  If you have an idea for a new name 
for VNS (Nick's current favorite is 'netplumber'), please submit it to 
ccollier@stanford.edu.  The winning entry (as judged by a jury of... 
some people) will become the new name of VNS version 2, and the author 
will get to be credited on our webpage, thus earning a permanent place 
in history.  Also, there may be fabulous prizes of some sort.

Thanks for your help!

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PROXY...
Date: Tue, 6 Mar 2007 15:29:27 -0800
Lines: 38
Distribution: su
Message-ID: <esktgp$q75$1@news.Stanford.EDU>
References: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103> <esj8jv$61s$1@news.Stanford.EDU> <Xns98EB50B73E4Fchunkaiwstanfordedu@171.64.14.103> <eskrft$o6m$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173223769 26853 127.0.0.1 (6 Mar 2007 23:29:29 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12197

Clay,
 I'm a bit confused by what you said. Are you saying that a regular Firefox 
will work fine with the STCP proxy, if the TCP stack is not buggy? My 
understanding of STCP is that it is a layer built above regular TCP. So, if 
I send an STCP packet to firefox, I'm not sure how firefox would interpret 
that.

-riju

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eskrft$o6m$1@news.Stanford.EDU...
> The proxy, proxyget, your STCP, and external websites should all work 
> together (plus your router, when you get to assignment 4).  The TCP stack 
> on your machine may be slightly picky or buggy, resulting in Firefox being 
> unable to talk through everything else.  It can still provide some useful 
> debugging information if you can look at why Firefox isn't showing pages.
>
> Clay
>
> Chun Kai Wang wrote:
>> ... then how do i test it? just use proxyget??? i thought putting in so 
>> much work will get me to use everything all together?
>>
>>
>>
>> "Riju Kallivalappil" <riju@stanford.edu> wrote in news:esj8jv$61s$1
>> @news.Stanford.EDU:
>>
>>> Because firefox doesn't use STCP.
>>>
>>> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
>>> news:Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103...
>>>> how come my proxyget works but i can't see websites on firefox????
>>>
>>>
>> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA#4
Date: Tue, 6 Mar 2007 16:32:52 -0800
Lines: 11
Distribution: su
Message-ID: <esl15s$k9$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173227516 649 127.0.0.1 (7 Mar 2007 00:31:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12198

I know a bunch of stuff is going on (grading, PA3, prep for final, etc.), 
but I was wondering if there was some code/topology would be released for 
PA4, perhaps with an update to the web page?  I am not planning on working 
on it until Friday, but I wanted to put feelers out about it.

Sincerely,
Randy Jennings

The squirrels are your friends!


.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: reference proxy behavior
Date: Tue, 06 Mar 2007 16:41:23 -0800
Lines: 26
Distribution: su
Message-ID: <esl1nm$144$1@news.Stanford.EDU>
References: <esk15k$e9$1@news.Stanford.EDU> <eskrl6$o6m$3@news.Stanford.EDU>
NNTP-Posting-Host: dnab423a50.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173228086 1156 171.66.58.80 (7 Mar 2007 00:41:26 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
In-Reply-To: <eskrl6$o6m$3@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12199

That's what I thought. The request is just a standard one generated by 
proxyget, which would be something like:

"GET http://www.stanford.edu HTTP/1.0\r\n"


Clay Collier wrote:
> If your proxy passed the tests for assignment 1, there are no other 
> changes that you need to make.  What exactly is the request that is 
> causing the discrepancy?
> 
> Clay
> 
> Chee-Hyung Yoon wrote:
>> Hi,
>>
>> it seems like the reference proxy is massaging the message passed by 
>> proxyget somehow. For websites like www.cnn.com or www.stanford.edu, 
>> if I just pass the http request passed from proxyget, I get 400 bad 
>> request error (and I get the same result if I telnet and manually pass 
>> the request to those sites). But if I use the reference proxy, I get 
>> the correct response from the server. What am I missing here and are 
>> we supposed to have this functionality or is it okay to just pass the 
>> message as passed by proxyget?
>>
>> Chee-Hyung
.

Path: shelby.stanford.edu!not-for-mail
From: Scott Lulovics <slulovic@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: TCP checksum failures
Date: Tue, 06 Mar 2007 17:34:37 -0800
Lines: 14
Distribution: su
Message-ID: <esl4q8$3o4$1@news.Stanford.EDU>
NNTP-Posting-Host: callandor.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173231240 3844 128.12.197.0 (7 Mar 2007 01:34:00 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
Xref: shelby.stanford.edu su.class.cs244a:12200

When running a proxy (mine or the provided) on an x86 arch (myths) and 
proxyget on x86-64 arch (my desktop), I get tcp checksum failures from 
the underlying code on the proxy side. Specifically, 
_mysock_verify_checksum in tcp_sum.c returns FALSE. It works fine when 
both are run from the myths or both are run from x86-64.

The checksum stuff is entirely out of our hands, I believe, so should I 
be worried about this?

Also, just to be sure, is there a penalty for using the reference proxy 
in this assignment?

Thanks,
Scott
.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Running on elaines
Date: Tue, 6 Mar 2007 17:34:46 -0800
Lines: 8
Distribution: su
Message-ID: <esl4ro$3oq$1@news.Stanford.EDU>
NNTP-Posting-Host: dn800c1708.stanford.edu
X-Trace: news.Stanford.EDU 1173231288 3866 128.12.23.8 (7 Mar 2007 01:34:48 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12201

I am having some trouble running on the elaines.  The assignment says we 
should be able to.  For one thing, the reference proxy is not compiled for 
the elaines.  Additionally, some of the debugging information for the rest 
of the files is missing.  Anyone have any insight into this?

--Alicia 


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA#4
Date: Tue, 06 Mar 2007 17:45:37 -0800
Lines: 16
Distribution: su
Message-ID: <esl5fu$448$1@news.Stanford.EDU>
References: <esl15s$k9$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173231934 4232 127.0.0.1 (7 Mar 2007 01:45:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esl15s$k9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12202

Randy Jennings wrote:
> I know a bunch of stuff is going on (grading, PA3, prep for final, etc.), 
> but I was wondering if there was some code/topology would be released for 
> PA4, perhaps with an update to the web page?  I am not planning on working 
> on it until Friday, but I wanted to put feelers out about it.
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends!
> 
> 

Clay is planning on getting new topologies out tonight.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Tom Deane" <tdeane@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxyget protocol
Date: Tue, 6 Mar 2007 18:03:19 -0800
Lines: 6
Distribution: su
Message-ID: <esl6ho$4uu$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-48759.stanford.edu
X-Trace: news.Stanford.EDU 1173233016 5086 128.12.197.184 (7 Mar 2007 02:03:36 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12203

The provided proxy.a doesn't seem to require "http://" to be put in front of 
a wesbite when you call GET.  However, I have the requirement that you have 
to specify the protocol in my PA1 proxy.... is that ok or do I need to 
change that?


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PROXY...
Date: Tue, 06 Mar 2007 19:48:17 -0800
Lines: 48
Distribution: su
Message-ID: <eslcob$9he$1@news.Stanford.EDU>
References: <Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103> <esj8jv$61s$1@news.Stanford.EDU> <Xns98EB50B73E4Fchunkaiwstanfordedu@171.64.14.103> <eskrft$o6m$1@news.Stanford.EDU> <esktgp$q75$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173239372 9774 171.64.74.54 (7 Mar 2007 03:49:32 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esktgp$q75$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12204

Sorry- yes, you're correct.  I was thinking ahead to assignment 4.  For 
assignment 3, since the server-side of the proxy is using STCP on top of 
a custom transport layer, trying to talk to the proxy with a normal 
client will not work at all.

On the same topic, it should be possible to port Firefox to run on top 
of STCP, if you would like some additional testing.

Clay


Riju Kallivalappil wrote:
> Clay,
>  I'm a bit confused by what you said. Are you saying that a regular Firefox 
> will work fine with the STCP proxy, if the TCP stack is not buggy? My 
> understanding of STCP is that it is a layer built above regular TCP. So, if 
> I send an STCP packet to firefox, I'm not sure how firefox would interpret 
> that.
> 
> -riju
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:eskrft$o6m$1@news.Stanford.EDU...
>> The proxy, proxyget, your STCP, and external websites should all work 
>> together (plus your router, when you get to assignment 4).  The TCP stack 
>> on your machine may be slightly picky or buggy, resulting in Firefox being 
>> unable to talk through everything else.  It can still provide some useful 
>> debugging information if you can look at why Firefox isn't showing pages.
>>
>> Clay
>>
>> Chun Kai Wang wrote:
>>> ... then how do i test it? just use proxyget??? i thought putting in so 
>>> much work will get me to use everything all together?
>>>
>>>
>>>
>>> "Riju Kallivalappil" <riju@stanford.edu> wrote in news:esj8jv$61s$1
>>> @news.Stanford.EDU:
>>>
>>>> Because firefox doesn't use STCP.
>>>>
>>>> "Chun Kai Wang" <chunkaiw@stanford.edu> wrote in message 
>>>> news:Xns98EB3DF95F1Echunkaiwstanfordedu@171.64.14.103...
>>>>> how come my proxyget works but i can't see websites on firefox????
>>>>
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Running on elaines
Date: Tue, 06 Mar 2007 19:50:19 -0800
Lines: 15
Distribution: su
Message-ID: <eslcs5$9he$2@news.Stanford.EDU>
References: <esl4ro$3oq$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173239496 9774 171.64.74.54 (7 Mar 2007 03:51:36 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esl4ro$3oq$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12205

You're either looking at an old copy of the assignment, or we missed a 
reference somewhere- the elaines are Solaris machines, and all of the 
stub code is Linux-based.  You'll need to run from the myths or one of 
the other x86 Linux machines.

Clay
Alicia Chen wrote:
> I am having some trouble running on the elaines.  The assignment says we 
> should be able to.  For one thing, the reference proxy is not compiled for 
> the elaines.  Additionally, some of the debugging information for the rest 
> of the files is missing.  Anyone have any insight into this?
> 
> --Alicia 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxyget protocol
Date: Tue, 06 Mar 2007 19:51:50 -0800
Lines: 11
Distribution: su
Message-ID: <eslcv0$9he$3@news.Stanford.EDU>
References: <esl6ho$4uu$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173239586 9774 171.64.74.54 (7 Mar 2007 03:53:06 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esl6ho$4uu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12206

Either behavior is acceptable.

Clay

Tom Deane wrote:
> The provided proxy.a doesn't seem to require "http://" to be put in front of 
> a wesbite when you call GET.  However, I have the requirement that you have 
> to specify the protocol in my PA1 proxy.... is that ok or do I need to 
> change that?
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: TCP checksum failures
Date: Tue, 06 Mar 2007 20:27:33 -0800
Lines: 19
Distribution: su
Message-ID: <eslf23$bbq$1@news.Stanford.EDU>
References: <esl4q8$3o4$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173241735 11642 171.64.74.54 (7 Mar 2007 04:28:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esl4q8$3o4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12207

We won't be doing any testing against 64-bit architectures- so this 
shouldn't be anything to worry about.

Clay
Scott Lulovics wrote:
> When running a proxy (mine or the provided) on an x86 arch (myths) and 
> proxyget on x86-64 arch (my desktop), I get tcp checksum failures from 
> the underlying code on the proxy side. Specifically, 
> _mysock_verify_checksum in tcp_sum.c returns FALSE. It works fine when 
> both are run from the myths or both are run from x86-64.
> 
> The checksum stuff is entirely out of our hands, I believe, so should I 
> be worried about this?
> 
> Also, just to be sure, is there a penalty for using the reference proxy 
> in this assignment?
> 
> Thanks,
> Scott
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: HW 4 Topologies are Out
Date: Tue, 06 Mar 2007 20:30:17 -0800
Lines: 10
Distribution: su
Message-ID: <eslf73$bbq$2@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173241895 11642 171.64.74.54 (7 Mar 2007 04:31:35 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:12208

Topologies for homework four were sent out tonight.  They should have 
the same topology IDs and IP address allocations as your previous 
topology- if not, use the new addresses.  Let me know via email if there 
are any problems.

Additionally, I got a few bounceback messages when the topos were sent. 
  If you didn't receive a message regarding your topology today, please 
let me know.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: Re: Failed Assertion
Date: Tue, 6 Mar 2007 21:38:05 -0700
Lines: 31
Distribution: su
Message-ID: <eslfjg$bo1$1@news.Stanford.EDU>
References: <paun-46D856.17033404032007@nntp.stanford.edu> <esfvss$s6b$1@news.Stanford.EDU> <esi5t9$6f4$2@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173242289 12033 127.0.0.1 (7 Mar 2007 04:38:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12209

Here's a test case that seems to cause the assertion every time, or just 
about:

Run proxyget on the same host as the reference proxy.
Use -U mode for both.
Try this url: hub.ebay.com/buy

Do you see the assert in proxyget?  It's the revents & 0x008 assert in 
network_recv_thread_func.

For some reason my proxy doesn't fail on this.  :-)

--Kevin

"Paul Tarjan (TA)" <ptarjan@stanford.edu> wrote in message 
news:esi5t9$6f4$2@news.Stanford.EDU...
> Greg Nelson wrote:
>> There's some discussion about this under "Errors from stcp".  A lot of us 
>> are getting it.  It seems to be a problem with the underlying code and it 
>> happens when one side closes the connection (the actual TCP socket that's 
>> simulating the network layer, not STCP) before the other side is done.
>>
>> No word from the TAs yet...
>
> We are unable to reproduce this problem. Could you send me a test case 
> that causes this assertion on every run?
>
> If anyone finds out the issue and can make a patch, please also send that 
> to me :) 


.

Path: shelby.stanford.edu!not-for-mail
From: Kristjan Petursson <kristjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: segv in proxyget
Date: Tue, 06 Mar 2007 22:17:15 -0800
Lines: 4
Distribution: su
Message-ID: <esllh8$fml$1@news.Stanford.EDU>
References: <eskjae$hp0$1@news.Stanford.EDU>
NNTP-Posting-Host: kristjan.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173248360 16085 128.12.132.218 (7 Mar 2007 06:19:20 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <eskjae$hp0$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12210

Dinesh Gupta wrote:
> If I run proxyget -U m/c:port  without giving url then it seg faults.
> 
Serves you right :-p
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW 4 Topologies are Out
Date: Tue, 06 Mar 2007 23:24:47 -0800
Lines: 17
Distribution: su
Message-ID: <eslpbq$ir8$1@news.Stanford.EDU>
References: <eslf73$bbq$2@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173252282 19304 128.12.194.72 (7 Mar 2007 07:24:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <eslf73$bbq$2@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12211

Clay Collier wrote:
> Topologies for homework four were sent out tonight.  They should have 
> the same topology IDs and IP address allocations as your previous 
> topology- if not, use the new addresses.  Let me know via email if there 
> are any problems.
> 
> Additionally, I got a few bounceback messages when the topos were sent. 
>  If you didn't receive a message regarding your topology today, please 
> let me know.
> 
> Clay

Do we need additional code as well? The project spec mentions 
echo_client_main.c and echo_server_main.c. I don't see them among my 
project files.

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: HW 4 Topologies are Out
Date: Tue, 06 Mar 2007 23:33:38 -0800
Lines: 21
Distribution: su
Message-ID: <eslpuu$j77$1@news.Stanford.EDU>
References: <eslf73$bbq$2@news.Stanford.EDU> <eslpbq$ir8$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173252895 19687 171.64.74.54 (7 Mar 2007 07:34:55 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <eslpbq$ir8$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12212

Those should be available tomorrow.

Clay
Yangfan Wang wrote:
> Clay Collier wrote:
>> Topologies for homework four were sent out tonight.  They should have 
>> the same topology IDs and IP address allocations as your previous 
>> topology- if not, use the new addresses.  Let me know via email if 
>> there are any problems.
>>
>> Additionally, I got a few bounceback messages when the topos were 
>> sent.  If you didn't receive a message regarding your topology today, 
>> please let me know.
>>
>> Clay
> 
> Do we need additional code as well? The project spec mentions 
> echo_client_main.c and echo_server_main.c. I don't see them among my 
> project files.
> 
> -Yangfan
.

Path: shelby.stanford.edu!myth2.Stanford.EDU!ryanchen
From: Ryan Chen <ryanchen@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA3 Milestone C: Modify server side or client side?
Date: Wed, 7 Mar 2007 00:32:49 -0800
Lines: 8
Distribution: su
Message-ID: <Pine.LNX.4.44.0703070028550.20000-100000@myth2.Stanford.EDU>
NNTP-Posting-Host: myth2.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1173256372 25641 171.64.15.175 (7 Mar 2007 08:32:52 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:12213

After reading the Milesonte HW3.C "what I need to do" on the website. I am
a little bit confused. It says that "You only need to change the way your
proxy works on the server (passive) side!" But looking at the diagram,
isn't the "CLIENT" supposed to talk STCP with our proxy rather than the
server? Why are we modifying the server side to speak STCP rather than the
client side to speak STCP? I think I am missing something big here, can
someone elaborate on this? Thanks a lot.

.

Path: shelby.stanford.edu!not-for-mail
From: Neelima Balakrishnan <bneelima@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 Milestone C: Modify server side or client side?
Date: Wed, 07 Mar 2007 00:35:40 -0800
Lines: 15
Distribution: su
Message-ID: <esltgo$p2f$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0703070028550.20000-100000@myth2.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173256537 25679 127.0.0.1 (7 Mar 2007 08:35:37 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <Pine.LNX.4.44.0703070028550.20000-100000@myth2.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12214

Ryan Chen wrote:
> After reading the Milesonte HW3.C "what I need to do" on the website. I am
> a little bit confused. It says that "You only need to change the way your
> proxy works on the server (passive) side!" But looking at the diagram,
> isn't the "CLIENT" supposed to talk STCP with our proxy rather than the
> server? Why are we modifying the server side to speak STCP rather than the
> client side to speak STCP? I think I am missing something big here, can
> someone elaborate on this? Thanks a lot.
> 
I think what it means to say is to modify the server side of the proxy 
(which is the side it uses to talk to our client - proxyget). The proxy 
acts as a client to the actual web server and hence should not be modified.

Neelima

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA3 Milestone C: Modify server side or client side?
Date: Wed, 07 Mar 2007 00:38:28 -0800
Lines: 16
Distribution: su
Message-ID: <C213BA04.901F%jpettit@stanford.edu>
References: <Pine.LNX.4.44.0703070028550.20000-100000@myth2.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173256710 25875 127.0.0.1 (7 Mar 2007 08:38:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PA3 Milestone C: Modify server side or client side?
Thread-Index: Acdgk/pZOKc1eMyHEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12215

> After reading the Milesonte HW3.C "what I need to do" on the website. I am
> a little bit confused. It says that "You only need to change the way your
> proxy works on the server (passive) side!" But looking at the diagram,
> isn't the "CLIENT" supposed to talk STCP with our proxy rather than the
> server? Why are we modifying the server side to speak STCP rather than the
> client side to speak STCP? I think I am missing something big here, can
> someone elaborate on this? Thanks a lot.

It's referring to this from the point of view of the proxy server.  The web
client is going to communicate over STCP to the proxy server (the proxy acts
a server in this connection).  The proxy server is going to communicate over
TCP to the actual web server (the proxy acts as a client in this
connection).

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Alicia Chen" <achen530@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Running on elaines
Date: Wed, 7 Mar 2007 01:04:13 -0800
Lines: 30
Distribution: su
Message-ID: <eslv6h$qq0$1@news.Stanford.EDU>
References: <esl4ro$3oq$1@news.Stanford.EDU> <eslcs5$9he$2@news.Stanford.EDU>
NNTP-Posting-Host: dn800c1708.stanford.edu
X-Trace: news.Stanford.EDU 1173258257 27456 128.12.23.8 (7 Mar 2007 09:04:17 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12216

From the assignment:
" Please do not run your assignment on other machines in Sweet Hall than the 
elaines, myths and sagas. "

From Paul's post in the thread PA3 test:
"> 1. What is a good way to test for interoperability of the code?
Try different endianess machines (elaines have their bits stored in the
opposite way from the myths)."

?

--Alicia

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:eslcs5$9he$2@news.Stanford.EDU...
> You're either looking at an old copy of the assignment, or we missed a 
> reference somewhere- the elaines are Solaris machines, and all of the stub 
> code is Linux-based.  You'll need to run from the myths or one of the 
> other x86 Linux machines.
>
> Clay
> Alicia Chen wrote:
>> I am having some trouble running on the elaines.  The assignment says we 
>> should be able to.  For one thing, the reference proxy is not compiled 
>> for the elaines.  Additionally, some of the debugging information for the 
>> rest of the files is missing.  Anyone have any insight into this?
>>
>> --Alicia 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Running on elaines
Date: Wed, 07 Mar 2007 01:39:00 -0800
Lines: 19
Distribution: su
Message-ID: <C213C834.9028%jpettit@stanford.edu>
References: <esl4ro$3oq$1@news.Stanford.EDU> <eslcs5$9he$2@news.Stanford.EDU> <eslv6h$qq0$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173260344 28908 127.0.0.1 (7 Mar 2007 09:39:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: Running on elaines
Thread-Index: AcdgnG8xrZ4A38yPEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12217

> From the assignment:
> " Please do not run your assignment on other machines in Sweet Hall than the
> elaines, myths and sagas. "
> 
> From Paul's post in the thread PA3 test:
> "> 1. What is a good way to test for interoperability of the code?
> Try different endianess machines (elaines have their bits stored in the
> opposite way from the myths)."

If you are using the reference proxy, then you will need to have that side
working on x86 Linux, since it was given to you as an archive of compiled
code.  However, all of the code that is being compiled from source files
(everything else) should work on either platform.

Keep in mind that you can't just switch all your testing to the Elaines.
You will need to have an x86 side communicating with a Sparc one.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Chee-Hyung Yoon <chyoon@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: reference proxy behavior
Date: Wed, 07 Mar 2007 06:00:24 -0800
Lines: 17
Distribution: su
Message-ID: <esmghr$d48$1@news.Stanford.EDU>
References: <esk15k$e9$1@news.Stanford.EDU>
NNTP-Posting-Host: dnab423a50.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173276030 13448 171.66.58.80 (7 Mar 2007 14:00:30 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
In-Reply-To: <esk15k$e9$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12218

It turns out the HTTP/1.1 requires the host header field to be present 
in all requests (RFC2616 14.23), so 400 bad request is a correct 
response from the server.

Chee-Hyung Yoon wrote:
> Hi,
> 
> it seems like the reference proxy is massaging the message passed by 
> proxyget somehow. For websites like www.cnn.com or www.stanford.edu, if 
> I just pass the http request passed from proxyget, I get 400 bad request 
> error (and I get the same result if I telnet and manually pass the 
> request to those sites). But if I use the reference proxy, I get the 
> correct response from the server. What am I missing here and are we 
> supposed to have this functionality or is it okay to just pass the 
> message as passed by proxyget?
> 
> Chee-Hyung
.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxy with www.google.com
Date: Wed, 7 Mar 2007 10:53:19 -0800
Lines: 16
Distribution: su
Message-ID: <Pine.LNX.4.44.0703071049550.21222-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1173293600 2700 171.64.15.38 (7 Mar 2007 18:53:20 GMT)
X-Complaints-To: news@news.stanford.edu
Xref: shelby.stanford.edu su.class.cs244a:12219

Hi,

I'm experiencing a situation where APP_CLOSE_REQUESTED is not notified to
transport layer. This happens with reference proxy/proxyget on
www.google.com for me.

the proxy calls myclose(), but it hangs after calling pthread_join within
myclose, and never get to the control_loop.

I've noticed some threads talking about the related issue, but I wanted to
confirm if this was a known issue that I don't have to worry about.


Thanks,
-Seung

.

Path: shelby.stanford.edu!myth20.Stanford.EDU!shchoi
From: Seung Hoon Choi <shchoi@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxy with www.google.com
Date: Wed, 7 Mar 2007 10:59:28 -0800
Lines: 25
Distribution: su
Message-ID: <Pine.LNX.4.44.0703071059130.24356-100000@myth20.Stanford.EDU>
References: <Pine.LNX.4.44.0703071049550.21222-100000@myth20.Stanford.EDU>
NNTP-Posting-Host: myth20.stanford.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.Stanford.EDU 1173293970 2946 171.64.15.38 (7 Mar 2007 18:59:30 GMT)
X-Complaints-To: news@news.stanford.edu
In-Reply-To: <Pine.LNX.4.44.0703071049550.21222-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12220

BTW, this also happens with my proxy.

-Seung


On Wed, 7 Mar 2007, Seung Hoon Choi wrote:

> Hi,
>
> I'm experiencing a situation where APP_CLOSE_REQUESTED is not notified to
> transport layer. This happens with reference proxy/proxyget on
> www.google.com for me.
>
> the proxy calls myclose(), but it hangs after calling pthread_join within
> myclose, and never get to the control_loop.
>
> I've noticed some threads talking about the related issue, but I wanted to
> confirm if this was a known issue that I don't have to worry about.
>
>
> Thanks,
> -Seung
>
>

.

Path: shelby.stanford.edu!not-for-mail
From: Dinesh Gupta <dineshg@Stanford.EDU>
Newsgroups: su.class.cs244a
Subject: Re: segv in proxyget
Date: Wed, 7 Mar 2007 19:48:42 +0000 (UTC)
Lines: 10
Distribution: su
Message-ID: <esn4uq$5a7$1@news.Stanford.EDU>
References: <eskjae$hp0$1@news.Stanford.EDU> <esllh8$fml$1@news.Stanford.EDU>
NNTP-Posting-Host: myth10.stanford.edu
X-Trace: news.Stanford.EDU 1173296922 5447 171.64.15.6 (7 Mar 2007 19:48:42 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (Linux/2.6.17.13smp (i686))
Xref: shelby.stanford.edu su.class.cs244a:12221

Printing proper usage would have been better. I figured this out but
initially I thought there is some problem in my proxy.
Anyways I put this message so that others won't get scared when they see
this.

Kristjan Petursson <kristjan@stanford.edu> wrote:
> Dinesh Gupta wrote:
> > If I run proxyget -U m/c:port  without giving url then it seg faults.
> > 
> Serves you right :-p
.

Path: shelby.stanford.edu!not-for-mail
From: "Darius Henderson" <darius.henderson@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: TCP checksum failures
Date: Wed, 7 Mar 2007 12:52:57 -0800
Lines: 36
Distribution: su
Message-ID: <esn8nh$9ic$1@news.Stanford.EDU>
References: <esl4q8$3o4$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173300785 9804 127.0.0.1 (7 Mar 2007 20:53:05 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
Xref: shelby.stanford.edu su.class.cs244a:12222

Hmm, I also noticed checksum failures during one specific case during the 
3way handshake:

1) the client receives the SYN-ACK and responds, but the ACK response is 
dropped. the client, not knowing the ACK was dropped, sends a data packet 
immediately after.

2) the server, after resending the SYN-ACK, calls stcp_network_recv (which 
now has the data packet), in hopes of finding the ACK.

However, the stcp_network_recv would never return for the server because it 
would get a checksum error on the data packet. I figured this had something 
do with the client considering the connection established, while the server 
didn't.

Maybe you're experiencing a similar problem? I never figured out why it 
would cause the checksum to fail though.

"Scott Lulovics" <slulovic@cs.stanford.edu> wrote in message 
news:esl4q8$3o4$1@news.Stanford.EDU...
> When running a proxy (mine or the provided) on an x86 arch (myths) and 
> proxyget on x86-64 arch (my desktop), I get tcp checksum failures from the 
> underlying code on the proxy side. Specifically, _mysock_verify_checksum 
> in tcp_sum.c returns FALSE. It works fine when both are run from the myths 
> or both are run from x86-64.
>
> The checksum stuff is entirely out of our hands, I believe, so should I be 
> worried about this?
>
> Also, just to be sure, is there a penalty for using the reference proxy in 
> this assignment?
>
> Thanks,
> Scott 


.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: revents & POLLERR assert in network_io_socket.c
Date: Wed, 7 Mar 2007 14:56:40 -0700
Lines: 62
Distribution: su
Message-ID: <esnceq$d3v$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173304602 13439 127.0.0.1 (7 Mar 2007 21:56:42 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12223

This assertion deserves a new thread.  Some more observations...

1)  I'm seeing the assert happen because POLLERR is true, and POLLERR is 
true because the peer issued a RST.  This is a RST on the actual TCP 
connection that underlies the simulated STCP connection.

2)  Why does the RST happen?  In my logs the STCP 4-way handshake completes 
correctly before the RST in -U mode, and I don't see the assert happen in 
reliable mode.  Since it only seems to happen (at least in this test case) 
in -U mode, one theory would be that some duplicated or delayed packets are 
reaching the proxy from the STCP client after the proxy has closed its 
connection (?).  Wouldn't that cause the proxy's TCP to issue a RST?  I 
think somebody made the assert go away by implementing the TIME_WAIT state. 
That would be consistent with what I'm seeing, since presumably then the 
proxy wouldn't choke on any spurious packets arriving after it left 
FIN_WAIT_2, at least for a while.

3)  If so it seems like we either need to implement TIME_WAIT or change 
network_io_socket.c to something like this, or both:

// Replace the default case at lines 245-253 with ...

// ----------------------------------------------------

default:

assert(!(fds[0].revents & POLLERR));

if (fds[0].revents) done = TRUE;

if( fds[1].revents & POLLERR )

{

     // One more read will set errno with info about the POLLERR

     bytes_read = _network_recv_packet(&ctx->network_state, packet_buf, 
sizeof(packet_buf));


     // Let the user know what error occurred

     fprintf( stderr, "TCP SOCKET ERROR: %s\n", strerror(errno) );

     // Give up on the connection

     done = TRUE;

}

else if (fds[1].revents) packet_ready = TRUE;

break;


Obviously this wouldn't make the RST go away, but at least it would handle 
it.  TA's, any thoughts?

Thanks,
Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: revents & POLLERR assert in network_io_socket.c
Date: Wed, 07 Mar 2007 15:50:03 -0800
Lines: 70
Distribution: su
Message-ID: <esnj3b$icp$1@news.Stanford.EDU>
References: <esnceq$d3v$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173311403 18841 127.0.0.1 (7 Mar 2007 23:50:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <esnceq$d3v$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12224

Kevin Hart wrote:
> This assertion deserves a new thread.  Some more observations...
> 
> 1)  I'm seeing the assert happen because POLLERR is true, and POLLERR is 
> true because the peer issued a RST.  This is a RST on the actual TCP 
> connection that underlies the simulated STCP connection.
> 
> 2)  Why does the RST happen?  In my logs the STCP 4-way handshake completes 
> correctly before the RST in -U mode, and I don't see the assert happen in 
> reliable mode.  Since it only seems to happen (at least in this test case) 
> in -U mode, one theory would be that some duplicated or delayed packets are 
> reaching the proxy from the STCP client after the proxy has closed its 
> connection (?).  Wouldn't that cause the proxy's TCP to issue a RST?  I 
> think somebody made the assert go away by implementing the TIME_WAIT state. 
> That would be consistent with what I'm seeing, since presumably then the 
> proxy wouldn't choke on any spurious packets arriving after it left 
> FIN_WAIT_2, at least for a while.
> 
> 3)  If so it seems like we either need to implement TIME_WAIT or change 
> network_io_socket.c to something like this, or both:
> 
> // Replace the default case at lines 245-253 with ...
> 
> // ----------------------------------------------------
> 
> default:
> 
> assert(!(fds[0].revents & POLLERR));
> 
> if (fds[0].revents) done = TRUE;
> 
> if( fds[1].revents & POLLERR )
> 
> {
> 
>      // One more read will set errno with info about the POLLERR
> 
>      bytes_read = _network_recv_packet(&ctx->network_state, packet_buf, 
> sizeof(packet_buf));
> 
> 
>      // Let the user know what error occurred
> 
>      fprintf( stderr, "TCP SOCKET ERROR: %s\n", strerror(errno) );
> 
>      // Give up on the connection
> 
>      done = TRUE;
> 
> }
> 
> else if (fds[1].revents) packet_ready = TRUE;
> 
> break;
> 
> 
> Obviously this wouldn't make the RST go away, but at least it would handle 
> it.  TA's, any thoughts?
> 
> Thanks,
> Kevin
> 
> 

It would be super helpful if you can make a 100% reproducible test case 
and forward it on to paul, along with a description of what is 
happening, and why it should work differently.

Thanks,
David
.

Path: shelby.stanford.edu!not-for-mail
From: David Erickson <derickso@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxy with www.google.com
Date: Wed, 07 Mar 2007 17:12:49 -0800
Lines: 31
Distribution: su
Message-ID: <esnnu7$mbj$1@news.Stanford.EDU>
References: <Pine.LNX.4.44.0703071049550.21222-100000@myth20.Stanford.EDU> <Pine.LNX.4.44.0703071059130.24356-100000@myth20.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173316359 22899 127.0.0.1 (8 Mar 2007 01:12:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <Pine.LNX.4.44.0703071059130.24356-100000@myth20.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12225

Seung Hoon Choi wrote:
> BTW, this also happens with my proxy.
> 
> -Seung
> 
> 
> On Wed, 7 Mar 2007, Seung Hoon Choi wrote:
> 
>> Hi,
>>
>> I'm experiencing a situation where APP_CLOSE_REQUESTED is not notified to
>> transport layer. This happens with reference proxy/proxyget on
>> www.google.com for me.
>>
>> the proxy calls myclose(), but it hangs after calling pthread_join within
>> myclose, and never get to the control_loop.
>>
>> I've noticed some threads talking about the related issue, but I wanted to
>> confirm if this was a known issue that I don't have to worry about.
>>
>>
>> Thanks,
>> -Seung
>>
>>
> 

This is on the proxyget side?  If it is on the proxy side you can fix 
that because it is your code.

-David
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: revents & POLLERR assert in network_io_socket.c
Date: Wed, 7 Mar 2007 20:39:03 -0800
Lines: 13
Distribution: su
Message-ID: <eso3vh$1bt$1@news.Stanford.EDU>
References: <esnceq$d3v$1@news.Stanford.EDU> <esnj3b$icp$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173328689 1405 127.0.0.1 (8 Mar 2007 04:38:09 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12226

> It would be super helpful if you can make a 100% reproducible test case 
> and forward it on to paul, along with a description of what is happening, 
> and why it should work differently.
Paul already has the test case, and this explanation matches how I explain 
it, too.  This post goes further by fixing the code in a way that seems 
plausible.  I have no ideas about the dependencies, though.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Jad Naous <jnaous@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS4 Q2
Date: Thu, 08 Mar 2007 15:06:45 -0800
Lines: 7
Distribution: su
Message-ID: <esq4tj$rch$1@news.Stanford.EDU>
NNTP-Posting-Host: seine.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173395187 28049 171.64.74.36 (8 Mar 2007 23:06:27 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.8 (X11/20060911)
Xref: shelby.stanford.edu su.class.cs244a:12227

Hi,

Q2: do we assume that the sender and rcvr are operating at 10Mbps as
well as 10MHz per second?

Thanks,
Jad.
.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PA4 files
Date: Thu, 08 Mar 2007 21:25:22 -0500
Lines: 4
Distribution: su
Message-ID: <esqgm3$81m$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173407235 8246 127.0.0.1 (9 Mar 2007 02:27:15 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:12228

I cannot find some of the files mentioned in PA 4.  Where can they be found?

Thanks,
Jin
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA4 files
Date: Thu, 08 Mar 2007 19:44:01 -0800
Lines: 9
Distribution: su
Message-ID: <esql92$b5q$1@news.Stanford.EDU>
References: <esqgm3$81m$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173411938 11450 171.64.74.54 (9 Mar 2007 03:45:38 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esqgm3$81m$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12229

Take a look at the tarball now linked off the assignment 4 page.

Clay
Jin Wang wrote:
> I cannot find some of the files mentioned in PA 4.  Where can they be 
> found?
> 
> Thanks,
> Jin
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Two PA4 Announcements
Date: Thu, 08 Mar 2007 19:48:06 -0800
Lines: 16
Distribution: su
Message-ID: <esqlgr$bbp$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173412187 11641 171.64.74.54 (9 Mar 2007 03:49:47 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:12230

1) Topology Re-send
There was a slight bug in the initial batch of topologies that were sent 
out that may have made it hard for you to connect to your topology (one 
of the nodes was named incorrectly).  Rather than fix this in place, 
I've re-sent the topology files out to everyone.  Also included in the 
new mailing is the rtable.vhost file that you will need in order to set 
up routing for the virtual host node that your proxy will be running from.

2) PA4 Code Tarball
Extra source code for PA4 is now posted on the PA4 assignment page. 
This tarball includes the VNS transport layer libraries, the echo server 
and client, and an updated Makefile for building the the echo 
client/server pair.  You'll need to add your transport.c, transport.h, 
and the source directory for your sr router and proxy into the build.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS4 Q2
Date: Fri, 09 Mar 2007 00:40:23 -0800
Lines: 7
Distribution: su
Message-ID: <C2165D77.90DC%jpettit@stanford.edu>
References: <esq4tj$rch$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173429623 27027 127.0.0.1 (9 Mar 2007 08:40:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS4 Q2
Thread-Index: AcdiJpO40hw82c4ZEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12231

> Q2: do we assume that the sender and rcvr are operating at 10Mbps as
> well as 10MHz per second?

Yes.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS4 Q2
Date: Fri, 09 Mar 2007 01:00:44 -0800
Lines: 15
Distribution: su
Message-ID: <C216623C.90E0%jpettit@stanford.edu>
References: <esq4tj$rch$1@news.Stanford.EDU> <C2165D77.90DC%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173430844 27695 127.0.0.1 (9 Mar 2007 09:00:44 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS4 Q2
Thread-Index: AcdiJpO40hw82c4ZEduBygARJDbi7gAAtfGo
Xref: shelby.stanford.edu su.class.cs244a:12232

On 3/9/07 12:40 AM, in article C2165D77.90DC%jpettit@stanford.edu, "Justin
Pettit" <jpettit@stanford.edu> wrote:

>> Q2: do we assume that the sender and rcvr are operating at 10Mbps as
>> well as 10MHz per second?
> 
> Yes.
> 
> --Justin
> 

I should add that Jad and I are discussing question 3, not question 2.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Kevin Hart" <kevin.hart@hp.com>
Newsgroups: su.class.cs244a
Subject: PA4 sanity check
Date: Fri, 9 Mar 2007 11:12:54 -0700
Lines: 21
Distribution: su
Message-ID: <ess838$4j$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173463976 147 127.0.0.1 (9 Mar 2007 18:12:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12233

The drawings and discussion in the PA4 handout are confusing me because they 
don't seem to acknowledge the two-sidedness of the proxy.  I have a couple 
of questions...

1) The handout says "your host should act exactly as the web proxy did over 
the system socket libraries."  I'm assuming that means we can configure a 
web browser to use the proxy as a real HTTP proxy for surfing the web as we 
did in PA1. But doesn't that mean the passive side of the proxy needs to be 
straight TCP sockets (to receive connections from a browser), and the active 
side needs to be STCP sockets (to interact with the VNS system)?  That would 
be a 180-degree reversal of what we just did to the proxy for PA3, right?

2) The packets we'll be receiving when our STCP calls stcp_network_receive 
will be real TCP packets this time (since the thing we're connecting to on 
the active side of the proxy will be a real network stack), right?

Thanks,

Kevin


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Two PA4 Announcements
Date: Fri, 9 Mar 2007 10:24:38 -0800
Lines: 14
Distribution: su
Message-ID: <ess8nl$sv$1@news.Stanford.EDU>
References: <esqlgr$bbp$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173464629 927 127.0.0.1 (9 Mar 2007 18:23:49 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12234

> 2) PA4 Code Tarball
> Extra source code for PA4 is now posted on the PA4 assignment page. This 
> tarball includes the VNS transport layer libraries, the echo server and 
> client, and an updated Makefile for building the the echo client/server 
> pair.  You'll need to add your transport.c, transport.h, and the source 
> directory for your sr router and proxy into the build.
Does this code have the bugfix to network_io_socket.c?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Two PA4 Announcements
Date: Fri, 9 Mar 2007 11:25:42 -0800
Lines: 19
Distribution: su
Message-ID: <essca5$4p3$1@news.Stanford.EDU>
References: <esqlgr$bbp$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173468293 4899 127.0.0.1 (9 Mar 2007 19:24:53 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12235

> 2) PA4 Code Tarball
> Extra source code for PA4 is now posted on the PA4 assignment page. This 
> tarball includes the VNS transport layer libraries, the echo server and 
> client, and an updated Makefile for building the the echo client/server 
> pair.  You'll need to add your transport.c, transport.h, and the source 
> directory for your sr router and proxy into the build.
How do we use the reference proxy?  The Makefile has a comment that I will 
get errors if I try to do it the same way hw3 worked.

Have you compiled the reference proxy with the vns code?  I am expecting 
even more link errors because the mysock functions were declared incorrectly 
and the compiler in the provided Makefile is gcc not g++.

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: ping responses from stcp_echo_server
Date: Fri, 9 Mar 2007 12:17:33 -0800
Lines: 68
Distribution: su
Message-ID: <essfbd$844$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173471405 8324 127.0.0.1 (9 Mar 2007 20:16:45 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12236

There is a bug in sr_transport/libsr_core.a (AFAICT).  When pinging 
stcp_echo_server, which links to this library, I get an ICMP req with 20 
more bytes than it should (and an incorrect timestamp).  I suspect what is 
happening is that part of the ICMP code is incorrectly adding on the length 
of the IP header (as it needs to for ICMP errors).  However, the first 56 
bytes of data are correct, and the checksum is not.  That indicates to me 
that in some places, the code probably treats the ICMP echo response as it 
should.

I have no patch, as I only have the reference library.  I suspect the 
reference sr uses the same code and will have the same bug.

As was pointed out earlier in the newsgroup, this means that ping ignores 
the response and treats it as if there was no response (this time because 
the ICMP checksum is wrong).

Frame 12 (98 bytes on wire, 98 bytes captured)
Ethernet II, Src: 70:00:00:d7:00:05 (70:00:00:d7:00:05), Dst: 
70:00:00:d7:00:06 (70:00:00:d7:00:06)
Internet Protocol, Src: 171.64.15.186 (171.64.15.186), Dst: 192.168.129.57 
(192.168.129.57)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xb111 [correct]
    Identifier: 0x2f6e
    Sequence number: 0x0100
    Data (56 bytes)

0000  70 00 00 d7 00 06 70 00 00 d7 00 05 08 00 45 00   p.....p.......E.
0010  00 54 00 00 40 00 3d 01 40 cd ab 40 0f ba c0 a8   .T..@.=.@..@....
0020  81 39 08 00 b1 11 2f 6e 01 00 84 b8 f1 45 ab 7e   .9..../n.....E.~
0030  0a 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15   ................
0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
0060  36 37                                             67

The stcp_echo_server responds with:

Frame 13 (118 bytes on wire, 118 bytes captured)
Ethernet II, Src: 70:00:00:d7:00:06 (70:00:00:d7:00:06), Dst: 
70:00:00:d7:00:05 (70:00:00:d7:00:05)
Internet Protocol, Src: 192.168.129.57 (192.168.129.57), Dst: 171.64.15.186 
(171.64.15.186)
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0xf95f [incorrect, should be 0x81d0]
    Identifier: 0x2f6e
    Sequence number: 0x0100
    Data (76 bytes)

0000  70 00 00 d7 00 05 70 00 00 d7 00 06 08 00 45 00   p.....p.......E.
0010  00 68 00 00 00 00 ff 01 be b8 c0 a8 81 39 ab 40   .h...........9.@
0020  0f ba 00 00 f9 5f 2f 6e 01 00 84 b8 f1 45 ab 7e   ....._/n.....E.~
0030  0a 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15   ................
0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
0060  36 37 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23   67.......... !"#
0070  24 25 26 27 28 29                                 $%&'()


HTH,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: where to stick stcp_echo_client
Date: Fri, 9 Mar 2007 12:30:45 -0800
Lines: 22
Distribution: su
Message-ID: <essg44$8pa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173472196 9002 127.0.0.1 (9 Mar 2007 20:29:56 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12237

Obviously, we have to hook up stcp_echo_server to a VNS topology because the 
VNS parameters are required.

I thought since the parameters were optional, that we could hook up 
stcp_echo_client to run just on a normal host (as we only get one VNS host 
to play with).  Well, I was wrong.  It connects up to a default topology of 
28.  It even gets arp requests.  However, it cannot send any packets out 
because it gets no arp responses.

I tried to connect it up to my topology, but as the server was there, it 
could not connect (which, BTW, I think is an improvement over silent 
failure; thank you).

So my question is, how do we use stcp_echo_client and stcp_echo_server 
together?

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: compiling reference proxy
Date: Fri, 9 Mar 2007 13:00:52 -0800
Lines: 75
Distribution: su
Message-ID: <esshsk$aqa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173474004 11082 127.0.0.1 (9 Mar 2007 21:00:04 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12238

I tried:
our.proxy_vns: $(LIBSPROXY) $(VNS_GLUE)
 $(warning ***compiling with reference proxy_vns...***)
 $(CC) $(CFLAGS) -o $@ $^ $(VNS_LIBS)

This gets the errors I was expecting (no std::cout, no std::string, etc.)

I also tried:
our.proxy_vns: $(LIBSPROXY) $(VNS_GLUE)
 $(warning ***compiling with reference proxy_vns...***)
 g++ $(CFLAGS) -o $@ $^ $(VNS_LIBS)

and:

our.proxy_vns: $(LIBSPROXY) $(VNS_GLUE)
 $(warning ***compiling with reference proxy_vns...***)
 $(CC) $(CFLAGS) -o $@ -lstdc++ $^ $(VNS_LIBS)

This also gets the errors I was expecting (myclose, myaccept, etc. not 
found).  I have asked that proxy.a be compiled with the enclosed header file 
before (which correctly declairs myclose, myaccept, etc.), but did not push 
the matter because there was away around the issue.  Could that please be 
done and a new .a distributed?  W/o the source that implements these 
functions or a new .a, the reference  proxy is unusable.  There may be other 
issues, so a compile before distribution might be a wise idea.  For 
instance, I suspect the reference proxy does not call sr_api_init as it will 
need to do for pa4.

Sincerely,
Randy Jennings

The squirrels are your friends!


begin 666 mysock.h
M+RH@;7ES;V-K+F@M+6UY<V]C:V5T(&%P<&QI8V%T:6]N(&EN=&5R9F%C92 J
M+PH*(VEF;F1E9B!?7TU94T]#2U](7U\*(V1E9FEN92!?7TU94T]#2U](7U\*
M"B-I9B!D969I;F5D*$Q)3E58*2!\?"!D969I;F5D*$-91U=)3BD*(VEN8VQU
M9&4@/'-T9&EN="YH/@HC96QI9B!D969I;F5D*%-/3$%225,I"B-I;F-L=61E
M(#QI;G1T>7!E<RYH/@HC96QS90HC97)R;W(@;F5E9"!T;R!D969I;F4@=6EN
M=#,R7W0*(V5N9&EF"@HC:6YC;'5D92 \<WES+W1Y<&5S+F@^"B-I;F-L=61E
M(#QS>7,O<V]C:V5T+F@^"@H*(VEF;F1E9B!&04Q310HC9&5F:6YE($9!3%-%
M(# *(V5N9&EF"@HC:69N9&5F(%12544*(V1E9FEN92!44E5%(#$*(V5N9&EF
M"@IT>7!E9&5F(&EN="!B;V]L7W0["G1Y<&5D968@:6YT(&UY<V]C:V5T7W0[
M(" @(" O*B!M>7-O8VME="!D97-C<FEP=&]R("HO"@H*+RH@;6%X:6UU;2!N
M=6UB97(@;V8@;7ES;V-K971S('!E<B!P<F]C97-S("HO"B-D969I;F4@34%8
M7TY535]#3TY.14-424].4R V- H*(VEF("A-05A?3E5-7T-/3DY%0U1)3TY3
M("8@*$U!6%].54U?0T].3D5#5$E/3E,@+2 Q*2D@(3T@, H@(" @(V5R<F]R
M($U!6%].54U?0T].3D5#5$E/3E,@<VAO=6QD(&)E(&$@<&]W97(@;V8@='=O
M"B-E;F1I9@H*(VEF9&5F(%]?8W!L=7-P;'5S"F5X=&5R;B B0R(@>PHC96YD
M:68*"65X=&5R;B!M>7-O8VME=%]T(&UY<V]C:V5T*&)O;VQ?="!I<U]R96QI
M86)L92D["@EE>'1E<FX@:6YT(&UY8FEN9"AM>7-O8VME=%]T('-D+"!S=')U
M8W0@<V]C:V%D9'(@*F%D9'(L(&EN="!A9&1R;&5N*3L*"65X=&5R;B!I;G0@
M;7EL:7-T96XH;7ES;V-K971?="!S9"P@:6YT(&)A8VML;V<I.PH)97AT97)N
M(&EN="!M>6-O;FYE8W0H;7ES;V-K971?="!S9"P@<W1R=6-T('-O8VMA9&1R
M*B!N86UE+"!I;G0@;F%M96QE;BD["@EE>'1E<FX@:6YT(&UY86-C97!T*&UY
M<V]C:V5T7W0@<V0L('-T<G5C="!S;V-K861D<BH@861D<BP@:6YT("IA9&1R
M;&5N*3L*"65X=&5R;B!I;G0@;7EC;&]S92AM>7-O8VME=%]T('-D*3L*"65X
M=&5R;B!I;G0@;7ER96%D*&UY<V]C:V5T7W0@<V0L('9O:60@*F)U9F9E<BP@
M<VEZ95]T(&QE;F=T:"D["@EE>'1E<FX@:6YT(&UY=W)I=&4H;7ES;V-K971?
M="!S9"P@8V]N<W0@=F]I9" J8G5F9F5R+"!S:7IE7W0@;&5N9W1H*3L*"65X
M=&5R;B!I;G0@;7EG971S;V-K;F%M92AM>7-O8VME=%]T('-D+"!S=')U8W0@
M<V]C:V%D9'(@*F%D9'(L"@D@(" @(" @(" @(" @(" @(" @(" @(" @<V]C
M:VQE;E]T("IA9&1R;&5N*3L*"65X=&5R;B!I;G0@;7EG971P965R;F%M92AM
M>7-O8VME=%]T('-D+"!S=')U8W0@<V]C:V%D9'(@*F%D9'(L"@D@(" @(" @
M(" @(" @(" @(" @(" @(" @<V]C:VQE;E]T("IA9&1R;&5N*3L*(VEF9&5F
M(%]?8W!L=7-P;'5S"GT*(V5N9&EF( HO*B!R971U<FX@25 @861D<F5S<R!O
M9B!I;G1E<F9A8V4@;VX@=VAI8V@@<&%C:V5T<R!T;R]F<F]M('!E97)?861D
M<B!A<F4*("H@9&5L:79E<F5D+B @<&5E<E]A9&1R(&ES(&EN(&YE='=O<FL@
M8GET92!O<F1E<BX*("HO"F5X=&5R;B!U:6YT,S)?="!M>6QO8V%L:7 H=6EN
M=#,R7W0@<&5E<E]A9&1R*3L*"B-E;F1I9B @+RH@7U]-65-/0TM?2%]?("HO
""@H`
`
end

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: compiling reference proxy
Date: Fri, 9 Mar 2007 13:41:22 -0800
Lines: 19
Distribution: su
Message-ID: <essk8h$d0b$1@news.Stanford.EDU>
References: <esshsk$aqa$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173476433 13323 127.0.0.1 (9 Mar 2007 21:40:33 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12239

Previously, I was not compiling in my transport layer.  To do so, add:

our.proxy_vns: $(LIBSPROXY) $(VNS_GLUE) $(OBJ_VNS)
 $(warning ***compiling with reference proxy_vns...***)
 $(CC) $(CFLAGS) -o $@ -lstdc++ $^ $(VNS_LIBS)

Yes, it still does not compile.

I also noticed another linker error that I cannot explain:

sr_transport/libsr_core.a(sr_ip_input.o): In function `sr_ip_handle_local':
: undefined reference to `sr_transport_input'

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Justin Pettit <jpettit@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS3 Graded and PS4 Reminder
Date: Fri, 09 Mar 2007 15:22:51 -0800
Lines: 14
Distribution: su
Message-ID: <C2172C4B.9136%jpettit@stanford.edu>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173482574 19499 127.0.0.1 (9 Mar 2007 23:22:54 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Microsoft-Entourage/11.3.3.061214
Thread-Topic: PS3 Graded and PS4 Reminder
Thread-Index: AcdiodswGdCw9s6VEduBygARJDbi7g==
Xref: shelby.stanford.edu su.class.cs244a:12240

The third problem set is graded.  If you were not in class today, then you
can pick it up in the third floor filing cabinet.  SCPD students should
receive their graded assignments early next week.  The average was 81.81 out
of 100 with a standard deviation of 16.01.

Don't forget that the fourth problem set is due Wednesday.  The cutoff for
turning it in late is noon on Friday.  After that, we will post the sample
final and solutions from 2004.  The 2006 final (without solutions) is
already posted on the main page.

Have a great weekend.

--Justin

.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS#4 q4b
Date: Fri, 9 Mar 2007 15:34:36 -0800
Lines: 10
Distribution: su
Message-ID: <est2vj$qrj$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173491507 27507 127.0.0.1 (10 Mar 2007 01:51:47 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12241

I am assuming that we are ignoring (header/trailer/IPG etc.) for this (and
the following) parts.  Is that correct?

Sincerely,
Randy Jennings

The squirrels are your friends!



.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA4 sanity check
Date: Fri, 9 Mar 2007 23:06:26 -0500
Lines: 49
Distribution: su
Message-ID: <estarv$36b$1@news.Stanford.EDU>
References: <ess838$4j$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173499583 3275 127.0.0.1 (10 Mar 2007 04:06:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12242

I don't know.  I read this to be basically that we're using what we put 
together for part C in HW3, but then hooking it up with VNS by doing the 
sr_api_init and the single change to gethostbyname.  The proxy, like in HW3, 
would expect STCP packets coming in but send normal TCP packets going out. 
The difference is that since we're hooked into VNS both the STCP and TCP 
packets will be pushed through our router.  To that end, it seems to me that 
the client for our proxy will still be the STCP version of proxyget.  But 
that the proxy will communicate to the outside world using normal TCP just 
routed through our router implementation.  Here's my flow of how I read a 
request to go:
proxyget->STCP->VNS->our router->VNS->STCP->proxy->TCP->VNS->our 
router->VNS->TCP->web server and back again.

Now, I may be parsing the assignment this way because it's easier and we 
have STCP talking to STCP and TCP talking to TCP but he assignment did say: 
"You should not have to write much code to get things working as all 
functional components should already be completed."

Anyway, I would really like a TA's feedback on this as I found this the most 
confusing part of the assignment.

-Seth

"Kevin Hart" <kevin.hart@hp.com> wrote in message 
news:ess838$4j$1@news.Stanford.EDU...
> The drawings and discussion in the PA4 handout are confusing me because 
> they don't seem to acknowledge the two-sidedness of the proxy.  I have a 
> couple of questions...
>
> 1) The handout says "your host should act exactly as the web proxy did 
> over the system socket libraries."  I'm assuming that means we can 
> configure a web browser to use the proxy as a real HTTP proxy for surfing 
> the web as we did in PA1. But doesn't that mean the passive side of the 
> proxy needs to be straight TCP sockets (to receive connections from a 
> browser), and the active side needs to be STCP sockets (to interact with 
> the VNS system)?  That would be a 180-degree reversal of what we just did 
> to the proxy for PA3, right?
>
> 2) The packets we'll be receiving when our STCP calls stcp_network_receive 
> will be real TCP packets this time (since the thing we're connecting to on 
> the active side of the proxy will be a real network stack), right?
>
> Thanks,
>
> Kevin
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Compiling our own proxy in HW4
Date: Sat, 10 Mar 2007 01:11:48 -0500
Lines: 28
Distribution: su
Message-ID: <esti70$92i$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173507104 9298 127.0.0.1 (10 Mar 2007 06:11:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12243

I'm having trouble compiling my proxy in hw4.  First off, I had to add the 
proxy to the all: target (actually I added it to all_hw4).  But then when I 
tried to compile, it complained that sr_api_init could not be linked.  I got 
past this by looking at the echo_server target and copying over the VNS_GLUE 
and VNS_OBJS entries, etc.  But then when I do that, I get:

gcc -g -DLINUX -D_REENTRANT -ansi -pthread -D_GNU_SOURCE -Wall -W -Wno-unused-function 
 -Wno-unused-parameter  -o your.proxy transport.o mysock_api.o stcp_api.o 
mysock.o network.o connection_demux.o tcp_sum.o network_io.o 
network_io_tcp.o network_io_socket.o sw_proxy.o sr_transport/sr_vns_api.o 
sr_transport/sr_vns_integration.o sr_transport/libsr_core.a 
sr_transport/libsr_vns.a -lnsl -lpthread -lcrypt -lresolv  -lnsl -lpthread -lcrypt
sr_transport/libsr_core.a(sr_ip_input.o): In function `sr_ip_handle_local':
: undefined reference to `sr_transport_input'
collect2: ld returned 1 exit status
make: *** [your.proxy] Error 1

The target it's trying to compile is:
your.proxy: $(OBJS) $(PROXY_OBJS) $(VNS_GLUE)
$(CC) $(CFLAGS) -o $@ $^ $(VNS_LIBS) $(STCPLIB) ${LIBS}

TAs, should I have to muck with the Makefile this much?  I feel like I'm 
going down a rabbit hole with this one and could waste a lot of time over 
something stupid I'm doing.

-Seth 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sat, 10 Mar 2007 00:59:11 -0800
Lines: 29
Distribution: su
Message-ID: <ests4e$n2c$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173517262 23628 171.64.74.54 (10 Mar 2007 09:01:02 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <essg44$8pa$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12244

You should be able to connect the echo client to the vhost and the echo 
server to the vrouter.  Just pass them the appropriate rtable files and 
specify the vnode name using the -v option.

Clay

Randy Jennings wrote:
> Obviously, we have to hook up stcp_echo_server to a VNS topology because the 
> VNS parameters are required.
> 
> I thought since the parameters were optional, that we could hook up 
> stcp_echo_client to run just on a normal host (as we only get one VNS host 
> to play with).  Well, I was wrong.  It connects up to a default topology of 
> 28.  It even gets arp requests.  However, it cannot send any packets out 
> because it gets no arp responses.
> 
> I tried to connect it up to my topology, but as the server was there, it 
> could not connect (which, BTW, I think is an improvement over silent 
> failure; thank you).
> 
> So my question is, how do we use stcp_echo_client and stcp_echo_server 
> together?
> 
> Sincerely,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: ping responses from stcp_echo_server
Date: Sat, 10 Mar 2007 01:03:11 -0800
Lines: 77
Distribution: su
Message-ID: <estsbu$n2c$2@news.Stanford.EDU>
References: <essfbd$844$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173517503 23628 171.64.74.54 (10 Mar 2007 09:05:03 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <essfbd$844$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12245

Yes- there is a problem there.  Compounding it, the version of ping that 
runs by default is quite picky about this sort of thing and discards the 
packet rather enthusiastically.  As a temporary fix, try running 
/bin/ping instead of the ping that runs by default on the myths (which 
is, I think, /usr/pubsw/bin/ping

Clay

Randy Jennings wrote:
> There is a bug in sr_transport/libsr_core.a (AFAICT).  When pinging 
> stcp_echo_server, which links to this library, I get an ICMP req with 20 
> more bytes than it should (and an incorrect timestamp).  I suspect what is 
> happening is that part of the ICMP code is incorrectly adding on the length 
> of the IP header (as it needs to for ICMP errors).  However, the first 56 
> bytes of data are correct, and the checksum is not.  That indicates to me 
> that in some places, the code probably treats the ICMP echo response as it 
> should.
> 
> I have no patch, as I only have the reference library.  I suspect the 
> reference sr uses the same code and will have the same bug.
> 
> As was pointed out earlier in the newsgroup, this means that ping ignores 
> the response and treats it as if there was no response (this time because 
> the ICMP checksum is wrong).
> 
> Frame 12 (98 bytes on wire, 98 bytes captured)
> Ethernet II, Src: 70:00:00:d7:00:05 (70:00:00:d7:00:05), Dst: 
> 70:00:00:d7:00:06 (70:00:00:d7:00:06)
> Internet Protocol, Src: 171.64.15.186 (171.64.15.186), Dst: 192.168.129.57 
> (192.168.129.57)
> Internet Control Message Protocol
>     Type: 8 (Echo (ping) request)
>     Code: 0
>     Checksum: 0xb111 [correct]
>     Identifier: 0x2f6e
>     Sequence number: 0x0100
>     Data (56 bytes)
> 
> 0000  70 00 00 d7 00 06 70 00 00 d7 00 05 08 00 45 00   p.....p.......E.
> 0010  00 54 00 00 40 00 3d 01 40 cd ab 40 0f ba c0 a8   .T..@.=.@..@....
> 0020  81 39 08 00 b1 11 2f 6e 01 00 84 b8 f1 45 ab 7e   .9..../n.....E.~
> 0030  0a 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15   ................
> 0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
> 0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
> 0060  36 37                                             67
> 
> The stcp_echo_server responds with:
> 
> Frame 13 (118 bytes on wire, 118 bytes captured)
> Ethernet II, Src: 70:00:00:d7:00:06 (70:00:00:d7:00:06), Dst: 
> 70:00:00:d7:00:05 (70:00:00:d7:00:05)
> Internet Protocol, Src: 192.168.129.57 (192.168.129.57), Dst: 171.64.15.186 
> (171.64.15.186)
> Internet Control Message Protocol
>     Type: 0 (Echo (ping) reply)
>     Code: 0
>     Checksum: 0xf95f [incorrect, should be 0x81d0]
>     Identifier: 0x2f6e
>     Sequence number: 0x0100
>     Data (76 bytes)
> 
> 0000  70 00 00 d7 00 05 70 00 00 d7 00 06 08 00 45 00   p.....p.......E.
> 0010  00 68 00 00 00 00 ff 01 be b8 c0 a8 81 39 ab 40   .h...........9.@
> 0020  0f ba 00 00 f9 5f 2f 6e 01 00 84 b8 f1 45 ab 7e   ....._/n.....E.~
> 0030  0a 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15   ................
> 0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
> 0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
> 0060  36 37 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23   67.......... !"#
> 0070  24 25 26 27 28 29                                 $%&'()
> 
> 
> HTH,
> Randy Jennings
> 
> The squirrels are your friends! 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Updated pa4 Tarball & Makefule
Date: Sat, 10 Mar 2007 03:36:57 -0800
Lines: 17
Distribution: su
Message-ID: <esu5ca$7bi$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173526731 7538 171.64.74.54 (10 Mar 2007 11:38:51 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
Xref: shelby.stanford.edu su.class.cs244a:12246

Hi folks-

In response to some difficulties that have cropped up with the pa4 
tarball, there is now a new version posted on the website.  This version 
should clear up the linker errors that were cropping up earlier, and 
also includes a simplified system for selecting what reference binaries 
you want to build- take a look at the flagged section in the Makefile 
for help.  The reference sr binary is also included.

One other thing that I've noticed- even if you told your proxy (or the 
echo server) to listen on all interfaces, it seems that this doesn't 
always take if you've attached your code to a VNS node with multiple IPs 
(such as the vrouter node).  If you're getting refused connections or 
other problems in this situation, make sure that you try all of the IPs 
on the node.

Clay
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: weird Makefile output
Date: Sat, 10 Mar 2007 04:14:34 -0800
Lines: 8
Distribution: su
Message-ID: <esu7eu$b9s$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173528862 11580 128.12.194.72 (10 Mar 2007 12:14:22 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:12247

When I make my router code, I can see the Makefile compiling the code 
that I have in my sr folder, but it's still saying "using reference sr".

Looking at the Makefile, this output seems to be hardcoded to be print 
out even if I'm using my own router code, and I end up with my own sr 
executable afterwards. What's going on?

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: weird default proxy output
Date: Sat, 10 Mar 2007 04:19:56 -0800
Lines: 30
Distribution: su
Message-ID: <esu7p1$bjo$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173529185 11896 128.12.194.72 (10 Mar 2007 12:19:45 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Xref: shelby.stanford.edu su.class.cs244a:12248

Currently, I'm using the reference proxy, the reference STCP impl, and 
my own router code. I'm using the latest tarball.

proxy is mapped to our_stcp_proxy:
lrwxr-xr-x 1 yfw operator     14 Mar 10 04:10 proxy -> our_stcp_proxy

myth8:~/CS244A/hw4/pa4> ./proxy
usage: ./proxy [-U] [VNS options]
   where VNS options are zero or more of:
   -t topo id
   -v host
   -s VNS server
   -p VNS port
   -r routing table
   -l logfile

myth8:~/CS244A/hw4/pa4> ./proxy -U -t 229 -v vhost -s vns-1.stanford.edu 
-p 8000 -r sr/rtable.vhost -l log.txt
usage: ./proxy [-U] [VNS options]
   where VNS options are zero or more of:
   -t topo id
   -v host
   -s VNS server
   -p VNS port
   -r routing table
   -l logfile

Err, oops. I do believe that there is a tiny bug in the reference proxy. :)

-Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: weird Makefile output
Date: Sat, 10 Mar 2007 04:32:43 -0800
Lines: 17
Distribution: su
Message-ID: <esu8gv$c5s$1@news.Stanford.EDU>
References: <esu7eu$b9s$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173529951 12476 128.12.194.72 (10 Mar 2007 12:32:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esu7eu$b9s$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12249

Also:
make: *** No rule to make target `proxy.c', needed by 
`our_stcp_your_proxy'.  Stop.

I'm not sure how to fix this one.

-Yangfan

Yangfan Wang wrote:
> When I make my router code, I can see the Makefile compiling the code 
> that I have in my sr folder, but it's still saying "using reference sr".
> 
> Looking at the Makefile, this output seems to be hardcoded to be print 
> out even if I'm using my own router code, and I end up with my own sr 
> executable afterwards. What's going on?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sat, 10 Mar 2007 13:32:56 -0800
Lines: 144
Distribution: su
Message-ID: <esv85r$b3k$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU> <ests4e$n2c$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173562363 11380 127.0.0.1 (10 Mar 2007 21:32:43 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:12250

Did anyone get this to work? Following is what I see when I tried (using 
only reference implementations, that is)

Any ideas? Am I doing something wrong?

Server
=====
>> ./stcp_echo_server -t 216 -v vrouter -r rtable
********************
Destination: 192.168.129.60
  Gateway : 192.168.129.60
  Mask : 255.255.255.255
  Interface : eth1
Destination: 192.168.129.62
  Gateway : 192.168.129.62
  Mask : 255.255.255.255
  Interface : eth2
Destination: 0.0.0.0
  Gateway : 172.24.74.17
  Mask : 0.0.0.0
  Interface : eth0
********************
Client pepe connecting to Server 171.67.71.19:12345
Requesting topology 216
Sending c_open (type=1 len=108)
Received Hardware Info with 18 entries
Interface: eth0
Speed: 0
Hardware Address: 70:00:00:d8:00:02
Ethernet IP: 192.168.129.58
Subnet: 0.0.0.0
Mask: 0.0.0.0
Interface: eth1
Speed: 0
Hardware Address: 70:00:00:d8:00:03
Ethernet IP: 192.168.129.59
Subnet: 0.0.0.0
Mask: 0.0.0.0
Interface: eth2
Speed: 0
Hardware Address: 70:00:00:d8:00:05
Ethernet IP: 192.168.129.61
Subnet: 0.0.0.0
Mask: 0.0.0.0
Interface: eth0
  hardware address 70:00:00:d8:00:02
  ip address 192.168.129.58
Interface: eth1
  hardware address 70:00:00:d8:00:03
  ip address 192.168.129.59
Interface: eth2
  hardware address 70:00:00:d8:00:05
  ip address 192.168.129.61
Echo server running on port 1792
-> received ARP request from 192.168.129.62 on interface eth2
 <- sent ARP reply to 192.168.129.62 on interface eth2
-> received IP packet [src:192.168.129.62][dst:192.168.129.61]
* routing packet to ip 192.168.129.62 on interface eth2
<- sending arp request for ip 192.168.129.62 on interface eth2
* added ip packet  to arp queue
-> received ARP reply from 192.168.129.62
<- sending queued packet
Attempting to send packet out on interface eth2
* routing packet to ip 192.168.129.62 on interface eth2
Attempting to send packet out on interface eth2
* routing packet to ip 192.168.129.62 on interface eth2
Attempting to send packet out on interface eth2
* routing packet to ip 192.168.129.62 on interface eth2
Attempting to send packet out on interface eth2
* routing packet to ip 192.168.129.62 on interface eth2
Attempting to send packet out on interface eth2
* routing packet to ip 192.168.129.62 on interface eth2
Attempting to send packet out on interface eth2
sd = myaccept(bindsd, &peer_addr, &peer_addr_len): Software caused 
connection abort

Client
======
>> ./stcp_echo_client -t 216 -v vhost -r rtable.vhost 192.168.129.61
********************
Destination: 0.0.0.0
  Gateway : 192.168.129.61
  Mask : 0.0.0.0
  Interface : eth0
********************
Client pepe connecting to Server 171.67.71.19:12345
Requesting topology 216
Sending c_open (type=1 len=108)
Received Hardware Info with 6 entries
Interface: eth0
Speed: 0
Hardware Address: 70:00:00:d8:00:06
Ethernet IP: 192.168.129.62
Subnet: 0.0.0.0
Mask: 0.0.0.0
Interface: eth0
  hardware address 70:00:00:d8:00:06
  ip address 192.168.129.62
addr is 1031907520
* routing packet to default gateway at 192.168.129.61 on interface eth0
<- sending arp request for ip 192.168.129.61 on interface eth0
* added ip packet  to arp queue
-> received ARP reply from 192.168.129.61
<- sending queued packet
Attempting to send packet out on interface eth0
-> received ARP request from 192.168.129.61 on interface eth0
 <- sent ARP reply to 192.168.129.61 on interface eth0
-> received IP packet [src:192.168.129.61][dst:192.168.129.62]
stcp_echo_client: connection_demux.c:153: _mysock_enqueue_connection: 
Assertion `ctx && ctx->listening && ctx->bound' failed.
Aborted (core dumped)


"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:ests4e$n2c$1@news.Stanford.EDU...
> You should be able to connect the echo client to the vhost and the echo 
> server to the vrouter.  Just pass them the appropriate rtable files and 
> specify the vnode name using the -v option.
>
> Clay
>
> Randy Jennings wrote:
>> Obviously, we have to hook up stcp_echo_server to a VNS topology because 
>> the VNS parameters are required.
>>
>> I thought since the parameters were optional, that we could hook up 
>> stcp_echo_client to run just on a normal host (as we only get one VNS 
>> host to play with).  Well, I was wrong.  It connects up to a default 
>> topology of 28.  It even gets arp requests.  However, it cannot send any 
>> packets out because it gets no arp responses.
>>
>> I tried to connect it up to my topology, but as the server was there, it 
>> could not connect (which, BTW, I think is an improvement over silent 
>> failure; thank you).
>>
>> So my question is, how do we use stcp_echo_client and stcp_echo_server 
>> together?
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sat, 10 Mar 2007 16:45:16 -0500
Lines: 38
Distribution: su
Message-ID: <esv8tn$beq$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU> <ests4e$n2c$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173563128 11738 127.0.0.1 (10 Mar 2007 21:45:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12251

If we hook the client up to the vhost and the server up to the vrouter, 
where do we put our router?  If we're using our router in with these two, 
then what's the point of the echo server/client exercise just to test that 
our STCP implementation works with VNS?

Seth

"Clay Collier" <ccollier@stanford.edu> wrote in message 
news:ests4e$n2c$1@news.Stanford.EDU...
> You should be able to connect the echo client to the vhost and the echo 
> server to the vrouter.  Just pass them the appropriate rtable files and 
> specify the vnode name using the -v option.
>
> Clay
>
> Randy Jennings wrote:
>> Obviously, we have to hook up stcp_echo_server to a VNS topology because 
>> the VNS parameters are required.
>>
>> I thought since the parameters were optional, that we could hook up 
>> stcp_echo_client to run just on a normal host (as we only get one VNS 
>> host to play with).  Well, I was wrong.  It connects up to a default 
>> topology of 28.  It even gets arp requests.  However, it cannot send any 
>> packets out because it gets no arp responses.
>>
>> I tried to connect it up to my topology, but as the server was there, it 
>> could not connect (which, BTW, I think is an improvement over silent 
>> failure; thank you).
>>
>> So my question is, how do we use stcp_echo_client and stcp_echo_server 
>> together?
>>
>> Sincerely,
>> Randy Jennings
>>
>> The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: "Seth Wright" <orion@cs.stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PA4 sanity check
Date: Sat, 10 Mar 2007 17:08:48 -0500
Lines: 64
Distribution: su
Message-ID: <esva9b$c62$1@news.Stanford.EDU>
References: <ess838$4j$1@news.Stanford.EDU> <estarv$36b$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173564524 12482 127.0.0.1 (10 Mar 2007 22:08:44 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12252

Well, looks like I was wrong.  It looks like you're totally right about 
being able to use Firefox, etc with the proxy.  Once I got stuff up and 
running, I had my router in the middle, with my proxy on the vhost and then 
configured firefox to hit the proxy (192.168....) and that started working 
(albeit slowly).  So, it looks like my assumption of proxyget using STCP was 
off.  Sorry about that - I do have to say that the assignment itself was 
somewhat confusing in this regards.

Seth

"Seth Wright" <orion@cs.stanford.edu> wrote in message 
news:estarv$36b$1@news.Stanford.EDU...
>I don't know.  I read this to be basically that we're using what we put 
>together for part C in HW3, but then hooking it up with VNS by doing the 
>sr_api_init and the single change to gethostbyname.  The proxy, like in 
>HW3, would expect STCP packets coming in but send normal TCP packets going 
>out. The difference is that since we're hooked into VNS both the STCP and 
>TCP packets will be pushed through our router.  To that end, it seems to me 
>that the client for our proxy will still be the STCP version of proxyget. 
>But that the proxy will communicate to the outside world using normal TCP 
>just routed through our router implementation.  Here's my flow of how I 
>read a request to go:
> proxyget->STCP->VNS->our router->VNS->STCP->proxy->TCP->VNS->our 
> router->VNS->TCP->web server and back again.
>
> Now, I may be parsing the assignment this way because it's easier and we 
> have STCP talking to STCP and TCP talking to TCP but he assignment did 
> say: "You should not have to write much code to get things working as all 
> functional components should already be completed."
>
> Anyway, I would really like a TA's feedback on this as I found this the 
> most confusing part of the assignment.
>
> -Seth
>
> "Kevin Hart" <kevin.hart@hp.com> wrote in message 
> news:ess838$4j$1@news.Stanford.EDU...
>> The drawings and discussion in the PA4 handout are confusing me because 
>> they don't seem to acknowledge the two-sidedness of the proxy.  I have a 
>> couple of questions...
>>
>> 1) The handout says "your host should act exactly as the web proxy did 
>> over the system socket libraries."  I'm assuming that means we can 
>> configure a web browser to use the proxy as a real HTTP proxy for surfing 
>> the web as we did in PA1. But doesn't that mean the passive side of the 
>> proxy needs to be straight TCP sockets (to receive connections from a 
>> browser), and the active side needs to be STCP sockets (to interact with 
>> the VNS system)?  That would be a 180-degree reversal of what we just did 
>> to the proxy for PA3, right?
>>
>> 2) The packets we'll be receiving when our STCP calls 
>> stcp_network_receive will be real TCP packets this time (since the thing 
>> we're connecting to on the active side of the proxy will be a real 
>> network stack), right?
>>
>> Thanks,
>>
>> Kevin
>>
>>
>
> 


.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: PS4, Q6
Date: Sat, 10 Mar 2007 17:27:27 -0500
Lines: 8
Distribution: su
Message-ID: <esvbft$crr$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173565757 13179 127.0.0.1 (10 Mar 2007 22:29:17 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:12253

The generator is x^3 + 1, so 4 bits are needed to represent the 
remainder.  It seems there should be 4 registers in the diagram: r_0, 
r_1, r_2, r_3.

Only 3 registers are shown.  Am I missing something here?

Thanks,
Jin
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sat, 10 Mar 2007 14:30:35 -0800
Lines: 172
Distribution: su
Message-ID: <esvbht$cvc$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU> <ests4e$n2c$1@news.Stanford.EDU> <esv85r$b3k$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173565821 13292 128.12.194.72 (10 Mar 2007 22:30:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esv85r$b3k$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12254

Riju,

make sure that you've started two instances of your sr router, one 
sitting on vrouter and one sitting on vhost. Then hook up the echo 
server to vrouter and the echo client to vhost, which you did. (So you 
should have 4 programs running total.)

Make sure that you're giving the echo client the right IP address. The 
only IP address that worked for me was the one on the vrouter that 
connected to the vhost. (The vhost's gateway to the vrouter, in other 
words.)

I'm not sure what the expected output is. For me at least, nothing 
crashes, and I can see some packets going from client to server, and the 
packets do get echoed back.

Disclaimer: I'm not a TA, but I hope that helped.

-Yangfan

Riju Kallivalappil wrote:
> Did anyone get this to work? Following is what I see when I tried (using 
> only reference implementations, that is)
> 
> Any ideas? Am I doing something wrong?
> 
> Server
> =====
> 
>>>./stcp_echo_server -t 216 -v vrouter -r rtable
> 
> ********************
> Destination: 192.168.129.60
>   Gateway : 192.168.129.60
>   Mask : 255.255.255.255
>   Interface : eth1
> Destination: 192.168.129.62
>   Gateway : 192.168.129.62
>   Mask : 255.255.255.255
>   Interface : eth2
> Destination: 0.0.0.0
>   Gateway : 172.24.74.17
>   Mask : 0.0.0.0
>   Interface : eth0
> ********************
> Client pepe connecting to Server 171.67.71.19:12345
> Requesting topology 216
> Sending c_open (type=1 len=108)
> Received Hardware Info with 18 entries
> Interface: eth0
> Speed: 0
> Hardware Address: 70:00:00:d8:00:02
> Ethernet IP: 192.168.129.58
> Subnet: 0.0.0.0
> Mask: 0.0.0.0
> Interface: eth1
> Speed: 0
> Hardware Address: 70:00:00:d8:00:03
> Ethernet IP: 192.168.129.59
> Subnet: 0.0.0.0
> Mask: 0.0.0.0
> Interface: eth2
> Speed: 0
> Hardware Address: 70:00:00:d8:00:05
> Ethernet IP: 192.168.129.61
> Subnet: 0.0.0.0
> Mask: 0.0.0.0
> Interface: eth0
>   hardware address 70:00:00:d8:00:02
>   ip address 192.168.129.58
> Interface: eth1
>   hardware address 70:00:00:d8:00:03
>   ip address 192.168.129.59
> Interface: eth2
>   hardware address 70:00:00:d8:00:05
>   ip address 192.168.129.61
> Echo server running on port 1792
> -> received ARP request from 192.168.129.62 on interface eth2
>  <- sent ARP reply to 192.168.129.62 on interface eth2
> -> received IP packet [src:192.168.129.62][dst:192.168.129.61]
> * routing packet to ip 192.168.129.62 on interface eth2
> <- sending arp request for ip 192.168.129.62 on interface eth2
> * added ip packet  to arp queue
> -> received ARP reply from 192.168.129.62
> <- sending queued packet
> Attempting to send packet out on interface eth2
> * routing packet to ip 192.168.129.62 on interface eth2
> Attempting to send packet out on interface eth2
> * routing packet to ip 192.168.129.62 on interface eth2
> Attempting to send packet out on interface eth2
> * routing packet to ip 192.168.129.62 on interface eth2
> Attempting to send packet out on interface eth2
> * routing packet to ip 192.168.129.62 on interface eth2
> Attempting to send packet out on interface eth2
> * routing packet to ip 192.168.129.62 on interface eth2
> Attempting to send packet out on interface eth2
> sd = myaccept(bindsd, &peer_addr, &peer_addr_len): Software caused 
> connection abort
> 
> Client
> ======
> 
>>>./stcp_echo_client -t 216 -v vhost -r rtable.vhost 192.168.129.61
> 
> ********************
> Destination: 0.0.0.0
>   Gateway : 192.168.129.61
>   Mask : 0.0.0.0
>   Interface : eth0
> ********************
> Client pepe connecting to Server 171.67.71.19:12345
> Requesting topology 216
> Sending c_open (type=1 len=108)
> Received Hardware Info with 6 entries
> Interface: eth0
> Speed: 0
> Hardware Address: 70:00:00:d8:00:06
> Ethernet IP: 192.168.129.62
> Subnet: 0.0.0.0
> Mask: 0.0.0.0
> Interface: eth0
>   hardware address 70:00:00:d8:00:06
>   ip address 192.168.129.62
> addr is 1031907520
> * routing packet to default gateway at 192.168.129.61 on interface eth0
> <- sending arp request for ip 192.168.129.61 on interface eth0
> * added ip packet  to arp queue
> -> received ARP reply from 192.168.129.61
> <- sending queued packet
> Attempting to send packet out on interface eth0
> -> received ARP request from 192.168.129.61 on interface eth0
>  <- sent ARP reply to 192.168.129.61 on interface eth0
> -> received IP packet [src:192.168.129.61][dst:192.168.129.62]
> stcp_echo_client: connection_demux.c:153: _mysock_enqueue_connection: 
> Assertion `ctx && ctx->listening && ctx->bound' failed.
> Aborted (core dumped)
> 
> 
> "Clay Collier" <ccollier@stanford.edu> wrote in message 
> news:ests4e$n2c$1@news.Stanford.EDU...
> 
>>You should be able to connect the echo client to the vhost and the echo 
>>server to the vrouter.  Just pass them the appropriate rtable files and 
>>specify the vnode name using the -v option.
>>
>>Clay
>>
>>Randy Jennings wrote:
>>
>>>Obviously, we have to hook up stcp_echo_server to a VNS topology because 
>>>the VNS parameters are required.
>>>
>>>I thought since the parameters were optional, that we could hook up 
>>>stcp_echo_client to run just on a normal host (as we only get one VNS 
>>>host to play with).  Well, I was wrong.  It connects up to a default 
>>>topology of 28.  It even gets arp requests.  However, it cannot send any 
>>>packets out because it gets no arp responses.
>>>
>>>I tried to connect it up to my topology, but as the server was there, it 
>>>could not connect (which, BTW, I think is an improvement over silent 
>>>failure; thank you).
>>>
>>>So my question is, how do we use stcp_echo_client and stcp_echo_server 
>>>together?
>>>
>>>Sincerely,
>>>Randy Jennings
>>>
>>>The squirrels are your friends! 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Randy Jennings" <randyj@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: PS4, Q6
Date: Sat, 10 Mar 2007 14:56:13 -0800
Lines: 14
Distribution: su
Message-ID: <esvd10$dni$1@news.Stanford.EDU>
References: <esvbft$crr$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173567328 14066 127.0.0.1 (10 Mar 2007 22:55:28 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: shelby.stanford.edu su.class.cs244a:12255

> The generator is x^3 + 1, so 4 bits are needed to represent the remainder. 
> It seems there should be 4 registers in the diagram: r_0, r_1, r_2, r_3.
>
> Only 3 registers are shown.  Am I missing something here?
Binary arithmetic is a little bit different.  I expect this will be 
explained in class, but you only need 3 bits for the remainder (if there is 
a 1 in the MSb of both x and y, you can xor x from y even if x > y).

Sincerely,
Randy Jennings

The squirrels are your friends! 


.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: weird default proxy output
Date: Sat, 10 Mar 2007 16:11:04 -0800
Lines: 36
Distribution: su
Message-ID: <esvhif$g2r$1@news.Stanford.EDU>
References: <esu7p1$bjo$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173571984 16475 171.64.74.54 (11 Mar 2007 00:13:04 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esu7p1$bjo$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12256

Actually, the -p option is to set the port that the proxy talks to the 
VNS server on.  Leave off the -p option (the default is the only port 
our server is listening on) and put that 8000 at the end of everything else.

Clay
Yangfan Wang wrote:
> Currently, I'm using the reference proxy, the reference STCP impl, and 
> my own router code. I'm using the latest tarball.
> 
> proxy is mapped to our_stcp_proxy:
> lrwxr-xr-x 1 yfw operator     14 Mar 10 04:10 proxy -> our_stcp_proxy
> 
> myth8:~/CS244A/hw4/pa4> ./proxy
> usage: ./proxy [-U] [VNS options]
>   where VNS options are zero or more of:
>   -t topo id
>   -v host
>   -s VNS server
>   -p VNS port
>   -r routing table
>   -l logfile
> 
> myth8:~/CS244A/hw4/pa4> ./proxy -U -t 229 -v vhost -s vns-1.stanford.edu 
> -p 8000 -r sr/rtable.vhost -l log.txt
> usage: ./proxy [-U] [VNS options]
>   where VNS options are zero or more of:
>   -t topo id
>   -v host
>   -s VNS server
>   -p VNS port
>   -r routing table
>   -l logfile
> 
> Err, oops. I do believe that there is a tiny bug in the reference proxy. :)
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: weird Makefile output
Date: Sat, 10 Mar 2007 16:13:33 -0800
Lines: 20
Distribution: su
Message-ID: <esvhn3$g2r$2@news.Stanford.EDU>
References: <esu7eu$b9s$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173572133 16475 171.64.74.54 (11 Mar 2007 00:15:33 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esu7eu$b9s$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12257

 > Looking at the Makefile, this output seems to be hardcoded to be print
 > out even if I'm using my own router code, and I end up with my own sr
 > executable afterwards.
Exactly- the 'Using reference sr' message is spurious- just specify in 
the README that you are using your own sr, and make sure you specify the 
source files for your router in the Makefile.  We'll be able to tell if 
you've built your own router or not.

Clay


Yangfan Wang wrote:
> When I make my router code, I can see the Makefile compiling the code 
> that I have in my sr folder, but it's still saying "using reference sr".
> 
> Looking at the Makefile, this output seems to be hardcoded to be print 
> out even if I'm using my own router code, and I end up with my own sr 
> executable afterwards. What's going on?
> 
> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: Clay Collier <ccollier@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: weird Makefile output
Date: Sat, 10 Mar 2007 16:16:23 -0800
Lines: 29
Distribution: su
Message-ID: <esvhsd$g2r$3@news.Stanford.EDU>
References: <esu7eu$b9s$1@news.Stanford.EDU> <esu8gv$c5s$1@news.Stanford.EDU>
NNTP-Posting-Host: tybalt.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173572303 16475 171.64.74.54 (11 Mar 2007 00:18:23 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070102)
In-Reply-To: <esu8gv$c5s$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12258

This message means that you have specified that proxy.c is a requisite 
for one of your targets, but the build process can't find it.  When Make 
can't find a file, it looks for a rule to use to build the file (which 
obviously doesn't exist in this case), which is why you get that 
specific message.

If you put all of your proxy sources in the 'myproxy' directory, make 
sure that your source file as 'myproxy/proxy.c' rather than just 'proxy.c'.

Clay

Yangfan Wang wrote:
> Also:
> make: *** No rule to make target `proxy.c', needed by 
> `our_stcp_your_proxy'.  Stop.
> 
> I'm not sure how to fix this one.
> 
> -Yangfan
> 
> Yangfan Wang wrote:
>> When I make my router code, I can see the Makefile compiling the code 
>> that I have in my sr folder, but it's still saying "using reference sr".
>>
>> Looking at the Makefile, this output seems to be hardcoded to be print 
>> out even if I'm using my own router code, and I end up with my own sr 
>> executable afterwards. What's going on?
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Riju Kallivalappil" <riju@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sat, 10 Mar 2007 16:46:59 -0800
Lines: 178
Distribution: su
Message-ID: <esvjhu$hf4$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU> <ests4e$n2c$1@news.Stanford.EDU> <esv85r$b3k$1@news.Stanford.EDU> <esvbht$cvc$1@news.Stanford.EDU>
X-Trace: news.Stanford.EDU 1173574014 17892 127.0.0.1 (11 Mar 2007 00:46:54 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Xref: shelby.stanford.edu su.class.cs244a:12259

H'mm.. That's interesting... So, in effect you are connecting two VNS 
clients each to the same virtual host in your topology? I wonder how the 
packets get routed by the VNS system in this case.

"Yangfan Wang" <yfw@stanford.edu> wrote in message 
news:esvbht$cvc$1@news.Stanford.EDU...
> Riju,
>
> make sure that you've started two instances of your sr router, one sitting 
> on vrouter and one sitting on vhost. Then hook up the echo server to 
> vrouter and the echo client to vhost, which you did. (So you should have 4 
> programs running total.)
>
> Make sure that you're giving the echo client the right IP address. The 
> only IP address that worked for me was the one on the vrouter that 
> connected to the vhost. (The vhost's gateway to the vrouter, in other 
> words.)
>
> I'm not sure what the expected output is. For me at least, nothing 
> crashes, and I can see some packets going from client to server, and the 
> packets do get echoed back.
>
> Disclaimer: I'm not a TA, but I hope that helped.
>
> -Yangfan
>
> Riju Kallivalappil wrote:
>> Did anyone get this to work? Following is what I see when I tried (using 
>> only reference implementations, that is)
>>
>> Any ideas? Am I doing something wrong?
>>
>> Server
>> =====
>>
>>>>./stcp_echo_server -t 216 -v vrouter -r rtable
>>
>> ********************
>> Destination: 192.168.129.60
>>   Gateway : 192.168.129.60
>>   Mask : 255.255.255.255
>>   Interface : eth1
>> Destination: 192.168.129.62
>>   Gateway : 192.168.129.62
>>   Mask : 255.255.255.255
>>   Interface : eth2
>> Destination: 0.0.0.0
>>   Gateway : 172.24.74.17
>>   Mask : 0.0.0.0
>>   Interface : eth0
>> ********************
>> Client pepe connecting to Server 171.67.71.19:12345
>> Requesting topology 216
>> Sending c_open (type=1 len=108)
>> Received Hardware Info with 18 entries
>> Interface: eth0
>> Speed: 0
>> Hardware Address: 70:00:00:d8:00:02
>> Ethernet IP: 192.168.129.58
>> Subnet: 0.0.0.0
>> Mask: 0.0.0.0
>> Interface: eth1
>> Speed: 0
>> Hardware Address: 70:00:00:d8:00:03
>> Ethernet IP: 192.168.129.59
>> Subnet: 0.0.0.0
>> Mask: 0.0.0.0
>> Interface: eth2
>> Speed: 0
>> Hardware Address: 70:00:00:d8:00:05
>> Ethernet IP: 192.168.129.61
>> Subnet: 0.0.0.0
>> Mask: 0.0.0.0
>> Interface: eth0
>>   hardware address 70:00:00:d8:00:02
>>   ip address 192.168.129.58
>> Interface: eth1
>>   hardware address 70:00:00:d8:00:03
>>   ip address 192.168.129.59
>> Interface: eth2
>>   hardware address 70:00:00:d8:00:05
>>   ip address 192.168.129.61
>> Echo server running on port 1792
>> -> received ARP request from 192.168.129.62 on interface eth2
>>  <- sent ARP reply to 192.168.129.62 on interface eth2
>> -> received IP packet [src:192.168.129.62][dst:192.168.129.61]
>> * routing packet to ip 192.168.129.62 on interface eth2
>> <- sending arp request for ip 192.168.129.62 on interface eth2
>> * added ip packet  to arp queue
>> -> received ARP reply from 192.168.129.62
>> <- sending queued packet
>> Attempting to send packet out on interface eth2
>> * routing packet to ip 192.168.129.62 on interface eth2
>> Attempting to send packet out on interface eth2
>> * routing packet to ip 192.168.129.62 on interface eth2
>> Attempting to send packet out on interface eth2
>> * routing packet to ip 192.168.129.62 on interface eth2
>> Attempting to send packet out on interface eth2
>> * routing packet to ip 192.168.129.62 on interface eth2
>> Attempting to send packet out on interface eth2
>> * routing packet to ip 192.168.129.62 on interface eth2
>> Attempting to send packet out on interface eth2
>> sd = myaccept(bindsd, &peer_addr, &peer_addr_len): Software caused 
>> connection abort
>>
>> Client
>> ======
>>
>>>>./stcp_echo_client -t 216 -v vhost -r rtable.vhost 192.168.129.61
>>
>> ********************
>> Destination: 0.0.0.0
>>   Gateway : 192.168.129.61
>>   Mask : 0.0.0.0
>>   Interface : eth0
>> ********************
>> Client pepe connecting to Server 171.67.71.19:12345
>> Requesting topology 216
>> Sending c_open (type=1 len=108)
>> Received Hardware Info with 6 entries
>> Interface: eth0
>> Speed: 0
>> Hardware Address: 70:00:00:d8:00:06
>> Ethernet IP: 192.168.129.62
>> Subnet: 0.0.0.0
>> Mask: 0.0.0.0
>> Interface: eth0
>>   hardware address 70:00:00:d8:00:06
>>   ip address 192.168.129.62
>> addr is 1031907520
>> * routing packet to default gateway at 192.168.129.61 on interface eth0
>> <- sending arp request for ip 192.168.129.61 on interface eth0
>> * added ip packet  to arp queue
>> -> received ARP reply from 192.168.129.61
>> <- sending queued packet
>> Attempting to send packet out on interface eth0
>> -> received ARP request from 192.168.129.61 on interface eth0
>>  <- sent ARP reply to 192.168.129.61 on interface eth0
>> -> received IP packet [src:192.168.129.61][dst:192.168.129.62]
>> stcp_echo_client: connection_demux.c:153: _mysock_enqueue_connection: 
>> Assertion `ctx && ctx->listening && ctx->bound' failed.
>> Aborted (core dumped)
>>
>>
>> "Clay Collier" <ccollier@stanford.edu> wrote in message 
>> news:ests4e$n2c$1@news.Stanford.EDU...
>>
>>>You should be able to connect the echo client to the vhost and the echo 
>>>server to the vrouter.  Just pass them the appropriate rtable files and 
>>>specify the vnode name using the -v option.
>>>
>>>Clay
>>>
>>>Randy Jennings wrote:
>>>
>>>>Obviously, we have to hook up stcp_echo_server to a VNS topology because 
>>>>the VNS parameters are required.
>>>>
>>>>I thought since the parameters were optional, that we could hook up 
>>>>stcp_echo_client to run just on a normal host (as we only get one VNS 
>>>>host to play with).  Well, I was wrong.  It connects up to a default 
>>>>topology of 28.  It even gets arp requests.  However, it cannot send any 
>>>>packets out because it gets no arp responses.
>>>>
>>>>I tried to connect it up to my topology, but as the server was there, it 
>>>>could not connect (which, BTW, I think is an improvement over silent 
>>>>failure; thank you).
>>>>
>>>>So my question is, how do we use stcp_echo_client and stcp_echo_server 
>>>>together?
>>>>
>>>>Sincerely,
>>>>Randy Jennings
>>>>
>>>>The squirrels are your friends!
>>
>> 

.

Path: shelby.stanford.edu!not-for-mail
From: Jin Wang <jinwang@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Problems compiling with g++
Date: Sat, 10 Mar 2007 23:57:18 -0500
Lines: 9
Distribution: su
Message-ID: <et02av$ppu$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173589151 26430 127.0.0.1 (11 Mar 2007 04:59:11 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
Xref: shelby.stanford.edu su.class.cs244a:12260

If g++ is substituted for gcc, the Makefile seems to give "undefined 
reference" errors during compilation.

Is there a way to work around this, or must we rewrite our C++ code from 
transport.c in C?


--Jin

.

Path: shelby.stanford.edu!not-for-mail
From: "Nishant Patil" <nppatil@stanford.edu>
Newsgroups: su.class.cs244a
Subject: proxyget and stcp
Date: Sun, 11 Mar 2007 01:32:23 -0800
Lines: 19
Distribution: su
Message-ID: <et0i7f$8vu$1@news.Stanford.EDU>
NNTP-Posting-Host: patil-pc.stanford.edu
X-Trace: news.Stanford.EDU 1173605423 9214 172.24.74.169 (11 Mar 2007 09:30:23 GMT)
X-Complaints-To: news@news.stanford.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
Xref: shelby.stanford.edu su.class.cs244a:12261

Hi,

            I'm having some trouble getting proxyget to talk to proxy (I'm 
using the reference proxy).  I then changed proxyget to use regular TCP 
socket calls, and I was able to download webpages.  I was also able to get 
traffic using telnet and firefox which use TCP.  Is there a reason why I 
cannot connect to proxy (server-side) by making STCP calls from proxyget 
(client-side) ?



Thanks,

Nishant





.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: where to stick stcp_echo_client
Date: Sun, 11 Mar 2007 04:25:36 -0700
Lines: 191
Distribution: su
Message-ID: <et0ov1$e66$1@news.Stanford.EDU>
References: <essg44$8pa$1@news.Stanford.EDU> <ests4e$n2c$1@news.Stanford.EDU> <esv85r$b3k$1@news.Stanford.EDU> <esvbht$cvc$1@news.Stanford.EDU> <esvjhu$hf4$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173612321 14534 128.12.194.72 (11 Mar 2007 11:25:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esvjhu$hf4$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12262

I'm not sure exactly how it works either, since our router code should 
reject any data directly addressed to the router with a bad port number 
ICMP packet. It is supposed to be a router, not a host, after all.

-Yangfan

Riju Kallivalappil wrote:
> H'mm.. That's interesting... So, in effect you are connecting two VNS 
> clients each to the same virtual host in your topology? I wonder how the 
> packets get routed by the VNS system in this case.
> 
> "Yangfan Wang" <yfw@stanford.edu> wrote in message 
> news:esvbht$cvc$1@news.Stanford.EDU...
> 
>>Riju,
>>
>>make sure that you've started two instances of your sr router, one sitting 
>>on vrouter and one sitting on vhost. Then hook up the echo server to 
>>vrouter and the echo client to vhost, which you did. (So you should have 4 
>>programs running total.)
>>
>>Make sure that you're giving the echo client the right IP address. The 
>>only IP address that worked for me was the one on the vrouter that 
>>connected to the vhost. (The vhost's gateway to the vrouter, in other 
>>words.)
>>
>>I'm not sure what the expected output is. For me at least, nothing 
>>crashes, and I can see some packets going from client to server, and the 
>>packets do get echoed back.
>>
>>Disclaimer: I'm not a TA, but I hope that helped.
>>
>>-Yangfan
>>
>>Riju Kallivalappil wrote:
>>
>>>Did anyone get this to work? Following is what I see when I tried (using 
>>>only reference implementations, that is)
>>>
>>>Any ideas? Am I doing something wrong?
>>>
>>>Server
>>>=====
>>>
>>>
>>>>>./stcp_echo_server -t 216 -v vrouter -r rtable
>>>
>>>********************
>>>Destination: 192.168.129.60
>>>  Gateway : 192.168.129.60
>>>  Mask : 255.255.255.255
>>>  Interface : eth1
>>>Destination: 192.168.129.62
>>>  Gateway : 192.168.129.62
>>>  Mask : 255.255.255.255
>>>  Interface : eth2
>>>Destination: 0.0.0.0
>>>  Gateway : 172.24.74.17
>>>  Mask : 0.0.0.0
>>>  Interface : eth0
>>>********************
>>>Client pepe connecting to Server 171.67.71.19:12345
>>>Requesting topology 216
>>>Sending c_open (type=1 len=108)
>>>Received Hardware Info with 18 entries
>>>Interface: eth0
>>>Speed: 0
>>>Hardware Address: 70:00:00:d8:00:02
>>>Ethernet IP: 192.168.129.58
>>>Subnet: 0.0.0.0
>>>Mask: 0.0.0.0
>>>Interface: eth1
>>>Speed: 0
>>>Hardware Address: 70:00:00:d8:00:03
>>>Ethernet IP: 192.168.129.59
>>>Subnet: 0.0.0.0
>>>Mask: 0.0.0.0
>>>Interface: eth2
>>>Speed: 0
>>>Hardware Address: 70:00:00:d8:00:05
>>>Ethernet IP: 192.168.129.61
>>>Subnet: 0.0.0.0
>>>Mask: 0.0.0.0
>>>Interface: eth0
>>>  hardware address 70:00:00:d8:00:02
>>>  ip address 192.168.129.58
>>>Interface: eth1
>>>  hardware address 70:00:00:d8:00:03
>>>  ip address 192.168.129.59
>>>Interface: eth2
>>>  hardware address 70:00:00:d8:00:05
>>>  ip address 192.168.129.61
>>>Echo server running on port 1792
>>>-> received ARP request from 192.168.129.62 on interface eth2
>>> <- sent ARP reply to 192.168.129.62 on interface eth2
>>>-> received IP packet [src:192.168.129.62][dst:192.168.129.61]
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>><- sending arp request for ip 192.168.129.62 on interface eth2
>>>* added ip packet  to arp queue
>>>-> received ARP reply from 192.168.129.62
>>><- sending queued packet
>>>Attempting to send packet out on interface eth2
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>>Attempting to send packet out on interface eth2
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>>Attempting to send packet out on interface eth2
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>>Attempting to send packet out on interface eth2
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>>Attempting to send packet out on interface eth2
>>>* routing packet to ip 192.168.129.62 on interface eth2
>>>Attempting to send packet out on interface eth2
>>>sd = myaccept(bindsd, &peer_addr, &peer_addr_len): Software caused 
>>>connection abort
>>>
>>>Client
>>>======
>>>
>>>
>>>>>./stcp_echo_client -t 216 -v vhost -r rtable.vhost 192.168.129.61
>>>
>>>********************
>>>Destination: 0.0.0.0
>>>  Gateway : 192.168.129.61
>>>  Mask : 0.0.0.0
>>>  Interface : eth0
>>>********************
>>>Client pepe connecting to Server 171.67.71.19:12345
>>>Requesting topology 216
>>>Sending c_open (type=1 len=108)
>>>Received Hardware Info with 6 entries
>>>Interface: eth0
>>>Speed: 0
>>>Hardware Address: 70:00:00:d8:00:06
>>>Ethernet IP: 192.168.129.62
>>>Subnet: 0.0.0.0
>>>Mask: 0.0.0.0
>>>Interface: eth0
>>>  hardware address 70:00:00:d8:00:06
>>>  ip address 192.168.129.62
>>>addr is 1031907520
>>>* routing packet to default gateway at 192.168.129.61 on interface eth0
>>><- sending arp request for ip 192.168.129.61 on interface eth0
>>>* added ip packet  to arp queue
>>>-> received ARP reply from 192.168.129.61
>>><- sending queued packet
>>>Attempting to send packet out on interface eth0
>>>-> received ARP request from 192.168.129.61 on interface eth0
>>> <- sent ARP reply to 192.168.129.61 on interface eth0
>>>-> received IP packet [src:192.168.129.61][dst:192.168.129.62]
>>>stcp_echo_client: connection_demux.c:153: _mysock_enqueue_connection: 
>>>Assertion `ctx && ctx->listening && ctx->bound' failed.
>>>Aborted (core dumped)
>>>
>>>
>>>"Clay Collier" <ccollier@stanford.edu> wrote in message 
>>>news:ests4e$n2c$1@news.Stanford.EDU...
>>>
>>>
>>>>You should be able to connect the echo client to the vhost and the echo 
>>>>server to the vrouter.  Just pass them the appropriate rtable files and 
>>>>specify the vnode name using the -v option.
>>>>
>>>>Clay
>>>>
>>>>Randy Jennings wrote:
>>>>
>>>>
>>>>>Obviously, we have to hook up stcp_echo_server to a VNS topology because 
>>>>>the VNS parameters are required.
>>>>>
>>>>>I thought since the parameters were optional, that we could hook up 
>>>>>stcp_echo_client to run just on a normal host (as we only get one VNS 
>>>>>host to play with).  Well, I was wrong.  It connects up to a default 
>>>>>topology of 28.  It even gets arp requests.  However, it cannot send any 
>>>>>packets out because it gets no arp responses.
>>>>>
>>>>>I tried to connect it up to my topology, but as the server was there, it 
>>>>>could not connect (which, BTW, I think is an improvement over silent 
>>>>>failure; thank you).
>>>>>
>>>>>So my question is, how do we use stcp_echo_client and stcp_echo_server 
>>>>>together?
>>>>>
>>>>>Sincerely,
>>>>>Randy Jennings
>>>>>
>>>>>The squirrels are your friends!
>>>
>>>
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Yangfan Wang <yfw@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: weird default proxy output
Date: Sun, 11 Mar 2007 04:29:36 -0700
Lines: 46
Distribution: su
Message-ID: <et0p6g$e66$2@news.Stanford.EDU>
References: <esu7p1$bjo$1@news.Stanford.EDU> <esvhif$g2r$1@news.Stanford.EDU>
NNTP-Posting-Host: rescomp-06-80386.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173612561 14534 128.12.194.72 (11 Mar 2007 11:29:21 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <esvhif$g2r$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12263

At which port is your VNS server listening on? This would be useful 
information to have if I want to use my own proxy rather than the 
reference proxy.

-Yangfan

Clay Collier wrote:
> Actually, the -p option is to set the port that the proxy talks to the 
> VNS server on.  Leave off the -p option (the default is the only port 
> our server is listening on) and put that 8000 at the end of everything 
> else.
> 
> Clay
> Yangfan Wang wrote:
> 
>> Currently, I'm using the reference proxy, the reference STCP impl, and 
>> my own router code. I'm using the latest tarball.
>>
>> proxy is mapped to our_stcp_proxy:
>> lrwxr-xr-x 1 yfw operator     14 Mar 10 04:10 proxy -> our_stcp_proxy
>>
>> myth8:~/CS244A/hw4/pa4> ./proxy
>> usage: ./proxy [-U] [VNS options]
>>   where VNS options are zero or more of:
>>   -t topo id
>>   -v host
>>   -s VNS server
>>   -p VNS port
>>   -r routing table
>>   -l logfile
>>
>> myth8:~/CS244A/hw4/pa4> ./proxy -U -t 229 -v vhost -s 
>> vns-1.stanford.edu -p 8000 -r sr/rtable.vhost -l log.txt
>> usage: ./proxy [-U] [VNS options]
>>   where VNS options are zero or more of:
>>   -t topo id
>>   -v host
>>   -s VNS server
>>   -p VNS port
>>   -r routing table
>>   -l logfile
>>
>> Err, oops. I do believe that there is a tiny bug in the reference 
>> proxy. :)
>>
>> -Yangfan
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: Problems compiling with g++
Date: Sun, 11 Mar 2007 05:44:31 -0700
Lines: 16
Distribution: su
Message-ID: <et0tji$hn3$1@news.Stanford.EDU>
References: <et02av$ppu$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173617074 18147 128.12.133.106 (11 Mar 2007 12:44:34 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <et02av$ppu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12264

Umm.. I thought you were supposed to code everything in C except for the 
proxy (which we allowed c++).

For part 4, we are using YOUR makefile, so just get it working with 
whatever compiler you want (on the myths) and we will use that one to test.

Jin Wang wrote:
> If g++ is substituted for gcc, the Makefile seems to give "undefined 
> reference" errors during compilation.
> 
> Is there a way to work around this, or must we rewrite our C++ code from 
> transport.c in C?
> 
> 
> --Jin
> 
.

Path: shelby.stanford.edu!not-for-mail
From: "Paul Tarjan (TA)" <ptarjan@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Re: proxyget and stcp
Date: Sun, 11 Mar 2007 05:52:37 -0700
Lines: 25
Distribution: su
Message-ID: <et0u2n$hn3$2@news.Stanford.EDU>
References: <et0i7f$8vu$1@news.Stanford.EDU>
NNTP-Posting-Host: paulinator.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173617559 18147 128.12.133.106 (11 Mar 2007 12:52:39 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <et0i7f$8vu$1@news.Stanford.EDU>
Xref: shelby.stanford.edu su.class.cs244a:12265

We switched it around this assignment. The proxy speaks TCP on the 
incoming side, and STCP on the outgoing side. So, you can use any tool 
to download webpages from it, but you can only get pages from the 
webservers that speaks STCP.

Nishant Patil wrote:
> Hi,
> 
>             I'm having some trouble getting proxyget to talk to proxy (I'm 
> using the reference proxy).  I then changed proxyget to use regular TCP 
> socket calls, and I was able to download webpages.  I was also able to get 
> traffic using telnet and firefox which use TCP.  Is there a reason why I 
> cannot connect to proxy (server-side) by making STCP calls from proxyget 
> (client-side) ?
> 
> 
> 
> Thanks,
> 
> Nishant
> 
> 
> 
> 
> 
.

Path: shelby.stanford.edu!not-for-mail
From: Ben Nham <nham@stanford.edu>
Newsgroups: su.class.cs244a
Subject: use late day on pa4?
Date: Sun, 11 Mar 2007 18:15:47 -0700
Lines: 5
Distribution: su
Message-ID: <et29k9$lc9$1@news.Stanford.EDU>
NNTP-Posting-Host: nham.stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173662153 21897 128.12.94.22 (12 Mar 2007 01:15:53 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
Xref: shelby.stanford.edu su.class.cs244a:12266

Sorry if this was covered somewhere else, but if we still have our late 
day left, can we use it on pa4? I'm just asking because I have a final 
this Thursday and might want to devote some more time studying for that...

Ben
.

Path: shelby.stanford.edu!not-for-mail
From: Greg Nelson <grourk@stanford.edu>
Newsgroups: su.class.cs244a
Subject: Verify Checksum Failure
Date: Sun, 11 Mar 2007 21:30:00 -0700
Lines: 17
Distribution: su
Message-ID: <et2krj$rle$1@news.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.Stanford.EDU 1173673651 28334 127.0.0.1 (12 Mar 2007 04:27:31 GMT)
X-Complaints-To: news@news.stanford.edu
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
Xref: shelby.stanford.edu su.class.cs244a:12267

Hi,

When I use the reference router and proxy with my own STCP and then try 
to telnet into the proxy I hit the following assertion failure:

proxy: stcp_api.c:166: stcp_network_recv: Assertion `len <= 0 || 
_mysock_verify_checksum(_mysock_get_context(sd), dst, len)' failed.

If I comment out that assertion in stcp_api.c then everything works 
fine.  I can get to the application server and the web with telnet and a 
browser using my STCP.

What is it about my transport layer that is causing this assertion to fail?

Thanks,

Greg
.