X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Examples%2FUDPClientServer%2FMainpage.dox;h=ec62d29af780a25c33295f0e42e6b3e324602416;hb=ac1dca71db955a9f19edc7ad1888bfe5bd126eac;hp=b5c787580f5ee9c7633ad21e3b92597911a5c044;hpb=4e3d3eabb9def43ad4496bff5f7e3bf77ce1719d;p=senf.git

diff --git a/Examples/UDPClientServer/Mainpage.dox b/Examples/UDPClientServer/Mainpage.dox
index b5c7875..ec62d29 100644
--- a/Examples/UDPClientServer/Mainpage.dox
+++ b/Examples/UDPClientServer/Mainpage.dox
@@ -24,22 +24,26 @@
 
     \dontinclude udpServer.cc
 
-    This Application is a command line based client/server application, which sends some strings from
-    client to server, where they are printed on the command line.
+    This Application is a command line based client/server application, which sends some strings
+    from client to server, where they are printed on the command line.
 
     After installing the Library, the udpServer and the udpClient can be found in the
     senf/Example/udpServer directory and compiled with
 
     <pre>
-        # scons -u
-        <Then you can start the client/server with>
+    # scons -u
+    </pre>
 
-        # ./udpServer
-        # ./udpClient
+    Now you can start the application with
+    <pre>
+    # ./udpServer
+    # ./udpClient
     </pre>
 
-    When we take a look to the code, we start with the Server:
-    First we include the necessary headers:
+    \section UDPserverApplication UDP server application
+
+    We take a look to the code starting with the Server: The file starts out including the necessary
+    header files:
 
     \skip // Custom includes
     \until membind
@@ -48,69 +52,66 @@
     integrated Scheduler. The  scheduler library provides a simple yet flexible abstraction of
     the standard asynchronous UNIX mainloop utilizing \c select or \c poll.
 
-    \section UDP_serverApplication UDP server application
-
     First we define a class which is responsible for opening a socket and print out the incoming
     data on stdout. We create a \c ::UDPv4ClientSocketHandle, which is an unconnected and
-    uninitialized UDP (Ipv4) socket.
+    uninitialized UDP (IPv4) socket.
 
     \until serverSock;
 
-    The constructor initialize the Server Object with a given address and port. In our case the
-    server listens static on the loopback device with port 4243.
+    The name \e client socket handle is a bit misleading: The handle is a \e client and not a \e
+    server socket handle since it implements the ordinary (client) socket API and not the connection
+    oriented (e.g. TCP accept) server socket API. Since UDP is not connection oriented, there exists
+    no \c UDPv4ServerSocketHandle.
 
     \until {}
 
-    The public \c run() member is called to run the sniffer. It first adds the socket to the
-    Scheduler. The <tt> \link senf::Scheduler::add add() \endlink </tt> call takes two Arguments,
-    the socket to bind to (which can be a lot of things and must not necessarily be a socket
-    instance) and callback function to call, whenever there is an event on that socket.The callback
-    is specified as a <a href="http://www.boost.org/doc/libs/release/doc/html/function.html">
-    Boost.Function</a> object. A third argument may be specified to restrict the events, on which 
-    the function is called, here we used the EV_READ Argument, because we just want the program to
-    read from the socket. The default argument is set to \c senf::Scheduler::EV_ALL, which allows 
-    all actions on the socket.
+    The constructor initialize the Server Object with a given address and port. In our case the
+    server configuration is static: The server listens on the loopback device on port 4243. We
+    instantiate and configure a senf::scheduler::FdEvent instance to call Server::readFromClient
+    whenever data is available on the handle.
 
     \until }
 
-    Calling the Schedulers <tt> \link senf::Scheduler::process process()\endlink </tt> method will
-    start the event loop. This call does not return (ok, it does return in special cases if
-    \c senf::Scheduler::terminate() is called which does not apply here). The Callback Function is
-    the \c readFromClient() Function, which is declared as private here and will be called whenever
-    an event on the socket is encountered. The scheduler passes the event ID to the function.
+    The public \c run() member is called to run the sniffer. It enables the event callback and
+    enters the scheduler main-loop.
 
     \until event)
 
-    In the function the data from the socket is put into a standard string and dumped out on stdout.
+    This member function is called by the %scheduler whenever new data is available. The scheduler
+    passes in an event-mask of the event(s) triggering the call.
 
     \until };
 
-    In the main function we need to create an Object of our Server with the loopback address and the port.
+    In the function the data from the socket is put into a standard string and dumped out on stdout.
 
     \until return 0;
+    \until }
+
+    In the main function we need to create an Object of our Server with the loopback address and the
+    port.
 
     That's it. We finish of by catching the exception and giving as much %detail as possible if an
-    exception is caught. The \c prettyName function from the \c Utils library is used, to get a nice,
-    printable representation of the dynamic type of the exception instance. It is an interface to
-    the g++ demangler. This is necessary since the name member of the C++ \c type_info instance is
-    a mangled name in g++.
+    exception is caught. The \c prettyName function from the \c Utils library is used, to get a
+    nice, printable representation of the dynamic type of the exception instance. It is an interface
+    to the g++ de-mangler. This is necessary since the name member of the C++ \c type_info instance
+    is a mangled name in g++.
 
-    \section UDP_clientApplication UDP client application
+    \section UDPclientApplication UDP client application
 
     \dontinclude udpClient.cc
 
-    The client application uses the same mechanisms, but implements them in a small main function.
+    The client application uses the same mechanisms but implements them in a small main function.
     It sends numbers as strings to the server.
 
     \skip  argv[])
     \until return 0;
+    \until }
 
-    First a \c ::UDPv4ClientSocketHandle is created. With the function
-    \c writeto(senf::INet4SocketAddress, string) the string s will be written to the specified
-    address and port, which is constructed here from a  static string read from the console with the format \c IP:PORT. In this
-    example Integers from zero to ten are send to the Server socket.
-
-    The exception handling is again the same as with the server application.
+    First a \c senf::::UDPv4ClientSocketHandle is created. With
+    <tt>writeto(senf::INet4SocketAddress, string)</tt> the string \c s will be written to the
+    specified address and port, which is constructed here from a static string read from the command
+    line with the syntax \c IP:PORT. In this example Integers from zero to ten are send to the
+    Server socket.
 */