Q: How powerful should our
system be? Does it have to be able to split all users into different channels
or groups as it is implemented in IRC, or it is ok to have them all in
one discussion? 
A: The idea is to design
a real-life, useful system. Part of the assignment is that you determine
(and document) what "useful" means - if, for example, you think
having discussion groups is useful you should state your reasoning.
Your design should be as "good" as possible, however, your implementation does not have to reflect your entire design. If you are not going to implement your entire design - you need to send us mail telling us what you plan on implementing, and we will be able to say "Yes, that sounds great" -or- "I think you need to think about implementing more".
Q: Is it ok to use telnet
as a client program, and forget about the interface, so that incoming string
may appear in the middle of text currently printed, as we did it for Project
1? A: Yes, as long as you document
(acknowledge) that you understand that using telnet is not optimal and
that a better client could be developed. The idea is that you need to make
sure that we know that you know the limitations of your implementation.
Q: Do I need to describe
the protocol between the client and the server? If so how detailed? A: Yes, it does need to
be described; in sufficient detail so that somebody else could implement
a client that would interface with your server (or a server that would
interface with your client) without any problems. The level of detail in
the project #2 handout is about right.
Q: Do we really have to
worry about [network byte order] for project 3? |
TA SLAUGHTERS UNDERGRAD : Bloodbath during office hours . Insane rage rumored to be sparked by a single email message - Congress calls for mandatory five-day 'cooling off period' for Internet access. |
A: If done right (by providing
a layer that takes care of network byte order), the amount of coding you
need to do is trival.
-also-
Many/most TCP based applications (and some UDP) encode everything in ASCII so there is no network byte order issue at the application level. Consider FTP - although there is need to send port numbers and other integer values between processes, everything is done via strings. To tell an FTP server what port I'm listening on
"PORT ip1,ip2,ip3,ip4,p1,p2"
and the server must parse the command line and convert ip1,ip1,... to it's
own integer representation (using atoi or scanf or something like that).
Everything is ASCII and no network byte order code is needed for such transactions.
Q:
Can I have an extension?
A: No - everyone must submit by Nov 1st.