summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--ChangeLog-98b15
-rw-r--r--docs/tutorials/015/Compressor.cpp38
-rw-r--r--docs/tutorials/015/Compressor.h23
-rw-r--r--docs/tutorials/015/Crypt.cpp18
-rw-r--r--docs/tutorials/015/Crypt.h13
-rw-r--r--docs/tutorials/015/combine.shar333
-rw-r--r--docs/tutorials/015/page04.html1
-rw-r--r--docs/tutorials/015/page09.html2
-rw-r--r--docs/tutorials/015/page14.html22
-rw-r--r--docs/tutorials/015/page15.html25
-rw-r--r--docs/tutorials/015/page16.html16
-rw-r--r--docs/tutorials/015/page17.html8
-rw-r--r--docs/tutorials/015/page18.html68
-rw-r--r--docs/tutorials/015/page19.html119
-rw-r--r--docs/tutorials/015/page20.html61
-rw-r--r--docs/tutorials/015/page21.html99
-rw-r--r--docs/tutorials/015/page22.html82
-rw-r--r--docs/tutorials/index.html13
18 files changed, 850 insertions, 106 deletions
diff --git a/ChangeLog-98b b/ChangeLog-98b
index 8f50aa021bd..2e531e63b3f 100644
--- a/ChangeLog-98b
+++ b/ChangeLog-98b
@@ -1,3 +1,18 @@
+Mon Oct 19 20:44:33 1998 James CE Johnson <jcej@chiroptera.tragus.org>
+
+ * docs/tutorials/015:
+ Once again I've modified just about every file. Finally though
+ Tutorial 015: Protocol Stream is done!
+
+ * docs/tutorials/combine
+ Get rid of that silly "links" file and add "bodies". The new file
+ is an ordered list of files to use when assembling the HTML
+ pages. This makes it easier to stuff source code into the pages.
+
+ * docs/tutorials/index.html
+ I could have sworn that I linked in 014 many moons ago.
+ Appologies to Bob McWhirter for leaving this out for so long!
+
Mon Oct 19 17:00:52 EDT 1998 James CE Johnson <jcej@chiroptera.tragus.org>
* docs/tutorials/015:
diff --git a/docs/tutorials/015/Compressor.cpp b/docs/tutorials/015/Compressor.cpp
index 06efab06947..c2f796bd68e 100644
--- a/docs/tutorials/015/Compressor.cpp
+++ b/docs/tutorials/015/Compressor.cpp
@@ -4,22 +4,38 @@
#include "Compressor.h"
#include "ace/SOCK_Stream.h"
+/* Construct our baseclass with the proper thread count. I really
+ should remove this option...
+ */
Compressor::Compressor( int _thr_count )
: inherited(_thr_count)
{
+ ;
}
Compressor::~Compressor(void)
{
+ ;
}
+/* This is where you insert your compression code. Most compressors
+ want to work on a block of data instead of a byte-stream.
+ Fortunately the message block has a block that can be compressed.
+ Take a look at libz for a quick way to add compression to your
+ apps
+ */
int Compressor::send(ACE_Message_Block *message, ACE_Time_Value *timeout)
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Compressor::send() compressing (%s)\n", message->rd_ptr() ));
+ // Create a block to hold the compressed data. I belive libz
+ // recommends a buffer about 10-20% larger than the source.
+ // Other libraries/algorithms may have their own quirks.
ACE_Message_Block * compressed = new ACE_Message_Block( message->size() );
- // Perform a bogus compression algorithm
+ // Perform a bogus compression algorithm. 'CD' just tells me
+ // that this is compressed data and when we "decompress" we'll
+ // look for this signature to validate the data received.
ACE_OS::sprintf( compressed->wr_ptr(), "CD:%s", message->rd_ptr() );
compressed->wr_ptr( strlen(compressed->wr_ptr())+1 );
@@ -32,12 +48,27 @@ int Compressor::send(ACE_Message_Block *message, ACE_Time_Value *timeout)
return( 0 );
}
+/* And here's the decompression side. We've written Xmit/Recv so that
+ we're guaranteed to get an entire block of compressed data. If
+ we'd used recv() in the Recv object then we might have gotten a
+ partial block and that may not decompress very nicely.
+ */
int Compressor::recv(ACE_Message_Block *message, ACE_Time_Value *timeout)
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Compress::recv() decompressing (%s)\n", message->rd_ptr() ));
+ // Room for the decompressed data. In the real world you
+ // would probably want to send the original (uncompressed)
+ // data size in the message. You can predict the maximum
+ // possible decompression size but it's cheap and easy just to
+ // send that along. Look again at how I do exacly that
+ // between Xmit and Recv.
ACE_Message_Block * decompressed = new ACE_Message_Block( message->size() );
+ // Check for our signature. Even when you use a real
+ // compression algorithm you may want to include your own
+ // signature so that you can verify the block. It pays to be
+ // paranoid!
if( ACE_OS::strncmp( message->rd_ptr(), "CD:", 3 ) )
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Improperly encompressed data.\n" ));
@@ -45,9 +76,12 @@ int Compressor::recv(ACE_Message_Block *message, ACE_Time_Value *timeout)
return(-1);
}
+ // Skip past the signature before going any further.
message->rd_ptr( 3 );
- // Perform a bogus decompression algorithm
+ // Perform a bogus decompression algorithm. This is where you
+ // would feed to libz or your favorite decompressor. (It's
+ // costly but you could invoke popen() on gzip!)
ACE_OS::sprintf( decompressed->wr_ptr(), "%s", message->rd_ptr() );
decompressed->wr_ptr( strlen(decompressed->wr_ptr())+1 );
diff --git a/docs/tutorials/015/Compressor.h b/docs/tutorials/015/Compressor.h
index f1310432841..bc0257b16d1 100644
--- a/docs/tutorials/015/Compressor.h
+++ b/docs/tutorials/015/Compressor.h
@@ -6,27 +6,38 @@
#include "Protocol_Task.h"
-class ACE_SOCK_Stream;
-
+/* A reallly dumb compression object. (It actually adds 3 bytes to
+ every message block.)
+*/
class Compressor : public Protocol_Task
{
public:
typedef Protocol_Task inherited;
-
+
+ // I've given you the option of creating this task derivative
+ // with a number of threads. In retro-spect that really isn't
+ // a good idea. Most client/server systems rely on requests
+ // and responses happening in a predicatable order. Introduce
+ // a thread pool and message queue and that ordering goes
+ // right out the window. In other words: Don't ever use the
+ // constructor parameter!
Compressor( int _thr_count = 0 );
+
~Compressor(void);
protected:
+ // This is called when the compressor is on the downstream
+ // side. We'll take the message, compress it and move it
+ // along to the next module.
int send(ACE_Message_Block *message,
ACE_Time_Value *timeout);
+ // This one is called on the upstream side. No surprise: we
+ // decompress the data and send it on up the stream.
int recv(ACE_Message_Block *message,
ACE_Time_Value *timeout);
-
-private:
- mode_t mode_;
};
#endif // COMPRESSOR_H
diff --git a/docs/tutorials/015/Crypt.cpp b/docs/tutorials/015/Crypt.cpp
index 26827ce44b0..1e20b8f5b42 100644
--- a/docs/tutorials/015/Crypt.cpp
+++ b/docs/tutorials/015/Crypt.cpp
@@ -4,6 +4,8 @@
#include "Crypt.h"
#include "ace/SOCK_Stream.h"
+/* The expected constructor...
+ */
Crypt::Crypt( int _thr_count )
: inherited(_thr_count)
{
@@ -13,13 +15,19 @@ Crypt::~Crypt(void)
{
}
+/* To send the data we'll apply a signature and encryption.
+ */
int Crypt::send(ACE_Message_Block *message, ACE_Time_Value *timeout)
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Crypt::send() encrypting (%s)\n", message->rd_ptr() ));
+ // I suspect that some encryptors might change the data size.
+ // It probably isn't safe to create a same-size destination buffer.
ACE_Message_Block * encrypted = new ACE_Message_Block( message->size() );
- // Perform a bogus encryption algorithm
+ // Perform a bogus encryption algorithm and add our safety
+ // signature. Adding the original data size is also probably
+ // a good idea that I haven't encorporated here.
ACE_OS::sprintf( encrypted->wr_ptr(), "ED:%s", message->rd_ptr() );
encrypted->wr_ptr( strlen(encrypted->wr_ptr())+1 );
@@ -32,12 +40,18 @@ int Crypt::send(ACE_Message_Block *message, ACE_Time_Value *timeout)
return( 0 );
}
+/* The upstream movement requires that we decrypt what the peer has
+ given us.
+*/
int Crypt::recv(ACE_Message_Block *message, ACE_Time_Value *timeout)
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Crypt::recv() decrypting (%s)\n", message->rd_ptr() ));
+ // Create a destination for the decrypted data. The same
+ // block size caveat exists of course.
ACE_Message_Block * decrypted = new ACE_Message_Block( message->size() );
+ // Check the signature as expected.
if( ACE_OS::strncmp( message->rd_ptr(), "ED:", 3 ) )
{
ACE_DEBUG ((LM_INFO, "(%P|%t) Improperly encrypted data.\n" ));
@@ -45,6 +59,8 @@ int Crypt::recv(ACE_Message_Block *message, ACE_Time_Value *timeout)
return(-1);
}
+ // Don't forget to skip past the signature before decrypting
+ // or things will be quite exciting!
message->rd_ptr( 3 );
// Perform a bogus decryption algorithm
diff --git a/docs/tutorials/015/Crypt.h b/docs/tutorials/015/Crypt.h
index b34dda4c12e..7a38e1bdb52 100644
--- a/docs/tutorials/015/Crypt.h
+++ b/docs/tutorials/015/Crypt.h
@@ -6,25 +6,30 @@
#include "Protocol_Task.h"
-class ACE_SOCK_Stream;
-
+/* An interface (adaptor) between your favorite encryption method and
+ an ACE_Stream.
+*/
class Crypt : public Protocol_Task
{
public:
typedef Protocol_Task inherited;
-
+
+ // Again we have the option of multiple threads and again I
+ // regret tempting folks to use it.
Crypt( int _thr_count = 0 );
+
~Crypt(void);
protected:
+ // Moving downstream will encrypt the data
int send(ACE_Message_Block *message,
ACE_Time_Value *timeout);
+ // And moving upstream will decrypt it.
int recv(ACE_Message_Block *message,
ACE_Time_Value *timeout);
-private:
};
#endif // CRYPT_H
diff --git a/docs/tutorials/015/combine.shar b/docs/tutorials/015/combine.shar
index 564843d6251..2faa3e703da 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 1998-10-19 16:39 EDT by <jcej@caldera.lads.com>.
-# Source directory was `/scsiA/home/jcej/projects/ACE_wrappers/docs/tutorials/015'.
+# Made on 1998-10-19 20:42 EDT 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.
#
@@ -26,11 +26,16 @@
# 334 -rw-rw-r-- page11.pre
# 334 -rw-rw-r-- page12.pre
# 326 -rw-rw-r-- page13.pre
-# 770 -rw-rw-r-- page14.pre
-# 660 -rw-rw-r-- page15.pre
-# 213 -rw-rw-r-- page16.pre
-# 129 -rw-rw-r-- page17.pre
-# 348 -rw-rw-r-- page04.pst
+# 540 -rw-rw-r-- page14.pre
+# 770 -rw-rw-r-- page15.pre
+# 660 -rw-rw-r-- page16.pre
+# 213 -rw-rw-r-- page17.pre
+# 372 -rw-rw-r-- page18.pre
+# 281 -rw-rw-r-- page19.pre
+# 356 -rw-rw-r-- page20.pre
+# 151 -rw-rw-r-- page21.pre
+# 2551 -rw-rw-r-- page22.pre
+# 398 -rw-rw-r-- page04.pst
# 609 -rw-rw-r-- page09.pst
#
save_IFS="${IFS}"
@@ -78,7 +83,7 @@ else
fi
rm -f 1231235999 $$.touch
#
-if mkdir _sh23762; then
+if mkdir _sh02329; then
$echo 'x -' 'creating lock directory'
else
$echo 'failed to create lock directory'
@@ -594,36 +599,30 @@ if test -f 'page14.pre' && test "$first_param" != -c; then
else
$echo 'x -' extracting 'page14.pre' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'page14.pre' &&
-The implementation of Xmit isn't too complicated. If we choose to
-combine it with the Recv task we simply lift the recv() method from
-that object and drop it into this one.
-<P>
-Note that close() must decide if it's being called when the stream is
-shutdown or when it's svc() method exits. Since we tell the baseclass
-not to use any threads it's a safe bet that flags will always be
-non-zero. Still, it's good practice to plan for the future by
-checking the value.
+The Xmit object knows how to send data to the peer. It sits at the
+tail of the stream and gets everything that flows down from the head.
+In keeping with the spirit of things, this object does only one thing
+and doesn't concern itself with anyone else' details.
<P>
-Note also that when we send the data we prefix it with the data size.
-This let's our sibling Recv ensure that an entire block is received
-together. This can be very important for compression and encryption
-processes which typically work better with blocks of data instead of
-streams of data.
+The only thing you might want to do is combine it with Recv. Why?
+As you'll realize in a page or two, the Xmit and Recv objects must
+interact if you're going to ensure a safe transit. By having a single
+object it's easier to coordinate and maintain the interaction.
<HR>
SHAR_EOF
- $shar_touch -am 1019163798 'page14.pre' &&
+ $shar_touch -am 1019203498 'page14.pre' &&
chmod 0664 'page14.pre' ||
$echo 'restore of' 'page14.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 'page14.pre:' 'MD5 check failed'
-0d79137eaedd73b820037fcafe6e16b6 page14.pre
+bfc300ca2da5b82a5e452713cbf2f544 page14.pre
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page14.pre'`"
- test 770 -eq "$shar_count" ||
- $echo 'page14.pre:' 'original size' '770,' 'current size' "$shar_count!"
+ test 540 -eq "$shar_count" ||
+ $echo 'page14.pre:' 'original size' '540,' 'current size' "$shar_count!"
fi
fi
# ============= page15.pre ==============
@@ -632,18 +631,21 @@ if test -f 'page15.pre' && test "$first_param" != -c; then
else
$echo 'x -' extracting 'page15.pre' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'page15.pre' &&
-Recv is the sibling to Xmit. Again, they could be combined into a
-single object if you want.
+The implementation of Xmit isn't too complicated. If we choose to
+combine it with the Recv task we simply lift the recv() method from
+that object and drop it into this one.
<P>
-An ACE_Stream is designed to handle downstream traffic very
-well. You put() data into it and it flows along towards the tail.
-However, there doesn't seem to be a way to put data in such that it
-will travel upstream. To get around that, I've added a get() method
-to Recv that will trigger a read on the socket. Recv will then put
-the data to the next upstream module and we're on our way. As noted
-earlier, that data will eventually show up either in the <i>reader</i>
-(if installed on the stream open()) or the stream head reader task's
-message queue.
+Note that close() must decide if it's being called when the stream is
+shutdown or when it's svc() method exits. Since we tell the baseclass
+not to use any threads it's a safe bet that flags will always be
+non-zero. Still, it's good practice to plan for the future by
+checking the value.
+<P>
+Note also that when we send the data we prefix it with the data size.
+This let's our sibling Recv ensure that an entire block is received
+together. This can be very important for compression and encryption
+processes which typically work better with blocks of data instead of
+streams of data.
<HR>
SHAR_EOF
$shar_touch -am 1019163798 'page15.pre' &&
@@ -653,12 +655,12 @@ SHAR_EOF
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'page15.pre:' 'MD5 check failed'
-2d89b3c894cfcfdfef47ae506913cdad page15.pre
+0d79137eaedd73b820037fcafe6e16b6 page15.pre
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page15.pre'`"
- test 660 -eq "$shar_count" ||
- $echo 'page15.pre:' 'original size' '660,' 'current size' "$shar_count!"
+ test 770 -eq "$shar_count" ||
+ $echo 'page15.pre:' 'original size' '770,' 'current size' "$shar_count!"
fi
fi
# ============= page16.pre ==============
@@ -667,10 +669,18 @@ if test -f 'page16.pre' && test "$first_param" != -c; then
else
$echo 'x -' extracting 'page16.pre' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'page16.pre' &&
-The Recv implementation is nearly as simple as Xmit. There's
-opportunity for error when we get the message size and we have to
-manage the lifetime of the tickler but other than that it's pretty
-basic stuff.
+Recv is the sibling to Xmit. Again, they could be combined into a
+single object if you want.
+<P>
+An ACE_Stream is designed to handle downstream traffic very
+well. You put() data into it and it flows along towards the tail.
+However, there doesn't seem to be a way to put data in such that it
+will travel upstream. To get around that, I've added a get() method
+to Recv that will trigger a read on the socket. Recv will then put
+the data to the next upstream module and we're on our way. As noted
+earlier, that data will eventually show up either in the <i>reader</i>
+(if installed on the stream open()) or the stream head reader task's
+message queue.
<HR>
SHAR_EOF
$shar_touch -am 1019163798 'page16.pre' &&
@@ -680,12 +690,12 @@ SHAR_EOF
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'page16.pre:' 'MD5 check failed'
-7db337f2c6ec74d75560534dec550b0e page16.pre
+2d89b3c894cfcfdfef47ae506913cdad page16.pre
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page16.pre'`"
- test 213 -eq "$shar_count" ||
- $echo 'page16.pre:' 'original size' '213,' 'current size' "$shar_count!"
+ test 660 -eq "$shar_count" ||
+ $echo 'page16.pre:' 'original size' '660,' 'current size' "$shar_count!"
fi
fi
# ============= page17.pre ==============
@@ -694,8 +704,10 @@ if test -f 'page17.pre' && test "$first_param" != -c; then
else
$echo 'x -' extracting 'page17.pre' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'page17.pre' &&
-This and the next three pages present the protocol objects that
-provide compression and encryption. If you were hoping to
+The Recv implementation is nearly as simple as Xmit. There's
+opportunity for error when we get the message size and we have to
+manage the lifetime of the tickler but other than that it's pretty
+basic stuff.
<HR>
SHAR_EOF
$shar_touch -am 1019163798 'page17.pre' &&
@@ -705,12 +717,212 @@ SHAR_EOF
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'page17.pre:' 'MD5 check failed'
-d8553fb71b067ee360aca09883a6c775 page17.pre
+7db337f2c6ec74d75560534dec550b0e page17.pre
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page17.pre'`"
- test 129 -eq "$shar_count" ||
- $echo 'page17.pre:' 'original size' '129,' 'current size' "$shar_count!"
+ test 213 -eq "$shar_count" ||
+ $echo 'page17.pre:' 'original size' '213,' 'current size' "$shar_count!"
+ fi
+fi
+# ============= page18.pre ==============
+if test -f 'page18.pre' && test "$first_param" != -c; then
+ $echo 'x -' SKIPPING 'page18.pre' '(file already exists)'
+else
+ $echo 'x -' extracting 'page18.pre' '(text)'
+ sed 's/^X//' << 'SHAR_EOF' > 'page18.pre' &&
+This and the next three pages present the protocol objects that
+provide compression and encryption. If you were hoping to learn the
+secrets of compression and encryption then I'm going to disappoint
+you. There are some really good libraries out there that do this
+stuff though and if anyone wants to integrate one of them into the
+tutorial I'll be glad to take it!
+<HR>
+SHAR_EOF
+ $shar_touch -am 1019203698 'page18.pre' &&
+ chmod 0664 'page18.pre' ||
+ $echo 'restore of' 'page18.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 'page18.pre:' 'MD5 check failed'
+dc5f706bd5a27009aed167c0b137648e page18.pre
+SHAR_EOF
+ else
+ shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page18.pre'`"
+ test 372 -eq "$shar_count" ||
+ $echo 'page18.pre:' 'original size' '372,' 'current size' "$shar_count!"
+ fi
+fi
+# ============= page19.pre ==============
+if test -f 'page19.pre' && test "$first_param" != -c; then
+ $echo 'x -' SKIPPING 'page19.pre' '(file already exists)'
+else
+ $echo 'x -' extracting 'page19.pre' '(text)'
+ sed 's/^X//' << 'SHAR_EOF' > 'page19.pre' &&
+Here we implement the details of our compression. By having both
+compression and decompression in one object it's easier to keep track
+of implementation details. Splitting Xmit/Recv like I did will make
+things more difficult if something has to change in their interaction.
+<HR>
+SHAR_EOF
+ $shar_touch -am 1019195798 'page19.pre' &&
+ chmod 0664 'page19.pre' ||
+ $echo 'restore of' 'page19.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 'page19.pre:' 'MD5 check failed'
+4eb5dcd181f180d6c460971903efb288 page19.pre
+SHAR_EOF
+ else
+ shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page19.pre'`"
+ test 281 -eq "$shar_count" ||
+ $echo 'page19.pre:' 'original size' '281,' 'current size' "$shar_count!"
+ fi
+fi
+# ============= page20.pre ==============
+if test -f 'page20.pre' && test "$first_param" != -c; then
+ $echo 'x -' SKIPPING 'page20.pre' '(file already exists)'
+else
+ $echo 'x -' extracting 'page20.pre' '(text)'
+ sed 's/^X//' << 'SHAR_EOF' > 'page20.pre' &&
+While I might be able to come up with a competitive compressor, I
+don't have a snowball's chance to code up encryption. I'd be better
+off piping the data through the standard Unix crypt command.
+<P>
+So, while I was lazy with Compress, I'm realistic with Crypt. I'll
+show you the hooks and entry points and let someone else contribute an
+encryptor.
+<HR>
+SHAR_EOF
+ $shar_touch -am 1019203798 'page20.pre' &&
+ chmod 0664 'page20.pre' ||
+ $echo 'restore of' 'page20.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 'page20.pre:' 'MD5 check failed'
+7f75130d385a34b2c421a8d7cae69cc3 page20.pre
+SHAR_EOF
+ else
+ shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page20.pre'`"
+ test 356 -eq "$shar_count" ||
+ $echo 'page20.pre:' 'original size' '356,' 'current size' "$shar_count!"
+ fi
+fi
+# ============= page21.pre ==============
+if test -f 'page21.pre' && test "$first_param" != -c; then
+ $echo 'x -' SKIPPING 'page21.pre' '(file already exists)'
+else
+ $echo 'x -' extracting 'page21.pre' '(text)'
+ sed 's/^X//' << 'SHAR_EOF' > 'page21.pre' &&
+The encryption implementation isn't any smarter than that of the
+compressor. Still, the hooks are there for you to insert your
+favorite library.
+<HR>
+SHAR_EOF
+ $shar_touch -am 1019203898 'page21.pre' &&
+ chmod 0664 'page21.pre' ||
+ $echo 'restore of' 'page21.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 'page21.pre:' 'MD5 check failed'
+7f0f64452098cdef38c5496340a4b6c7 page21.pre
+SHAR_EOF
+ else
+ shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page21.pre'`"
+ test 151 -eq "$shar_count" ||
+ $echo 'page21.pre:' 'original size' '151,' 'current size' "$shar_count!"
+ fi
+fi
+# ============= page22.pre ==============
+if test -f 'page22.pre' && test "$first_param" != -c; then
+ $echo 'x -' SKIPPING 'page22.pre' '(file already exists)'
+else
+ $echo 'x -' extracting 'page22.pre' '(text)'
+ sed 's/^X//' << 'SHAR_EOF' > 'page22.pre' &&
+Well, this has certainly been one of the more verbose tutorials to
+date. I must say "thanks" to everyone who stuck it out this far!
+<P>
+A quick review of what we've done:
+<UL>
+X
+<LI>Create a simple client application and Client object that uses a
+Protocol Stream without really knowing how they work. The app (and
+object) rely on the public interface of the Protocol Stream to get the
+job done. At this level the protocol details are irrelevant.
+<P>
+<LI>Next, we create a simple server application and Server object
+similar to the client. The Protocol Stream is of course used and we
+have to know a little more so that we can insert a <i>reader</i> that
+will ultimately process the data from the client.
+<P>
+<LI>We then go into the details of the Protocol_Stream implementation
+and it's Protocol_Task object that forms the basis for the stream
+tasks. Each object is kept as small and simple as possible to improve
+reusability and future maintenance.
+<P>
+<LI>Finally, the individual protocol objects are discused. Separate
+objects for the peer interface were created as well as the bogus
+compressor and encryptor. The protocol can be extended or modified by
+creating new such objects and installing them in the Protocol_Stream's
+open() method.
+X
+</UL>
+<P>
+X
+It doesn't sound like much but it certainly took a bunch of files to
+get there. It's easy to get lost in the details when there's so much
+to cover so you're encouraged to go over things a couple of times.
+As always, enhancments of the tutorials is welcome!
+<P>
+Here's the complete file list:
+<UL>
+<LI><A HREF="client">Makefile</A>
+<P>
+<LI><A HREF="Makefile.client">client Makefile</A>
+<LI><A HREF="client.cpp">client.cpp</A>
+<LI><A HREF="Client.h">Client.h</A>
+<LI><A HREF="Client.cpp">Client.cpp</A>
+<P>
+<LI><A HREF="Makefile.server">Server Makefile</A>
+<LI><A HREF="server.cpp">server.cpp</A>
+<LI><A HREF="Server.h">Server.h</A>
+<LI><A HREF="Server.cpp">Server.cpp</A>
+<LI><A HREF="Handler.h">Handler.h</A>
+<LI><A HREF="Handler.cpp">Handler.cpp</A>
+<P>
+<LI><A HREF="Protocol_Stream.cpp">Protocol_Stream.cpp</A>
+<LI><A HREF="Protocol_Stream.h">Protocol_Stream.h</A>
+<LI><A HREF="Protocol_Task.cpp">Protocol_Task.cpp</A>
+<LI><A HREF="Protocol_Task.h">Protocol_Task.h</A>
+<P>
+<LI><A HREF="Xmit.cpp">Xmit.cpp</A>
+<LI><A HREF="Xmit.h">Xmit.h</A>
+<LI><A HREF="Recv.cpp">Recv.cpp</A>
+<LI><A HREF="Recv.h">Recv.h</A>
+<P>
+<LI><A HREF="Compressor.cpp">Compressor.cpp</A>
+<LI><A HREF="Compressor.h">Compressor.h</A>
+<LI><A HREF="Crypt.cpp">Crypt.cpp</A>
+<LI><A HREF="Crypt.h">Crypt.h</A>
+</UL>
+SHAR_EOF
+ $shar_touch -am 1019204198 'page22.pre' &&
+ chmod 0664 'page22.pre' ||
+ $echo 'restore of' 'page22.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 'page22.pre:' 'MD5 check failed'
+448ab5a481b51ec392aaac814a0bd005 page22.pre
+SHAR_EOF
+ else
+ shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page22.pre'`"
+ test 2551 -eq "$shar_count" ||
+ $echo 'page22.pre:' 'original size' '2551,' 'current size' "$shar_count!"
fi
fi
# ============= page04.pst ==============
@@ -726,6 +938,7 @@ X followed by an equally simple Client object.
<P>
For a quick look back:
<UL>
+<LI><A HREF="Makefile.client">client Makefile</A>
<LI><A HREF="client.cpp">client.cpp</A>
<LI><A HREF="Client.h">Client.h</A>
<LI><A HREF="Client.cpp">Client.cpp</A>
@@ -733,19 +946,19 @@ For a quick look back:
<P>
Now we'll move on and examine the server counter-part of our client.
SHAR_EOF
- $shar_touch -am 1019163798 'page04.pst' &&
+ $shar_touch -am 1019202198 'page04.pst' &&
chmod 0664 'page04.pst' ||
$echo 'restore of' 'page04.pst' '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 'page04.pst:' 'MD5 check failed'
-67b8e000792dd12883f8c89c09f14f13 page04.pst
+8fcb88614fd879307c71cea1d53e276f page04.pst
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page04.pst'`"
- test 348 -eq "$shar_count" ||
- $echo 'page04.pst:' 'original size' '348,' 'current size' "$shar_count!"
+ test 398 -eq "$shar_count" ||
+ $echo 'page04.pst:' 'original size' '398,' 'current size' "$shar_count!"
fi
fi
# ============= page09.pst ==============
@@ -763,23 +976,23 @@ cause confusion. We're going to discuss that mystery now but before
we do here's the list of server files if you want to review:
X
<UL>
+<LI><A HREF="Makefile.server">Server Makefile</A>
<LI><A HREF="server.cpp">server.cpp</A>
<LI><A HREF="Server.h">Server.h</A>
<LI><A HREF="Server.cpp">Server.cpp</A>
<LI><A HREF="Handler.h">Handler.h</A>
<LI><A HREF="Handler.cpp">Handler.cpp</A>
-<LI><A HREF="Makefile.server">Server Makefile</A>
</UL>
<P>
SHAR_EOF
- $shar_touch -am 1019163798 'page09.pst' &&
+ $shar_touch -am 1019202198 'page09.pst' &&
chmod 0664 'page09.pst' ||
$echo 'restore of' 'page09.pst' '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 'page09.pst:' 'MD5 check failed'
-a391cfe4b4fcd0002c418310c5b254c9 page09.pst
+22cfa1a8dadd48fccc7ed0c82aeba842 page09.pst
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page09.pst'`"
@@ -787,5 +1000,5 @@ SHAR_EOF
$echo 'page09.pst:' 'original size' '609,' 'current size' "$shar_count!"
fi
fi
-rm -fr _sh23762
+rm -fr _sh02329
exit 0
diff --git a/docs/tutorials/015/page04.html b/docs/tutorials/015/page04.html
index 3835dcffb39..5bd479f186e 100644
--- a/docs/tutorials/015/page04.html
+++ b/docs/tutorials/015/page04.html
@@ -85,6 +85,7 @@ Ok, that's it for the client. We've seen a very simple main()
<P>
For a quick look back:
<UL>
+<LI><A HREF="Makefile.client">client Makefile</A>
<LI><A HREF="client.cpp">client.cpp</A>
<LI><A HREF="Client.h">Client.h</A>
<LI><A HREF="Client.cpp">Client.cpp</A>
diff --git a/docs/tutorials/015/page09.html b/docs/tutorials/015/page09.html
index 6a842298010..e714c7334cf 100644
--- a/docs/tutorials/015/page09.html
+++ b/docs/tutorials/015/page09.html
@@ -213,12 +213,12 @@ cause confusion. We're going to discuss that mystery now but before
we do here's the list of server files if you want to review:
<UL>
+<LI><A HREF="Makefile.server">Server Makefile</A>
<LI><A HREF="server.cpp">server.cpp</A>
<LI><A HREF="Server.h">Server.h</A>
<LI><A HREF="Server.cpp">Server.cpp</A>
<LI><A HREF="Handler.h">Handler.h</A>
<LI><A HREF="Handler.cpp">Handler.cpp</A>
-<LI><A HREF="Makefile.server">Server Makefile</A>
</UL>
<P>
<P><HR WIDTH="100%">
diff --git a/docs/tutorials/015/page14.html b/docs/tutorials/015/page14.html
index 2478f40606e..36e0b02f932 100644
--- a/docs/tutorials/015/page14.html
+++ b/docs/tutorials/015/page14.html
@@ -12,21 +12,15 @@
<P>
<HR WIDTH="100%">
-The implementation of Xmit isn't too complicated. If we choose to
-combine it with the Recv task we simply lift the recv() method from
-that object and drop it into this one.
+The Xmit object knows how to send data to the peer. It sits at the
+tail of the stream and gets everything that flows down from the head.
+In keeping with the spirit of things, this object does only one thing
+and doesn't concern itself with anyone else' details.
<P>
-Note that close() must decide if it's being called when the stream is
-shutdown or when it's svc() method exits. Since we tell the baseclass
-not to use any threads it's a safe bet that flags will always be
-non-zero. Still, it's good practice to plan for the future by
-checking the value.
-<P>
-Note also that when we send the data we prefix it with the data size.
-This let's our sibling Recv ensure that an entire block is received
-together. This can be very important for compression and encryption
-processes which typically work better with blocks of data instead of
-streams of data.
+The only thing you might want to do is combine it with Recv. Why?
+As you'll realize in a page or two, the Xmit and Recv objects must
+interact if you're going to ensure a safe transit. By having a single
+object it's easier to coordinate and maintain the interaction.
<HR>
<PRE>
diff --git a/docs/tutorials/015/page15.html b/docs/tutorials/015/page15.html
index cae5a12f871..708e19b7183 100644
--- a/docs/tutorials/015/page15.html
+++ b/docs/tutorials/015/page15.html
@@ -12,18 +12,21 @@
<P>
<HR WIDTH="100%">
-Recv is the sibling to Xmit. Again, they could be combined into a
-single object if you want.
+The implementation of Xmit isn't too complicated. If we choose to
+combine it with the Recv task we simply lift the recv() method from
+that object and drop it into this one.
<P>
-An ACE_Stream is designed to handle downstream traffic very
-well. You put() data into it and it flows along towards the tail.
-However, there doesn't seem to be a way to put data in such that it
-will travel upstream. To get around that, I've added a get() method
-to Recv that will trigger a read on the socket. Recv will then put
-the data to the next upstream module and we're on our way. As noted
-earlier, that data will eventually show up either in the <i>reader</i>
-(if installed on the stream open()) or the stream head reader task's
-message queue.
+Note that close() must decide if it's being called when the stream is
+shutdown or when it's svc() method exits. Since we tell the baseclass
+not to use any threads it's a safe bet that flags will always be
+non-zero. Still, it's good practice to plan for the future by
+checking the value.
+<P>
+Note also that when we send the data we prefix it with the data size.
+This let's our sibling Recv ensure that an entire block is received
+together. This can be very important for compression and encryption
+processes which typically work better with blocks of data instead of
+streams of data.
<HR>
<PRE>
diff --git a/docs/tutorials/015/page16.html b/docs/tutorials/015/page16.html
index 75ca714d7dd..0ff4b76ec8a 100644
--- a/docs/tutorials/015/page16.html
+++ b/docs/tutorials/015/page16.html
@@ -12,10 +12,18 @@
<P>
<HR WIDTH="100%">
-The Recv implementation is nearly as simple as Xmit. There's
-opportunity for error when we get the message size and we have to
-manage the lifetime of the tickler but other than that it's pretty
-basic stuff.
+Recv is the sibling to Xmit. Again, they could be combined into a
+single object if you want.
+<P>
+An ACE_Stream is designed to handle downstream traffic very
+well. You put() data into it and it flows along towards the tail.
+However, there doesn't seem to be a way to put data in such that it
+will travel upstream. To get around that, I've added a get() method
+to Recv that will trigger a read on the socket. Recv will then put
+the data to the next upstream module and we're on our way. As noted
+earlier, that data will eventually show up either in the <i>reader</i>
+(if installed on the stream open()) or the stream head reader task's
+message queue.
<HR>
<PRE>
diff --git a/docs/tutorials/015/page17.html b/docs/tutorials/015/page17.html
index f563bfabd9a..d506014a77d 100644
--- a/docs/tutorials/015/page17.html
+++ b/docs/tutorials/015/page17.html
@@ -12,8 +12,10 @@
<P>
<HR WIDTH="100%">
-This and the next three pages present the protocol objects that
-provide compression and encryption. If you were hoping to
+The Recv implementation is nearly as simple as Xmit. There's
+opportunity for error when we get the message size and we have to
+manage the lifetime of the tickler but other than that it's pretty
+basic stuff.
<HR>
<PRE>
@@ -103,4 +105,4 @@ int <font color=#008888>Recv::recv</font>(ACE_Message_Block * message, ACE_Time_
}
</PRE>
<P><HR WIDTH="100%">
-<CENTER>[<A HREF="..">Tutorial Index</A>] </CENTER>
+<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page18.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/015/page18.html b/docs/tutorials/015/page18.html
new file mode 100644
index 00000000000..7f5603946b8
--- /dev/null
+++ b/docs/tutorials/015/page18.html
@@ -0,0 +1,68 @@
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="James CE Johnson">
+ <TITLE>ACE Tutorial 015</TITLE>
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
+
+<CENTER><B><FONT SIZE=+2>ACE Tutorial 015</FONT></B></CENTER>
+
+<CENTER><B><FONT SIZE=+2>Building a protocol stream</FONT></B></CENTER>
+
+<P>
+<HR WIDTH="100%">
+This and the next three pages present the protocol objects that
+provide compression and encryption. If you were hoping to learn the
+secrets of compression and encryption then I'm going to disappoint
+you. There are some really good libraries out there that do this
+stuff though and if anyone wants to integrate one of them into the
+tutorial I'll be glad to take it!
+<HR>
+<PRE>
+
+<font color=red>// $Id$</font>
+
+<font color=blue>#ifndef</font> <font color=purple>COMPRESSOR_H</font>
+<font color=blue>#define</font> <font color=purple>COMPRESSOR_h</font>
+
+<font color=blue>#include</font> "<font color=green>Protocol_Task.h</font>"
+
+<font color=red>/* A reallly dumb compression object. (It actually adds 3 bytes to
+ every message block.)
+*/</font>
+class Compressor : public Protocol_Task
+{
+public:
+
+ typedef Protocol_Task inherited;
+
+ <font color=red>// I've given you the option of creating this task derivative</font>
+ <font color=red>// with a number of threads. In retro-spect that really isn't </font>
+ <font color=red>// a good idea. Most client/server systems rely on requests</font>
+ <font color=red>// and responses happening in a predicatable order. Introduce </font>
+ <font color=red>// a thread pool and message queue and that ordering goes</font>
+ <font color=red>// right out the window. In other words: Don't ever use the</font>
+ <font color=red>// constructor parameter!</font>
+ Compressor( int _thr_count = 0 );
+
+ ~Compressor(void);
+
+protected:
+
+ <font color=red>// This is called when the compressor is on the downstream</font>
+ <font color=red>// side. We'll take the message, compress it and move it</font>
+ <font color=red>// along to the next module.</font>
+ int send(ACE_Message_Block *message,
+ ACE_Time_Value *timeout);
+
+ <font color=red>// This one is called on the upstream side. No surprise: we</font>
+ <font color=red>// decompress the data and send it on up the stream.</font>
+ int recv(ACE_Message_Block *message,
+ ACE_Time_Value *timeout);
+};
+
+<font color=blue>#endif</font> <font color=red>// COMPRESSOR_H</font>
+</PRE>
+<P><HR WIDTH="100%">
+<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page19.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/015/page19.html b/docs/tutorials/015/page19.html
new file mode 100644
index 00000000000..73103ff15bf
--- /dev/null
+++ b/docs/tutorials/015/page19.html
@@ -0,0 +1,119 @@
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="James CE Johnson">
+ <TITLE>ACE Tutorial 015</TITLE>
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
+
+<CENTER><B><FONT SIZE=+2>ACE Tutorial 015</FONT></B></CENTER>
+
+<CENTER><B><FONT SIZE=+2>Building a protocol stream</FONT></B></CENTER>
+
+<P>
+<HR WIDTH="100%">
+Here we implement the details of our compression. By having both
+compression and decompression in one object it's easier to keep track
+of implementation details. Splitting Xmit/Recv like I did will make
+things more difficult if something has to change in their interaction.
+<HR>
+<PRE>
+
+<font color=red>// $Id$</font>
+
+<font color=blue>#include</font> "<font color=green>Compressor.h</font>"
+<font color=blue>#include</font> "<font color=green>ace/SOCK_Stream.h</font>"
+
+<font color=red>/* Construct our baseclass with the proper thread count. I really
+ should remove this option...
+ */</font>
+<font color=#008888>Compressor::Compressor</font>( int _thr_count )
+ : inherited(_thr_count)
+{
+ ;
+}
+
+<font color=#008888>Compressor::~Compressor</font>(void)
+{
+ ;
+}
+
+<font color=red>/* This is where you insert your compression code. Most compressors
+ want to work on a block of data instead of a byte-stream.
+ Fortunately the message block has a block that can be compressed.
+ Take a look at libz for a quick way to add compression to your
+ apps
+ */</font>
+int <font color=#008888>Compressor::send</font>(ACE_Message_Block *message, ACE_Time_Value *timeout)
+{
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) <font color=#008888>Compressor::send</font>() compressing (%s)\n</font>", message->rd_ptr() ));
+
+ <font color=red>// Create a block to hold the compressed data. I belive libz</font>
+ <font color=red>// recommends a buffer about 10-20% larger than the source.</font>
+ <font color=red>// Other libraries/algorithms may have their own quirks.</font>
+ ACE_Message_Block * compressed = new ACE_Message_Block( message->size() );
+
+ <font color=red>// Perform a bogus compression algorithm. 'CD' just tells me</font>
+ <font color=red>// that this is compressed data and when we "<font color=green>decompress</font>" we'll </font>
+ <font color=red>// look for this signature to validate the data received.</font>
+ <font color=#008888>ACE_OS::sprintf</font>( compressed->wr_ptr(), "<font color=green>CD:%s</font>", message->rd_ptr() );
+ compressed->wr_ptr( strlen(compressed->wr_ptr())+1 );
+
+ <font color=red>// Send the compressed data down the stream to the next module</font>
+ this->put_next( compressed );
+
+ <font color=red>// We're done here.</font>
+ message->release();
+
+ return( 0 );
+}
+
+<font color=red>/* And here's the decompression side. We've written Xmit/Recv so that
+ we're guaranteed to get an entire block of compressed data. If
+ we'd used recv() in the Recv object then we might have gotten a
+ partial block and that may not decompress very nicely.
+ */</font>
+int <font color=#008888>Compressor::recv</font>(ACE_Message_Block *message, ACE_Time_Value *timeout)
+{
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) <font color=#008888>Compress::recv</font>() decompressing (%s)\n</font>", message->rd_ptr() ));
+
+ <font color=red>// Room for the decompressed data. In the real world you</font>
+ <font color=red>// would probably want to send the original (uncompressed)</font>
+ <font color=red>// data size in the message. You can predict the maximum</font>
+ <font color=red>// possible decompression size but it's cheap and easy just to </font>
+ <font color=red>// send that along. Look again at how I do exacly that</font>
+ <font color=red>// between Xmit and Recv.</font>
+ ACE_Message_Block * decompressed = new ACE_Message_Block( message->size() );
+
+ <font color=red>// Check for our signature. Even when you use a real</font>
+ <font color=red>// compression algorithm you may want to include your own</font>
+ <font color=red>// signature so that you can verify the block. It pays to be</font>
+ <font color=red>// paranoid!</font>
+ if( <font color=#008888>ACE_OS::strncmp</font>( message->rd_ptr(), "<font color=green>CD:</font>", 3 ) )
+ {
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) Improperly encompressed data.\n</font>" ));
+ message->release();
+ return(-1);
+ }
+
+ <font color=red>// Skip past the signature before going any further.</font>
+ message->rd_ptr( 3 );
+
+ <font color=red>// Perform a bogus decompression algorithm. This is where you </font>
+ <font color=red>// would feed to libz or your favorite decompressor. (It's</font>
+ <font color=red>// costly but you could invoke popen() on gzip!)</font>
+ <font color=#008888>ACE_OS::sprintf</font>( decompressed->wr_ptr(), "<font color=green>%s</font>", message->rd_ptr() );
+ decompressed->wr_ptr( strlen(decompressed->wr_ptr())+1 );
+
+ <font color=red>// Recv the decompressed data down the stream to the next module</font>
+ this->put_next( decompressed );
+
+ <font color=red>// We're done here.</font>
+ message->release();
+
+ return( 0 );
+}
+
+</PRE>
+<P><HR WIDTH="100%">
+<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page20.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/015/page20.html b/docs/tutorials/015/page20.html
new file mode 100644
index 00000000000..6f81ebfa5ec
--- /dev/null
+++ b/docs/tutorials/015/page20.html
@@ -0,0 +1,61 @@
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="James CE Johnson">
+ <TITLE>ACE Tutorial 015</TITLE>
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
+
+<CENTER><B><FONT SIZE=+2>ACE Tutorial 015</FONT></B></CENTER>
+
+<CENTER><B><FONT SIZE=+2>Building a protocol stream</FONT></B></CENTER>
+
+<P>
+<HR WIDTH="100%">
+While I might be able to come up with a competitive compressor, I
+don't have a snowball's chance to code up encryption. I'd be better
+off piping the data through the standard Unix crypt command.
+<P>
+So, while I was lazy with Compress, I'm realistic with Crypt. I'll
+show you the hooks and entry points and let someone else contribute an
+encryptor.
+<HR>
+<PRE>
+
+<font color=red>// $Id$</font>
+
+<font color=blue>#ifndef</font> <font color=purple>CRYPT_H</font>
+<font color=blue>#define</font> <font color=purple>CRYPT_h</font>
+
+<font color=blue>#include</font> "<font color=green>Protocol_Task.h</font>"
+
+<font color=red>/* An interface (adaptor) between your favorite encryption method and
+ an ACE_Stream.
+*/</font>
+class Crypt : public Protocol_Task
+{
+public:
+
+ typedef Protocol_Task inherited;
+
+ <font color=red>// Again we have the option of multiple threads and again I</font>
+ <font color=red>// regret tempting folks to use it.</font>
+ Crypt( int _thr_count = 0 );
+
+ ~Crypt(void);
+
+protected:
+
+ <font color=red>// Moving downstream will encrypt the data</font>
+ int send(ACE_Message_Block *message,
+ ACE_Time_Value *timeout);
+
+ <font color=red>// And moving upstream will decrypt it.</font>
+ int recv(ACE_Message_Block *message,
+ ACE_Time_Value *timeout);
+};
+
+<font color=blue>#endif</font> <font color=red>// CRYPT_H</font>
+</PRE>
+<P><HR WIDTH="100%">
+<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page21.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/015/page21.html b/docs/tutorials/015/page21.html
new file mode 100644
index 00000000000..5b017dcf609
--- /dev/null
+++ b/docs/tutorials/015/page21.html
@@ -0,0 +1,99 @@
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="James CE Johnson">
+ <TITLE>ACE Tutorial 015</TITLE>
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
+
+<CENTER><B><FONT SIZE=+2>ACE Tutorial 015</FONT></B></CENTER>
+
+<CENTER><B><FONT SIZE=+2>Building a protocol stream</FONT></B></CENTER>
+
+<P>
+<HR WIDTH="100%">
+The encryption implementation isn't any smarter than that of the
+compressor. Still, the hooks are there for you to insert your
+favorite library.
+<HR>
+<PRE>
+
+<font color=red>// $Id$</font>
+
+<font color=blue>#include</font> "<font color=green>Crypt.h</font>"
+<font color=blue>#include</font> "<font color=green>ace/SOCK_Stream.h</font>"
+
+<font color=red>/* The expected constructor...
+ */</font>
+<font color=#008888>Crypt::Crypt</font>( int _thr_count )
+ : inherited(_thr_count)
+{
+}
+
+<font color=#008888>Crypt::~Crypt</font>(void)
+{
+}
+
+<font color=red>/* To send the data we'll apply a signature and encryption.
+ */</font>
+int <font color=#008888>Crypt::send</font>(ACE_Message_Block *message, ACE_Time_Value *timeout)
+{
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) <font color=#008888>Crypt::send</font>() encrypting (%s)\n</font>", message->rd_ptr() ));
+
+ <font color=red>// I suspect that some encryptors might change the data size.</font>
+ <font color=red>// It probably isn't safe to create a same-size destination buffer.</font>
+ ACE_Message_Block * encrypted = new ACE_Message_Block( message->size() );
+
+ <font color=red>// Perform a bogus encryption algorithm and add our safety</font>
+ <font color=red>// signature. Adding the original data size is also probably</font>
+ <font color=red>// a good idea that I haven't encorporated here.</font>
+ <font color=#008888>ACE_OS::sprintf</font>( encrypted->wr_ptr(), "<font color=green>ED:%s</font>", message->rd_ptr() );
+ encrypted->wr_ptr( strlen(encrypted->wr_ptr())+1 );
+
+ <font color=red>// Send the encrypted data down the stream to the next module</font>
+ this->put_next( encrypted );
+
+ <font color=red>// We're done here.</font>
+ message->release();
+
+ return( 0 );
+}
+
+<font color=red>/* The upstream movement requires that we decrypt what the peer has
+ given us.
+*/</font>
+int <font color=#008888>Crypt::recv</font>(ACE_Message_Block *message, ACE_Time_Value *timeout)
+{
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) <font color=#008888>Crypt::recv</font>() decrypting (%s)\n</font>", message->rd_ptr() ));
+
+ <font color=red>// Create a destination for the decrypted data. The same</font>
+ <font color=red>// block size caveat exists of course.</font>
+ ACE_Message_Block * decrypted = new ACE_Message_Block( message->size() );
+
+ <font color=red>// Check the signature as expected.</font>
+ if( <font color=#008888>ACE_OS::strncmp</font>( message->rd_ptr(), "<font color=green>ED:</font>", 3 ) )
+ {
+ ACE_DEBUG ((LM_INFO, "<font color=green>(%P|%t) Improperly encrypted data.\n</font>" ));
+ message->release();
+ return(-1);
+ }
+
+ <font color=red>// Don't forget to skip past the signature before decrypting</font>
+ <font color=red>// or things will be quite exciting!</font>
+ message->rd_ptr( 3 );
+
+ <font color=red>// Perform a bogus decryption algorithm</font>
+ <font color=#008888>ACE_OS::sprintf</font>( decrypted->wr_ptr(), "<font color=green>%s</font>", message->rd_ptr() );
+ decrypted->wr_ptr( strlen(decrypted->wr_ptr())+1 );
+
+ <font color=red>// Send the decrypted data down the stream to the next module</font>
+ this->put_next( decrypted );
+
+ <font color=red>// We're done here.</font>
+ message->release();
+
+ return( 0 );
+}
+</PRE>
+<P><HR WIDTH="100%">
+<CENTER>[<A HREF="..">Tutorial Index</A>] [<A HREF="page22.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/015/page22.html b/docs/tutorials/015/page22.html
new file mode 100644
index 00000000000..90843ab2d31
--- /dev/null
+++ b/docs/tutorials/015/page22.html
@@ -0,0 +1,82 @@
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="Author" CONTENT="James CE Johnson">
+ <TITLE>ACE Tutorial 015</TITLE>
+</HEAD>
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
+
+<CENTER><B><FONT SIZE=+2>ACE Tutorial 015</FONT></B></CENTER>
+
+<CENTER><B><FONT SIZE=+2>Building a protocol stream</FONT></B></CENTER>
+
+<P>
+<HR WIDTH="100%">
+Well, this has certainly been one of the more verbose tutorials to
+date. I must say "thanks" to everyone who stuck it out this far!
+<P>
+A quick review of what we've done:
+<UL>
+
+<LI>Create a simple client application and Client object that uses a
+Protocol Stream without really knowing how they work. The app (and
+object) rely on the public interface of the Protocol Stream to get the
+job done. At this level the protocol details are irrelevant.
+<P>
+<LI>Next, we create a simple server application and Server object
+similar to the client. The Protocol Stream is of course used and we
+have to know a little more so that we can insert a <i>reader</i> that
+will ultimately process the data from the client.
+<P>
+<LI>We then go into the details of the Protocol_Stream implementation
+and it's Protocol_Task object that forms the basis for the stream
+tasks. Each object is kept as small and simple as possible to improve
+reusability and future maintenance.
+<P>
+<LI>Finally, the individual protocol objects are discused. Separate
+objects for the peer interface were created as well as the bogus
+compressor and encryptor. The protocol can be extended or modified by
+creating new such objects and installing them in the Protocol_Stream's
+open() method.
+
+</UL>
+<P>
+
+It doesn't sound like much but it certainly took a bunch of files to
+get there. It's easy to get lost in the details when there's so much
+to cover so you're encouraged to go over things a couple of times.
+As always, enhancments of the tutorials is welcome!
+<P>
+Here's the complete file list:
+<UL>
+<LI><A HREF="client">Makefile</A>
+<P>
+<LI><A HREF="Makefile.client">client Makefile</A>
+<LI><A HREF="client.cpp">client.cpp</A>
+<LI><A HREF="Client.h">Client.h</A>
+<LI><A HREF="Client.cpp">Client.cpp</A>
+<P>
+<LI><A HREF="Makefile.server">Server Makefile</A>
+<LI><A HREF="server.cpp">server.cpp</A>
+<LI><A HREF="Server.h">Server.h</A>
+<LI><A HREF="Server.cpp">Server.cpp</A>
+<LI><A HREF="Handler.h">Handler.h</A>
+<LI><A HREF="Handler.cpp">Handler.cpp</A>
+<P>
+<LI><A HREF="Protocol_Stream.cpp">Protocol_Stream.cpp</A>
+<LI><A HREF="Protocol_Stream.h">Protocol_Stream.h</A>
+<LI><A HREF="Protocol_Task.cpp">Protocol_Task.cpp</A>
+<LI><A HREF="Protocol_Task.h">Protocol_Task.h</A>
+<P>
+<LI><A HREF="Xmit.cpp">Xmit.cpp</A>
+<LI><A HREF="Xmit.h">Xmit.h</A>
+<LI><A HREF="Recv.cpp">Recv.cpp</A>
+<LI><A HREF="Recv.h">Recv.h</A>
+<P>
+<LI><A HREF="Compressor.cpp">Compressor.cpp</A>
+<LI><A HREF="Compressor.h">Compressor.h</A>
+<LI><A HREF="Crypt.cpp">Crypt.cpp</A>
+<LI><A HREF="Crypt.h">Crypt.h</A>
+</UL>
+<P><HR WIDTH="100%">
+<CENTER>[<A HREF="..">Tutorial Index</A>] </CENTER>
diff --git a/docs/tutorials/index.html b/docs/tutorials/index.html
index 1ba3fbcc63a..bbdd6e350e7 100644
--- a/docs/tutorials/index.html
+++ b/docs/tutorials/index.html
@@ -93,6 +93,19 @@ A word about ACE_Message_Queue</H4>
<LI>
<A HREF="013/page01.html">Task chains and state machines</A></LI>
</OL>
+
+<P><HR WIDTH="50%" align=left><P>
+
+<H4>
+Paddling down (and up) the ACE_Stream</H4>
+
+<OL>
+<LI>
+<A HREF="014/page01.html">ACE_Stream Tutorial, Of Sorts</A></LI>
+<LI>
+<A HREF="015/page01.html">A certain amount of Protocol is required!</A></LI>
+</OL>
+
<HR>
<P>Back to the <A
View Lorry Controller Status