[ee122] Fwd: Project 1

[Lisa Fowler]

On 9/11/07, Ofer Sadgat <ofer at berkeley.edu> wrote:
> Yes, but what I am asking is does TCP ensure that data from a call to send
> will arrive at the other side in the same order or does it also ensure that
> multiple calls to send will arrive in the order that send is called? For
> example, what if the second of the two packets sent takes a faster path? Is
> the time encoded into the packet? Because if it isn't, then whats to say
> which came first? You could have a field which orders them, but then that
> would have a maximum size, what would happen when that is exceeded?
>
> More concretely:
>         Send(dataA)
>         Send(dataB)
>
> Other side:
>         Receive() returns dataB
>         Receive() returns dataA
>
> Is this possible?

TCP ensures that the data will be in order *within* each send/recv
pair.  It is POSSIBLE that separate messages (send()'s) will arrive
NOT in order, such as you described, due to strange path differences.
It's rare in this day and age, but not impossible.  This is where your
application level protocol should be doing fact checking to ensure
that the message is as its expected (e.g. checksums if it were mission
critical that you were going to send giant consecutive messages  and
that they MUST arrive in order).  I'm doing some checking now, but
it's my understanding that the way that send() works is that it has a
buffer under the covers and consecutive send()'s populate that buffer
until the kernel is sufficiently pleased before it actually sends off
the data via TCP -- thereby taking advantage of the TCP window sizes,
and TCP's in-order promises.

I'll get back to you on this, but for now, don't worry about it so
much.  For the purposes of the first part of this project, this
shouldn't be a problem, but I'll get back to you on the buffering.

-Lisa

> Ofer
>
> -----Original Message-----
> From: Daniel Killebrew [mailto:dank at eecs.berkeley.edu]
> Sent: Tuesday, September 11, 2007 9:44 PM
> To: ofer at berkeley.edu; ee122 at ICSI.Berkeley.EDU
> Cc: Lisa Fowler
> Subject: Re: Fwd: [ee122] Project 1
>
>
> > ---------- Forwarded message ----------
> > From: Ofer Sadgat <ofer at berkeley.edu>
> > Date: Sep 11, 2007 10:15 AM
> > Subject: RE: [ee122] Project 1
> > To: Lisa Fowler <fowler at eecs.berkeley.edu>
> >
> >
> > Yes, I understood what Beej's guide said. The problem comes from the
> server
> > side. When it is receiving packets, how does it know which packets come
> > before which? It isn't necessarily true that they will arrive in order.
> >
> >
> Assuming I understand your question correctly, TCP will give you the
> bytes of the message in order. You don't see how your data is split into
> packets when using TCP. TCP knows the order of the packets because there
> is a sequence number in the TCP header that indicates packet ordering.
>
> > Also, why is it that the Client's path allows "-" but the server's
> doesn't?
> >
> That's a typo, both client and server paths should allow "-' (hyphens).
> > Lastly, for our server should the path "/Hello/InDex.Html" ==
> > "/hello/index.html"?
> >
> Don't do any changing of the path's case. File system case sensitivity
> or insensitivity defaults to different things on different OSs. When
> grading, we won't expect you to return "Index.html" if we ask for
> "index.html".
>
> Daniel
> > Thanks,
> > Ofer
> >
> >
>
>