[ee122] Scaling down Proj1

[Lisa Fowler]

I'm sorry it wasn't clear before, but I do mean that the inclusion of
Project 1 code in Project 2 is so that you have something that can
trivially request and then transfer a single file from one host to the
other.

I *really* don't care about anything else.  As long as you can still
have host A request a file from host B (via a plain vanilla GET
request for a file in the working directory), and have host B send the
requested file to host A, that's great.  That's all I'm looking for.
One host A, one host B, and the ability to request and transfer a
particular file.

Your priority is showing that your protocol abstracts away all the
underlying work and helps create the illusion of a reliable in-order
channel, no matter the loss, delay, corruption, etc. seen below.

The app's view of (i.e. interface to) your transport protocol should
be nearly identical to how it was before when using TCP.

-Lisa

On Nov 18, 2007 8:09 PM, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> Hello,
>
> I think it would be helpful in knowing how much we can simplify our
> previous project in order to facilitate the emphasis on the
> inter-protocol.
>
> What I would like to do: (Outline)
>
> - Throw out data structure for keeping multiple connections.
> - Use 'listener' as a valid socket for recieving initial data (ala FTP).
> - Static number of sockets total.
> - Sequential handling of interactions (no sending_data until all
> data_recieve'd).
> - No persistent connections.
>
> The spec mentions some parts that can be tossed, but I'd like to know
> if there's a limit on how far I can simplify the interactions and
> still create an acceptable atomosphere for our protocol to work under.
> Basically I want to model the interactions as we normally do in the
> homework.
>
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>