instructions and still have some troubles, drop an e-mail to
<simgrid-user@lists.gforge.inria.fr>.
-\subsection faq_compiling Compiling SimGrid
+\subsection faq_compiling Compiling SimGrid from an archive
+First of all, you need to download the latest version of SimGrid from
+<a href="http://gforge.inria.fr/frs/?group_id=12">here</a>.
Suppose you have uncompressed SimGrid in some temporary location of
your home directory (say <tt>/home/joe/tmp/simgrid-3.0.1 </tt>). The
simplest way to use SimGrid is to install it in your home
\verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH
\endverbatim
+
+\subsection faq_compiling_cvs Compiling SimGrid from the CVS
+
+The project development takes place in the cvs, where all changes are
+commited when they happen. Then every once in a while, we make sure that the
+code quality meets our standard and release an archive from the code in the
+CVS. We afterward go back to the development in the CVS. So, if you need a
+recently added feature and can afford some little problem with the stability
+of the lastest features, you may want to use the CVS version instead of a
+released one.
+
+For that, you first need to get the "simgrid" module from
+<a href="http://gforge.inria.fr/scm/?group_id=12">here</a>.
+
+You won't find any <tt>configure</tt> and a few other things
+(<tt>Makefile.in</tt>'s, documentation, ...) will be missing as
+well. The reason for that is that all these files have to be
+regenerated using the latest versions of <tt>autoconf</tt>,
+<tt>automake</tt> (1.9) and <tt>doxygen</tt>. To generate the
+<tt>configure</tt> and the <tt>Makefile.in</tt>'s, you just have to
+launch the <tt>bootstrap</tt> command that resides in the top of the
+source tree. Then just follow the instructions of Section
+\ref faq_compiling.
+
+We insist on the fact that you really need the latest versions of
+autoconf and automake. Doing this step on exotic architectures/systems
+(i.e. anything different from a recent linux distribution) may be
+... uncertain. If you want to use the CVS version on another
+architecture/system, you should do the previous steps on a perfectly
+standard box, then do a <tt>make dist</tt> that will build you a
+perfectly portable SimGrid archive.
+
+In summary, the following commands will checkout the CVS, regenerate the
+configure script and friends, configure SimGrid and build an archive you can
+use on another machine afterward.
+
+\verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login
+cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid
+cd simgrid
+./bootstrap
+./configure --enable-maintainer-mode
+make dist \endverbatim
+
\subsection faq_setting Setting up your own code
Do not build your simulator by modifying the SimGrid examples. Go
\section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
You are at the right place... Having a look to these
-<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>
+<a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">slides</a>
+(or to these
+<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">"obsolete" slides</a>)
may give you some insights on what SimGrid can help you to do and what
are its limitations. Then you definitely should read the \ref
MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
- It was really boring to write 25,000 entries in the deployment file, so I wrote
a little script <tt>examples/gras/tokenS/make_deployment.pl</tt>, which you may
- want to adapt to your case.
+ want to adapt to your case. You could also think about hijacking
+ the SURFXML parser (have look at \ref faq_flexml_bypassing).
- The deployment file became quite big, so I had to do what is in the FAQ
entry \ref faq_flexml_limit
the development of FleXML, I can grant you that any patches would be really
welcome and quickly integrated.
+\subsection faq_gras_transport GRAS spits networking error messages
+
+Gras, on real platforms, naturally use regular sockets to communicate. They
+are deeply hiden in the gras abstraction, but when things go wrong, you may
+get some weird error messages. Here are some example, with the probable
+reason:
+
+ - <b>Transport endpoint is not connected</b>: several processes try to open
+ a server socket on the same port number of the same machine. This is
+ naturally bad and each process should pick its own port number for this.\n
+ Maybe, you just have some processes remaining from a previous experiment
+ on your machine.\n
+ Killing them may help, but again if you kill -KILL them, you'll have to
+ wait for a while: they didn't close there sockets properly and the system
+ needs a while to notice that this port is free again.
+
+ - <b>Socket closed by remote side</b>: if the remote process is not
+ supposed to close the socket at this point, it may be dead.
+
+ - <b>Connection reset by peer</b>: I found this on internet about this
+ error. I think it's what's happening here, too:\n
+ <i>This basically means that a network error occurred while the client was
+ receiving data from the server. But what is really happening is that the
+ server actually accepts the connection, processes the request, and sends
+ a reply to the client. However, when the server closes the socket, the
+ client believes that the connection has been terminated abnormally
+ because the socket implementation sends a TCP reset segment telling the
+ client to throw away the data and report an error.\n
+ Sometimes, this problem is caused by not properly closing the
+ input/output streams and the socket connection. Make sure you close the
+ input/output streams and socket connection properly. If everything is
+ closed properly, however, and the problem persists, you can work around
+ it by adding a one-second sleep before closing the streams and the
+ socket. This technique, however, is not reliable and may not work on all
+ systems.</i>\n
+ Since GRAS sockets are closed properly (repeat after me: there is no bug
+ in GRAS), it is either that you are closing your sockets on server side
+ before the client get a chance to read them (use gras_os_sleep() to delay
+ the server), or the server died awfully before the client got the data.
+
+
\subsection faq_deadlock There is a deadlock !!!
Unfortunately, we cannot debug every code written in SimGrid. We
