Back to Operating Systems Home Page

Assig 4 woes

Hello,

The text for assignment 4 is now available of the class web page for your
downloading pleasure (actually LaTeX2HTML is formatting it as I type, so
wait for a few more minutes before hitting the CIM web server). Sorry for
the slight delay, but today was a somewhat hectic day for me. The PS
version is available as well.

I also want to give public answer to a couple of emails I received, from
students concerned that they wouldn't be able to solve the assignment
since the basics of TCP/IP networking are being introduced in class this
week. 

While this is an unfortunate superposition, please realize that you can
begin to design and *implement* a mighty large part of your solution 
regardless of networking issues. As explained in class today, one of the 
beauties of the "BSD sockets" application programmer interface  to TCP/IP 
is that sockets *are* file descriptors as far as *all* the I/O operations
are concerned. You can write(2) to and read(2) from them exactly as if
they were descriptors attached to pipelines of files on the disk.

You get file descriptors for files with open(2), for pipelines with
pipe(2), and for sockets with socket(2): all these system calls return
file descriptors. The special and new things about sockets concern the
only way in which you connect them to other sockets on remote machines,
but not the way in which you read/write data with them, not at all.

Now study the assignemt text. About 3/4 of it have nothing to with 
networking. You don't believe it? Well, follow me for a moment:

1)
You are going to reuse your Enigma encryption code of assig 
2, to begin with (so remove the errors the TA indicated in your sources).
What changes here is that you don't *have* to use multiple processes to do 
the multilevel encoding: you may simplify it doing everything in one process,
but the code for the rotor feeding, shuffling etc will certainly remain 
the same.

2)
The implementation of the protocol message processing, both for the client
side and for the server side does *not* depend on the presence of 
connected sockets on the net. It is just string parsing and processing.
You can design and implement the appropriate parsing code separately on
client and server. And you can test them by making them read/write from/to
files. This is actually the right way to do even if you know how to network
already, since it allows to test and debug the protocol processing code 
without the influence of possible networking errors. So what about a:
        #define DEBUG 1 /* for now */
        #ifdef DEBUG
                in = open("testfile_in", O_RDONLY);
                out = open("testfile_out", O_WRONLY|O_CREAT, 0644);
        #else
                in = networking_code_that_i_have_to_figure_out(blah, blah);
                out = in;
        #endif
And then you put test directives on "tesfile_in" (as if they came from a 
remote host) and see what comes out of your client or server in 
"testfile_out".

So you can write all the basic protocol stuff regardless of networking - 
it'll be just a big "switch" statement with appropriate function calls
for every matched string.

3)
Networking is easy and fun to do, as you'll see by yourself in a coupla
days. Well, debugging it can be frustrating and need attention - one more
reasong to get the rest of the code right and tested quickly. 
In any case, it is nowadays an essential tool for any engineer wishing
to make a career in computers, so I believe  you had better dirt your hands
with it for once.

4)
As always, i and the TA's are available for help. The "message" section on
the web page contains lots of notes and examples about - please do browse it.

Ciao
Franco