+I decided to take a moment and sum up what Roy and I have achieved so
+far and what is our road-map for the future. So far, progress has been
+hampered by the fact that Roy had Milu'im, but we still managed to do several
+things. Here is a small report of our current status:
+The Development Workstation:
+* Local Web-server is running.
+* X-Windows is running. ( we will have some problems once we switch to
+the bigger and better screen)
+* Very crappy temporary screen, but I can successfully work on it
+by accessing it through VNC from the nearby workstation which has a better
+* SMB mounting of the home-directory of comnet
+(The Computer Networks Lab server) is working.
+* CVS server is running and operational on the local workstation.
+* Everything I can think of, from KDE to gvim to bash, was customized to match my whims.
+* Sound card is working. (I don't think we'll need it much, but the music
+* The Win2000 partition is not defined, but technically still present on the
+hard-disk. I believe that with some effort we can define it by knowing what
+the start and end sectors are. In any case, we don't need Windows for the time
+being and we can always use a network workstation.
+* SSH/Telnet account is active. (only SSH version 2, though)
+* Login via the NT domain is working.
+* Created a mailing list of firstname.lastname@example.org.
+* Should be archived at http://email@example.com/.
+Archive is not active yet from some reason.
+* I opened a BerliOS project for it under the id of "ip-noise". Those who
+wish to become members of this project:
+1. Register at http://developer.berlios.de/
+2. Send me an E-mail and I'll add them to the project.
+In any case, the project's page is:
+* Remote BerliOS CVS is operational.
+* The BerliOS web-site just contains a link to the web-site at the Technion.
+* We may activate some of the other services BerliOS offers us (Bug Tracking?
+Mailing Lists? Patch Manager? Web Forums? ) later, but they
+are most suitable for projects whose developers are not concentrated in
+one place, which is not exactly the case for us.
+We have written an engine in Perl that can retrieve packets off the kernel
+and then send them away, drop them or delay them to arbitrary delays. The
+arbitrator that is available at the moment is is a simple state-less
+arbitrator, which does not resemble our conception of the final arbitrator
+The design includes three threads, one of which is the arbitrator's. For the
+final design we plan to have two more arbitrator specific threads:
+One to modify the current state of all the Markovian chains, and the second
+to listen for requests of incremental changes from the user, and execute them.
+We have several documents available:
+1. A "Dokh Ifyun" of the project. Not too much of interest here, but
+we had to write it in order to get a workstation:
+2. A not-entirely-complete description of the Syntax that the user will work
+with the packet arbitrator:
+3. A description of the Architecture of the IP-Noise Engine Framework (the perl
+4. A description of the proposed Arbitrator's Architecture:
+5. A description of the protocol that the compiler will use to talk
+All of the documents are text files except for the "Dokh Ifyun" which
+is written in Hebrew MS-Word, but is also available as PostScript. Note, that
+the contents of all the documents are not final and subject to change as we
+progress in the project.
+The web-site is working and functional, but does not look very attractive.
+We have recently started experimenting with a tool called "Web Meta Language"
+that enables to easily generate complex HTML code. With it, we may be able
+to maintain a better site.
+The BerliOS site at the moment just links to this site, not mirrors it, which
+is another problem which I believe can be easily resolved with WML.
+Our plan for now is this:
+1. Write a compiler (in perl) to compile the syntax of the noise definition
+language to commands of the protocol that is understood by the arbitrator.
+We plan to keep the compiler written in Perl up till the end of the
+1. Parsing, Analyzing, etc. is much better done in Perl.
+2. We figure that modifying the behaviour of the noise simulator is not
+a real-time task, so nothing bad will happen if it is written in Perl.
+3. We can always convert it to C later, if such a need arises.
+Writing an Arbitrator in Perl:
+Roy and I decided that we are going to write the first working version of
+the Arbitrator as Perl code. We realize that we cannot expect to process
+heavy loads of packets in real-time this way. However, that way we will be
+able to write the code quickly without having to meddle with C's
+idiosyncrasy, and we would have a good idea of a proper architecture for
+The Arbitrator would be integrated into the existing perl code, to yield
+a fully functional (albeit very slow) noise simulator written in Perl.
+Convert the Arbitrator and Engine to C:
+Naturally, we are not going to keep everything in Perl, so the next logical
+step would be to convert them to C. We would probably stick to ANSI C so
+the code would compile faster. (g++ is quite slow)
+We have to make sure not to rely too much on the standard C library, or else
+the code will not be very ready for the kernel. (see the next section) Thus,
+it is proposed that we will use wrappers for such functions wherever possible,
+and possibly write our own for the kernel.
+Adapt the C code to run in kernel-mode:
+After we have a fully functional noise simulator written in C running in
+user-land, we plan to port the code to be a set of kernel modules. Omer
+Mussa'ev said in a mail message that user-level code that relies on IP-Queue,
+can only handle loads of up to 30 Mbps. Thus, converting the code to run
+in the kernel may be inevitable if we want to have a good performance.
+We're still don't know exactly what mechanisms are available for us in the
+kernel as we didn't work in kernel mode too much. For instance, we may have
+to rip the code of GNU libc in order to extract a portable code that can
+calculate the ln() function for us. This is just a simple example that working
+at the kernel is much more difficult than doing everything in user-land.