*** empty log message ***

11 files changed, 209 insertions, 54 deletions

diff --git a/docs/tutorials/013/work.cpp b/docs/tutorials/013/work.cpp
index 4fc16defb48..f4dc932d003 100644
--- a/docs/tutorials/013/work.cpp
+++ b/docs/tutorials/013/work.cpp
@@ -115,6 +115,7 @@ int Work::fini (void)
 {
     while (state_.value () < 3)
     {
+        ACE_DEBUG ((LM_DEBUG, "(%P|%t) 0x%x Work::fini() state %d\n", (void *) this,state_.value()));
         if (this->process () == -1)
         {
             ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "process"), -1);
diff --git a/docs/tutorials/014/combine.shar b/docs/tutorials/014/combine.shar
index c4af4862e35..dd173fb1a79 100644
--- a/docs/tutorials/014/combine.shar
+++ b/docs/tutorials/014/combine.shar
@@ -3,7 +3,7 @@
 # To extract the files from this archive, save it to some FILE, remove
 # everything before the `!/bin/sh' line above, then type `sh FILE'.
 #
-# Made on 1998-10-20 19:37 EDT by <jcej@chiroptera.tragus.org>.
+# Made on 1999-02-10 22:17 EST by <jcej@chiroptera.tragus.org>.
 # Source directory was `/var/home/jcej/projects/ACE_wrappers/docs/tutorials/014'.
 #
 # Existing files will *not* be overwritten unless `-c' is specified.
@@ -13,7 +13,7 @@
 # ------ ---------- ------------------------------------------
 #    414 -rw-r--r-- hdr
 #     44 -rw-r--r-- bodies
-#   1023 -rw-r--r-- page01.pre
+#   2609 -rw-r--r-- page01.pre
 #    231 -rw-r--r-- page02.pre
 #    651 -rw-r--r-- page03.pre
 #    439 -rw-r--r-- page04.pre
@@ -64,7 +64,7 @@ else
 fi
 rm -f 1231235999 $$.touch
 #
-if mkdir _sh14739; then
+if mkdir _sh28285; then
   $echo 'x -' 'creating lock directory'
 else
   $echo 'failed to create lock directory'
@@ -160,21 +160,55 @@ this way mirrors closely the way System V STREAMS work.  But you don't have to u
 bidirectionally.  In this tutorial, we only use one direction of the Stream.  Down.
 X
 <p>This tutorial is contributed by Bob McWhirter (bob@netwrench.com)
+X
+<P>
+Kirthika's abstract:
+<ul>
+In this tutorial, an ACE_Stream has been implemented which has modules
+flowing through it.(literally ;).
+The chain of modules in the Stream include the Head and Tail Modules. A
+Module is simply a reader-writer pair of ACE_Tasks with the writing side
+acting as downstream and the reading side as upstream. Here we are only
+concerned with going downstream so we install a Task into the write-side
+of the module.
+<P>
+The task implementation makes use of flags to decide on whether to close
+the main task or the service thread. The svc () method follows the
+golden rule of copying message blocks before putting them on the queue
+until it comes across a hang-up message. It then puts the message back
+on the queue for its peers to obtain it and exits.
+<P>
+Any message put onto the Tail module is an error. So a customised
+derivative of the Task class is created, which collects all the garbage
+messages put onto the Tail. This End_Task is put into the Stream at the
+start itself such that no modules whould ever follow it!
+<P>
+Then the other modules are pushed from the Tail-end into the Stream.
+This is because we are interested in writing and not reading.
+(Picture this to be a FIFO (queue) with head and tail nodes such
+that the nodes are removed from the front and put into the queue from
+the back) 
+<P>
+Each module then opens up the task which spawns threads and begins to
+shove messgaes down the stream. Once we have got all the messages into
+the stream, our job is completed and we shut down the Stream. 
 <P>
+A simple way to wade down the stream...;)
+</ul>
 SHAR_EOF
-  $shar_touch -am 1012190598 'page01.pre' &&
+  $shar_touch -am 0210221599 'page01.pre' &&
   chmod 0644 'page01.pre' ||
   $echo 'restore of' 'page01.pre' 'failed'
   if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
   && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
     md5sum -c << SHAR_EOF >/dev/null 2>&1 \
     || $echo 'page01.pre:' 'MD5 check failed'
-5b2cf5b57c135827e8465cdcfc83357f  page01.pre
+23c8c084825939056b1c9226d4ab54c1  page01.pre
 SHAR_EOF
   else
     shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page01.pre'`"
-    test 1023 -eq "$shar_count" ||
-    $echo 'page01.pre:' 'original size' '1023,' 'current size' "$shar_count!"
+    test 2609 -eq "$shar_count" ||
+    $echo 'page01.pre:' 'original size' '2609,' 'current size' "$shar_count!"
   fi
 fi
 # ============= page02.pre ==============
@@ -319,5 +353,5 @@ SHAR_EOF
     $echo 'page05.pre:' 'original size' '1079,' 'current size' "$shar_count!"
   fi
 fi
-rm -fr _sh14739
+rm -fr _sh28285
 exit 0
diff --git a/docs/tutorials/014/page01.html b/docs/tutorials/014/page01.html
index d74e678e8cc..1be24af0723 100644
--- a/docs/tutorials/014/page01.html
+++ b/docs/tutorials/014/page01.html
@@ -33,6 +33,40 @@ this way mirrors closely the way System V STREAMS work.  But you don't have to u
 bidirectionally.  In this tutorial, we only use one direction of the Stream.  Down.
 
 <p>This tutorial is contributed by Bob McWhirter (bob@netwrench.com)
+
+<P>
+Kirthika's abstract:
+<ul>
+In this tutorial, an ACE_Stream has been implemented which has modules
+flowing through it.(literally ;).
+The chain of modules in the Stream include the Head and Tail Modules. A
+Module is simply a reader-writer pair of ACE_Tasks with the writing side
+acting as downstream and the reading side as upstream. Here we are only
+concerned with going downstream so we install a Task into the write-side
+of the module.
+<P>
+The task implementation makes use of flags to decide on whether to close
+the main task or the service thread. The svc () method follows the
+golden rule of copying message blocks before putting them on the queue
+until it comes across a hang-up message. It then puts the message back
+on the queue for its peers to obtain it and exits.
+<P>
+Any message put onto the Tail module is an error. So a customised
+derivative of the Task class is created, which collects all the garbage
+messages put onto the Tail. This End_Task is put into the Stream at the
+start itself such that no modules whould ever follow it!
+<P>
+Then the other modules are pushed from the Tail-end into the Stream.
+This is because we are interested in writing and not reading.
+(Picture this to be a FIFO (queue) with head and tail nodes such
+that the nodes are removed from the front and put into the queue from
+the back) 
+<P>
+Each module then opens up the task which spawns threads and begins to
+shove messgaes down the stream. Once we have got all the messages into
+the stream, our job is completed and we shut down the Stream. 
 <P>
+A simple way to wade down the stream...;)
+</ul>
 <P><HR WIDTH="100%">
 <CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page02.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/014/page05.html b/docs/tutorials/014/page05.html
index a5d2160b2f8..d54bab00c84 100644
--- a/docs/tutorials/014/page05.html
+++ b/docs/tutorials/014/page05.html
@@ -63,8 +63,6 @@ typedef ACE_Stream&lt;ACE_MT_SYNCH> Stream;
 
 int main(int argc, char *argv[])
 {
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
-
   int numberOfMessages = argc > 1 ? <font color=#008888>ACE_OS::atoi</font>(argv[1]) : 3;
   <font color=red>// unless otherwise specified, just send three messages</font>
   <font color=red>// down the stream.</font>
@@ -72,8 +70,6 @@ int main(int argc, char *argv[])
   Stream theStream;
   <font color=red>// the ACE_Stream itself.</font>
 
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
-
   <font color=red>// Now, we instantiate 4 different Tasks.  These do not</font>
   <font color=red>// need to be all the same class, but they do need to</font>
   <font color=red>// all derrive from the same flavor of ACE_Task.</font>
@@ -115,14 +111,12 @@ int main(int argc, char *argv[])
   <font color=red>// so we'll only actually install a Task into the write</font>
   <font color=red>// side of the module, effectively downstream.</font>
 
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
   moduleOne = new Module("<font color=green>Module No. 1</font>", taskOne);
   moduleTwo = new Module("<font color=green>Module No. 2</font>", taskTwo);
   moduleThree = new Module("<font color=green>Module No. 3</font>", taskThree);
   moduleFour = new Module("<font color=green>Module No. 4</font>", taskFour);
   moduleEnd = new Module("<font color=green>Module End</font>", taskEnd);
 
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
   <font color=red>// Now we push the Modules onto the Stream.</font>
   <font color=red>// Pushing adds the module to the head, or </font>
   <font color=red>// otherwise prepends it to whatever modules</font>
@@ -135,7 +129,6 @@ int main(int argc, char *argv[])
            ACE_ERROR_RETURN ((LM_ERROR, "<font color=green>%p\n</font>", "<font color=green>push</font>"), -1);
   } 
 
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
   if (theStream.push(moduleFour) == -1) {
         ACE_ERROR_RETURN ((LM_ERROR, "<font color=green>%p\n</font>", "<font color=green>push</font>"), -1);
   }
@@ -159,7 +152,6 @@ int main(int argc, char *argv[])
         ACE_ERROR_RETURN ((LM_ERROR, "<font color=green>%p\n</font>", "<font color=green>push</font>"), -1);
   }
 
-  cerr &lt;&lt; __LINE__ &lt;&lt; endl;
   <font color=red>// Now that the Modules are open, the Tasks threads should</font>
   <font color=red>// be launching and entering their svc() loop, so we send</font>
   <font color=red>// some messages down the Stream.</font>
diff --git a/docs/tutorials/014/stream.cpp b/docs/tutorials/014/stream.cpp
index f135d6bb3c1..39c5eaed296 100644
--- a/docs/tutorials/014/stream.cpp
+++ b/docs/tutorials/014/stream.cpp
@@ -26,8 +26,6 @@ typedef ACE_Stream<ACE_MT_SYNCH> Stream;
 
 int main(int argc, char *argv[])
 {
-  cerr << __LINE__ << endl;
-
   int numberOfMessages = argc > 1 ? ACE_OS::atoi(argv[1]) : 3;
   // unless otherwise specified, just send three messages
   // down the stream.
@@ -35,8 +33,6 @@ int main(int argc, char *argv[])
   Stream theStream;
   // the ACE_Stream itself.
 
-  cerr << __LINE__ << endl;
-
   // Now, we instantiate 4 different Tasks.  These do not
   // need to be all the same class, but they do need to
   // all derrive from the same flavor of ACE_Task.
@@ -78,14 +74,12 @@ int main(int argc, char *argv[])
   // so we'll only actually install a Task into the write
   // side of the module, effectively downstream.
 
-  cerr << __LINE__ << endl;
   moduleOne = new Module("Module No. 1", taskOne);
   moduleTwo = new Module("Module No. 2", taskTwo);
   moduleThree = new Module("Module No. 3", taskThree);
   moduleFour = new Module("Module No. 4", taskFour);
   moduleEnd = new Module("Module End", taskEnd);
 
-  cerr << __LINE__ << endl;
   // Now we push the Modules onto the Stream.
   // Pushing adds the module to the head, or 
   // otherwise prepends it to whatever modules
@@ -98,7 +92,6 @@ int main(int argc, char *argv[])
            ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "push"), -1);
   } 
 
-  cerr << __LINE__ << endl;
   if (theStream.push(moduleFour) == -1) {
         ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "push"), -1);
   }
@@ -122,7 +115,6 @@ int main(int argc, char *argv[])
         ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "push"), -1);
   }
 
-  cerr << __LINE__ << endl;
   // Now that the Modules are open, the Tasks threads should
   // be launching and entering their svc() loop, so we send
   // some messages down the Stream.
diff --git a/docs/tutorials/015/Protocol_Stream.cpp b/docs/tutorials/015/Protocol_Stream.cpp
index 222ada3a3f8..c82ab12335c 100644
--- a/docs/tutorials/015/Protocol_Stream.cpp
+++ b/docs/tutorials/015/Protocol_Stream.cpp
@@ -33,7 +33,7 @@ Protocol_Stream::~Protocol_Stream (void)
 }
 
 /* Even opening the stream is rather simple.  The important thing to
-   rememer is that the modules you push onto the stream first will be
+   remember is that the modules you push onto the stream first will be
    at the tail (eg -- most downstream) end of things when you're
    done.
  */
@@ -71,7 +71,7 @@ Protocol_Stream::open (ACE_SOCK_Stream &peer,
   // will be sent through here last.  Server applications will
   // typically use this task to do the actual processing of data.
   // Note the use of Thru_Task.  Since a module must always have a
-  // pair of tasks we use this on the writter side as a no-op.
+  // pair of tasks we use this on the writer side as a no-op.
   if (reader)
     {
       if (stream ().push (new Module ("Reader",
diff --git a/docs/tutorials/015/Protocol_Task.h b/docs/tutorials/015/Protocol_Task.h
index bb690828318..993cebb2e89 100644
--- a/docs/tutorials/015/Protocol_Task.h
+++ b/docs/tutorials/015/Protocol_Task.h
@@ -53,7 +53,7 @@ protected:
     return this->thr_count () != 0;
   }
 
-  // Tasks on the writter (downstream) side of the stream are called
+  // Tasks on the writer (downstream) side of the stream are called
   // upon to send() data that will ultimately go to the peer.
   virtual int send (ACE_Message_Block *message,
                     ACE_Time_Value *timeout);
diff --git a/docs/tutorials/015/combine.shar b/docs/tutorials/015/combine.shar
index 522da61711a..b8fe561dd48 100644
--- a/docs/tutorials/015/combine.shar
+++ b/docs/tutorials/015/combine.shar
@@ -3,8 +3,8 @@
 # To extract the files from this archive, save it to some FILE, remove
 # everything before the `!/bin/sh' line above, then type `sh FILE'.
 #
-# Made on 1999-02-01 13:06 EST by <jcej@beta.mobsec.com>.
-# Source directory was `/projects/home/jcej/projects/ACE_wrappers/docs/tutorials/015'.
+# Made on 1999-02-10 22:34 EST by <jcej@chiroptera.tragus.org>.
+# Source directory was `/var/home/jcej/projects/ACE_wrappers/docs/tutorials/015'.
 #
 # Existing files will *not* be overwritten unless `-c' is specified.
 #
@@ -13,7 +13,7 @@
 # ------ ---------- ------------------------------------------
 #    414 -rw-rw-r-- hdr
 #    419 -rw-rw-r-- bodies
-#   1505 -rw-rw-r-- page01.pre
+#   4303 -rw-rw-r-- page01.pre
 #    194 -rw-rw-r-- page02.pre
 #    318 -rw-rw-r-- page03.pre
 #    178 -rw-rw-r-- page04.pre
@@ -24,7 +24,7 @@
 #    640 -rw-rw-r-- page09.pre
 #    978 -rw-rw-r-- page10.pre
 #    334 -rw-rw-r-- page11.pre
-#    334 -rw-rw-r-- page12.pre
+#     49 -rw-rw-r-- page12.pre
 #    326 -rw-rw-r-- page13.pre
 #    540 -rw-rw-r-- page14.pre
 #    770 -rw-rw-r-- page15.pre
@@ -83,7 +83,7 @@ else
 fi
 rm -f 1231235999 $$.touch
 #
-if mkdir _sh22831; then
+if mkdir _sh29164; then
   $echo 'x -' 'creating lock directory'
 else
   $echo 'failed to create lock directory'
@@ -218,23 +218,78 @@ What it amounts to is using the ACE_Select_Reactor for all platforms.
 Win32 defaults to ACE_WFMO_Reactor and that seems to be causing some
 or all of the problems.
 <P>
+Kirthika's abstract:
+<UL>
+The Protocol Stream model consists of a stream layer which pushes the
+data towards the underlying SOCK_Stream thru the stages of encryption
+and compression. This data is received at the other end of the
+SOCK_Stream and sent up to its Protocol_Stream layer via the stages of
+decompression and decryption and an optional Reader task. This is very
+similar to the model of the TCP/IP stack (specifically the datalink to
+physical layer portion).
+<P>
+ACE_Message_Blocks are used to communicate between the client and the
+server across the Protocol Stream, which abstracts the protocol
+conformance details. The underlying SOCK_Stream is used to set up the
+connection using the ACE_SOCK_Connector class. Once the connector
+completes its job, the SOCK_Stream pointer is passed on to the
+Protocol Stream which now takes over. The Client has put() and get()
+methods to send and receive data from the server. 
+<P>
+The server is implemented using the ACE_Acceptor to listen at the port
+for connections and a reactor for delegating events to the appropriate
+event handler. The handle_input () method of the handler simply allows
+the stream to receive the data and hand it over to the Handler_Task (a
+derivative of the ACE_Task) which will then process it.
+<P>
+The implementation of this Protocol Stream model is done using the
+ACE_Module class. The module for Xmit/Recv is shoved in first
+into the stream, followed by the compression and encryption modules. The
+optional Reader if defined is bundled with a dummy task
+(ACE_Thru_Task class) into a module. The get() and put() methods do
+the job of reading and writing to the Stream. Each module is made up
+of a pair of Protocol Tasks. A Protocol Task is a derivative of the
+ACE_Task and whose recv() and send() methods need to be filled to
+perform the appropriate task.
+<P>
+The Xmit object derives from the Protocol task and has a send() method
+which does the task of transmitting data to the underlying
+SOCK_Stream. Keeping the fragmentation and reassembly issues in mind,
+block-size is also sent across with the block of data.
+The Recv object uses a dummy Message Block to provoke the Protocol
+Task object to call the recv() on it. This is done by being
+foresighted about the use of mutliple threads instead of a single
+thread.
+<P>
+The compression/decompression is bundled in a single Protocol Task
+object with the send () method doing the compression and the recv()
+doing the decompression. Similarly, the encrption/decryption is done
+using a single Protocol Task object.
+<P>
+This tutorial provides a glimpse on how to design and implement a
+protocol in layers and also revises a lot of what has been learnt until
+now from the previous tutorials.
+(for instance, Message_Block, Task, Acceptor, Connector, Event_Handler
+etc.)
+</UL>
+<P>
 <font size=-1>* Ok, I didn't really implement encryption and
 X        compression objects.  I'll leave that as a thought
 X        exercise!</font>
 SHAR_EOF
-  $shar_touch -am 0201130299 'page01.pre' &&
+  $shar_touch -am 0210223099 'page01.pre' &&
   chmod 0664 'page01.pre' ||
   $echo 'restore of' 'page01.pre' 'failed'
   if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
   && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
     md5sum -c << SHAR_EOF >/dev/null 2>&1 \
     || $echo 'page01.pre:' 'MD5 check failed'
-6fb7af94b2876cbac76a358ffc05c226  page01.pre
+77d3deec35fab659429a2eef4ab5b679  page01.pre
 SHAR_EOF
   else
     shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page01.pre'`"
-    test 1505 -eq "$shar_count" ||
-    $echo 'page01.pre:' 'original size' '1505,' 'current size' "$shar_count!"
+    test 4303 -eq "$shar_count" ||
+    $echo 'page01.pre:' 'original size' '4303,' 'current size' "$shar_count!"
   fi
 fi
 # ============= page02.pre ==============
@@ -550,26 +605,22 @@ if test -f 'page12.pre' && test "$first_param" != -c; then
 else
   $echo 'x -' extracting 'page12.pre' '(text)'
   sed 's/^X//' << 'SHAR_EOF' > 'page12.pre' &&
-And now the implementation of the Protocol_Stream.  There are more
-lines of code here than we've seen so far but it still isn't
-complicated.  The basic idea is to construct the ACE_Stream with our
-set of protocol objects that will manipulate the data.  Our primary
-concern in this file is to get everything in the correct order!
+A quick look at the Protocol_Task header...
 <HR>
 SHAR_EOF
-  $shar_touch -am 1019173798 'page12.pre' &&
+  $shar_touch -am 0210223499 'page12.pre' &&
   chmod 0664 'page12.pre' ||
   $echo 'restore of' 'page12.pre' 'failed'
   if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
   && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
     md5sum -c << SHAR_EOF >/dev/null 2>&1 \
     || $echo 'page12.pre:' 'MD5 check failed'
-b0e968102fb417b12710e99465f4e387  page12.pre
+5258df32a7fddcecfe902aec8440f98f  page12.pre
 SHAR_EOF
   else
     shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page12.pre'`"
-    test 334 -eq "$shar_count" ||
-    $echo 'page12.pre:' 'original size' '334,' 'current size' "$shar_count!"
+    test 49 -eq "$shar_count" ||
+    $echo 'page12.pre:' 'original size' '49,' 'current size' "$shar_count!"
   fi
 fi
 # ============= page13.pre ==============
@@ -1007,5 +1058,5 @@ SHAR_EOF
     $echo 'page09.pst:' 'original size' '617,' 'current size' "$shar_count!"
   fi
 fi
-rm -fr _sh22831
+rm -fr _sh29164
 exit 0
diff --git a/docs/tutorials/015/page01.html b/docs/tutorials/015/page01.html
index b79c34335df..40c62b39718 100644
--- a/docs/tutorials/015/page01.html
+++ b/docs/tutorials/015/page01.html
@@ -41,6 +41,61 @@ What it amounts to is using the ACE_Select_Reactor for all platforms.
 Win32 defaults to ACE_WFMO_Reactor and that seems to be causing some
 or all of the problems.
 <P>
+Kirthika's abstract:
+<UL>
+The Protocol Stream model consists of a stream layer which pushes the
+data towards the underlying SOCK_Stream thru the stages of encryption
+and compression. This data is received at the other end of the
+SOCK_Stream and sent up to its Protocol_Stream layer via the stages of
+decompression and decryption and an optional Reader task. This is very
+similar to the model of the TCP/IP stack (specifically the datalink to
+physical layer portion).
+<P>
+ACE_Message_Blocks are used to communicate between the client and the
+server across the Protocol Stream, which abstracts the protocol
+conformance details. The underlying SOCK_Stream is used to set up the
+connection using the ACE_SOCK_Connector class. Once the connector
+completes its job, the SOCK_Stream pointer is passed on to the
+Protocol Stream which now takes over. The Client has put() and get()
+methods to send and receive data from the server. 
+<P>
+The server is implemented using the ACE_Acceptor to listen at the port
+for connections and a reactor for delegating events to the appropriate
+event handler. The handle_input () method of the handler simply allows
+the stream to receive the data and hand it over to the Handler_Task (a
+derivative of the ACE_Task) which will then process it.
+<P>
+The implementation of this Protocol Stream model is done using the
+ACE_Module class. The module for Xmit/Recv is shoved in first
+into the stream, followed by the compression and encryption modules. The
+optional Reader if defined is bundled with a dummy task
+(ACE_Thru_Task class) into a module. The get() and put() methods do
+the job of reading and writing to the Stream. Each module is made up
+of a pair of Protocol Tasks. A Protocol Task is a derivative of the
+ACE_Task and whose recv() and send() methods need to be filled to
+perform the appropriate task.
+<P>
+The Xmit object derives from the Protocol task and has a send() method
+which does the task of transmitting data to the underlying
+SOCK_Stream. Keeping the fragmentation and reassembly issues in mind,
+block-size is also sent across with the block of data.
+The Recv object uses a dummy Message Block to provoke the Protocol
+Task object to call the recv() on it. This is done by being
+foresighted about the use of mutliple threads instead of a single
+thread.
+<P>
+The compression/decompression is bundled in a single Protocol Task
+object with the send () method doing the compression and the recv()
+doing the decompression. Similarly, the encrption/decryption is done
+using a single Protocol Task object.
+<P>
+This tutorial provides a glimpse on how to design and implement a
+protocol in layers and also revises a lot of what has been learnt until
+now from the previous tutorials.
+(for instance, Message_Block, Task, Acceptor, Connector, Event_Handler
+etc.)
+</UL>
+<P>
 <font size=-1>* Ok, I didn't really implement encryption and
         compression objects.  I'll leave that as a thought
         exercise!</font>
diff --git a/docs/tutorials/015/page11.html b/docs/tutorials/015/page11.html
index 3a636df9fdb..f3225648a94 100644
--- a/docs/tutorials/015/page11.html
+++ b/docs/tutorials/015/page11.html
@@ -54,7 +54,7 @@ typedef ACE_Thru_Task&lt;ACE_MT_SYNCH> Thru_Task;
 }
 
 <font color=red>/* Even opening the stream is rather simple.  The important thing to
-   rememer is that the modules you push onto the stream first will be
+   remember is that the modules you push onto the stream first will be
    at the tail (eg -- most downstream) end of things when you're
    done.
  */</font>
@@ -92,7 +92,7 @@ int
   <font color=red>// will be sent through here last.  Server applications will</font>
   <font color=red>// typically use this task to do the actual processing of data.</font>
   <font color=red>// Note the use of Thru_Task.  Since a module must always have a</font>
-  <font color=red>// pair of tasks we use this on the writter side as a no-op.</font>
+  <font color=red>// pair of tasks we use this on the writer side as a no-op.</font>
   if (reader)
     {
       if (stream ().push (new Module ("<font color=green>Reader</font>",
diff --git a/docs/tutorials/015/page12.html b/docs/tutorials/015/page12.html
index 99d3959582d..8dae49b5a18 100644
--- a/docs/tutorials/015/page12.html
+++ b/docs/tutorials/015/page12.html
@@ -12,11 +12,7 @@
 
 <P>
 <HR WIDTH="100%">
-And now the implementation of the Protocol_Stream.  There are more
-lines of code here than we've seen so far but it still isn't
-complicated.  The basic idea is to construct the ACE_Stream with our
-set of protocol objects that will manipulate the data.  Our primary
-concern in this file is to get everything in the correct order!
+A quick look at the Protocol_Task header...
 <HR>
 <PRE>
 <font color=red>// $Id$</font>
@@ -74,7 +70,7 @@ protected:
     return this->thr_count () != 0;
   }
 
-  <font color=red>// Tasks on the writter (downstream) side of the stream are called</font>
+  <font color=red>// Tasks on the writer (downstream) side of the stream are called</font>
   <font color=red>// upon to send() data that will ultimately go to the peer.</font>
   virtual int send (ACE_Message_Block *message,
                     ACE_Time_Value *timeout);