Removed left over Id tags

5 files changed, 53 insertions, 67 deletions

diff --git a/ACE/performance-tests/RPC/ping.x b/ACE/performance-tests/RPC/ping.x
index ea078ffe139..31c3be713b5 100644
--- a/ACE/performance-tests/RPC/ping.x
+++ b/ACE/performance-tests/RPC/ping.x
@@ -1,8 +1,4 @@
 /*
- * $Id$
- */
-
-/*
  * A small program to test RPC round-trip delays.
  */
 program PINGPROG {
diff --git a/ACE/performance-tests/SCTP/README.OpenSS7 b/ACE/performance-tests/SCTP/README.OpenSS7
index 5183e872e12..6e811bd7630 100644
--- a/ACE/performance-tests/SCTP/README.OpenSS7
+++ b/ACE/performance-tests/SCTP/README.OpenSS7
@@ -1,30 +1,28 @@
-// $Id$
-
 This document describes the OpenSS7 API in detail.
 
 Introduction
 =============
- 
-OpenSS7 defines two types of services, UDP style and TCP style.  How OpenSS7 
-distinguishes the two styles is by the way in which the data is presented to 
-the application.  In OpenSS7, data is presented as byte streams or datagrams.  
-The stream style is considered the TCP style socket, and the datagram is 
+
+OpenSS7 defines two types of services, UDP style and TCP style.  How OpenSS7
+distinguishes the two styles is by the way in which the data is presented to
+the application.  In OpenSS7, data is presented as byte streams or datagrams.
+The stream style is considered the TCP style socket, and the datagram is
 considered the UDP style socket.  The UDP style socket does not represent a one
-to many mapping of file descriptors to associations as the IETF compatible 
+to many mapping of file descriptors to associations as the IETF compatible
 sockets does.
 
 Instead of adding new system calls, OpenSS7 decided to modify some of the
-existing system calls to play nicely with multi-homing.  So, to bind to 
+existing system calls to play nicely with multi-homing.  So, to bind to
 multiple addresses, you pass in an array of struct sockaddr* structures and the
 total length in bytes of the array.  Also, when accepting connections from a
-peer, you would pass in a pointer to an array of struct sockaddr* and the 
+peer, you would pass in a pointer to an array of struct sockaddr* and the
 length of the array in bytes.
 
 
 Building ACE/TAO with support for OpenSS7 SCTP
 ==============================================
 
-        - apply OpenSS7's SCTP patch (see OpenSS7's readme for details) 
+        - apply OpenSS7's SCTP patch (see OpenSS7's readme for details)
 
         - compile kernel with the following kernel variables (.config file)
                 + CONFIG_SCTP=y
@@ -42,7 +40,7 @@ Common Calls
 ============
 
 There are a few common calls which have the same semantics no matter which
-interface you are using (UDP style or TCP style).  So, the usual calls used in 
+interface you are using (UDP style or TCP style).  So, the usual calls used in
 a client are:
 
   1) socket()
@@ -61,7 +59,7 @@ while the usual calls for a server are as follows:
   5) accept()
   6) close()
 
-The previous example mimics the way in which the TCP protocol is used.  
+The previous example mimics the way in which the TCP protocol is used.
 There are some exceptions to the above sequence which we will get into a little
 later. So, let's talk about the system calls above.
 
@@ -106,7 +104,7 @@ The connect() call can be used to initialize a connection with a peer SCTP
 machine.  A connection can be initialized in 2 ways.  The first is this
 call(connect()).  The second way is to allow implicit initialization when the
 application calls sendmsg or sendto with the address of the remote host
-specified.  To allow data to be piggybacked with the COOKIE_ECHO chunk, you 
+specified.  To allow data to be piggybacked with the COOKIE_ECHO chunk, you
 must use the second initialization technique.  The signature of connect is as
 follows:
 
@@ -133,9 +131,9 @@ Accept()
 --------
 The accept() call allows the application to explicitly accept an incoming
 association initialization attempt.  accept() returns a new file descriptor
-which can be used to send data to the client.  accept() has a slightly 
-different semantic which allows it to take an array of address structures.  
-This gives the application the chance to get a specified number of addresses 
+which can be used to send data to the client.  accept() has a slightly
+different semantic which allows it to take an array of address structures.
+This gives the application the chance to get a specified number of addresses
 from the peer on initialization.  The signature of accept() is as follows:
 
   int accept(int fd, struct sockaddr* r_addr, socklen_t *r_addr_len)
@@ -159,7 +157,7 @@ Start the association shutdown sequence.  The signature is as follows:
 Data Interfaces
 ===============
 This section describes the sending and receiving of data on an SCTP socket.
-This is where the differences between the TCP style and UDP style sockets 
+This is where the differences between the TCP style and UDP style sockets
 shows.  SCTP uses the standard pairs of calls:
 
   1) send()/recv()
@@ -174,15 +172,15 @@ calls returns only datagrams.  For example, assume a sender sends 2 100 byte
 datagrams.  Now assume that the receiver calls one of the receive routines with
 a max buffer size of 120 bytes.  Assuming no errors are encountered, only 100
 bytes are returned to the receiver (only 1 datagram), leaving the last 20 bytes
-empty in the receivers buffer.  When the last of a datagram is read, the 
-MSG_EOR flag is returned, and if the datagram is too big to fit into the 
-specified buffer, the MSG_TRUNC flag is returned.  
+empty in the receivers buffer.  When the last of a datagram is read, the
+MSG_EOR flag is returned, and if the datagram is too big to fit into the
+specified buffer, the MSG_TRUNC flag is returned.
 
 With TCP styles sockets, the data is presented to the application as a stream
-of bytes (like TCP).  For example, assume the sender sends 2 100 byte 
-datagrams.  Now assume that the receiver calls one of the receive routines with 
-a max buffer size of 120.  Assuming no errors are encountered, 120 bytes are 
-returned (100 from the first datagram and 20 from the next datagram), leaving 
+of bytes (like TCP).  For example, assume the sender sends 2 100 byte
+datagrams.  Now assume that the receiver calls one of the receive routines with
+a max buffer size of 120.  Assuming no errors are encountered, 120 bytes are
+returned (100 from the first datagram and 20 from the next datagram), leaving
 80 bytes in the second datagram.  MSG_EOR and MSG_TRUNC are never returned.
 
 Send()/Recv()
@@ -217,10 +215,10 @@ The msg argument holds the data to be sent to the peer.  It also can take an
 address to send the data to.  So, for example, if you had an association with 2
 addresses for the peer and the default path used the first address, and you
 wanted to send data to the other address, you could specify that address in the
-msg structure.  If this address field is NULL, then data is sent out the       
-default address.  
+msg structure.  If this address field is NULL, then data is sent out the
+default address.
 
-This interface also allows other functions by using the ancillary data field 
+This interface also allows other functions by using the ancillary data field
 in the msg structure.  By using the ancillary data field, you may send data out
 a different stream by using the SCTP_SID control message.  This type of control
 message would take an integer representing the stream to send data out as it's
@@ -233,7 +231,7 @@ Sendto()/Recvfrom()
 The sendto/recvfrom interface allows the specification of which remote address
 to send data.  The signature of sendto/recvfrom is as follows:
 
-  int sendto(int fd, void *data, size_t d_len, int flags, 
+  int sendto(int fd, void *data, size_t d_len, int flags,
              struct sockaddr* r_addr, socklen_t r_addr_len)
   Where:
     fd         - A SCTP socket descriptor
diff --git a/ACE/performance-tests/SCTP/README.SCTP b/ACE/performance-tests/SCTP/README.SCTP
index 95c3cb0b53a..afe6853730b 100644
--- a/ACE/performance-tests/SCTP/README.SCTP
+++ b/ACE/performance-tests/SCTP/README.SCTP
@@ -1,22 +1,19 @@
-#       $Id$        
-
-This document provides general information about the SCTP protocol.  
-
+This document provides general information about the SCTP protocol.
 
 Introduction
 =============
-SCTP (Stream Control Transmission Protocol) is a new transport layer protocol 
-developed by the IETF and defined by RFC2960.  Originally designed for the 
-transmission of message-oriented applications such as the transportation of 
+SCTP (Stream Control Transmission Protocol) is a new transport layer protocol
+developed by the IETF and defined by RFC2960.  Originally designed for the
+transmission of message-oriented applications such as the transportation of
 signaling data for PSTNs (Public Switched Telephone Networks), SCTP can be used
-in any application that uses TCP.  
+in any application that uses TCP.
 
         Major Features
         --------------
 
         - Direct support for multi-homing
-        - Support for multiple streams per connection (known as associations) 
-          to reduce "head of line" blocking problems.   
+        - Support for multiple streams per connection (known as associations)
+          to reduce "head of line" blocking problems.
         - Four way handshake reducing the possibility for blind denial of
           service attacks.
         - Adjustment of congestion control parameters
@@ -25,31 +22,31 @@ in any application that uses TCP.
 API's
 ========
 
-The SCTP drafts have defined several different API's.  The first reference 
-implementation was a user level library.  This allowed an application to use 
-SCTP through several functions and callbacks.  As of this writing a 
+The SCTP drafts have defined several different API's.  The first reference
+implementation was a user level library.  This allowed an application to use
+SCTP through several functions and callbacks.  As of this writing a
 transition from the user level libraries to the kernel is underway.
 
-The IETF TSVWG (Transport Area Working Group) has published a draft 
-(draft-ietf-tsvwg-sctpsocket-06.txt) that defines a mapping between SCTP and 
+The IETF TSVWG (Transport Area Working Group) has published a draft
+(draft-ietf-tsvwg-sctpsocket-06.txt) that defines a mapping between SCTP and
 the BSD sockets interface.  This interface has made porting TCP applications to
 SCTP as simple as changing one socket call.
 
         OpenSS7
         --------
-        OpenSS7 has defined, a similar BSD style sockets interface.  It is 
+        OpenSS7 has defined, a similar BSD style sockets interface.  It is
         slightly different from the one defined by the IETF, however, at the
-        time of our evaluation it was the most stable implementation.  
+        time of our evaluation it was the most stable implementation.
 
-        Please see README.OpenSS7 for details and build instructions.   
+        Please see README.OpenSS7 for details and build instructions.
 
         LKSCTP
         ------
-        The LKSCTP implementation is based on the TSVWG's sockets draft.  
+        The LKSCTP implementation is based on the TSVWG's sockets draft.
         It is included with the Linux 2.6 series test kernels. Backported
-        (Linux 2.4) patches are also available from the LKSCTP website.  
+        (Linux 2.4) patches are also available from the LKSCTP website.
 
-        Please see README.LKSCTP for more details and build instructions.  
+        Please see README.LKSCTP for more details and build instructions.
 
 Resources
 ===========
@@ -61,8 +58,8 @@ Resources
 
         Internet-Drafts
         ----------------
-        
-        draft-ietf-tsvwg-sctpsocket-07.txt: 
+
+        draft-ietf-tsvwg-sctpsocket-07.txt:
                 Sockets API Extensions for Stream Control Transmission Protocol
 
         draft-ietf-tsvwg-sctpimpguide-08.txt
diff --git a/ACE/performance-tests/SCTP/README.SCTP_PERF_TEST b/ACE/performance-tests/SCTP/README.SCTP_PERF_TEST
index 81cacef02e0..1d2006c24c0 100644
--- a/ACE/performance-tests/SCTP/README.SCTP_PERF_TEST
+++ b/ACE/performance-tests/SCTP/README.SCTP_PERF_TEST
@@ -1,5 +1,3 @@
-$Id$
-
 Release 1.0 - January 2003
 
 ***********************************
@@ -141,7 +139,7 @@ and used on the command line in place of the shorter "Flag".  Hence
 
    ./SOCK_STREAM_clt -s 5
 
-is equivalent to 
+is equivalent to
 
    ./SOCK_STREAM_clt --payload-size-power-of-2 5
 
@@ -230,7 +228,7 @@ SOCK_SEQPACK_srv:
         Enable Nagle's algorithm (which is disabled by default).
 
     server-port  [ -p int ]
- 
+
         the port where the server's passive-mode socket will be
         bound.  The default is 45453.
 
@@ -258,7 +256,7 @@ SOCK_SEQPACK_srv, but the latter offers additional functionality:
         If your machine has three or more interfaces, and you wish to
         bind the socket only to a subset of two or more, AND you are
         using SOCK_SEQPACK_srv, THEN you may explicitly specify the
-        desired interface with an expression such as 
+        desired interface with an expression such as
         "-a 192.168.221.104,192.168.1.43".  The argument here is a
         comma-delimited list of dotted-decimal IPv4 addresses with no
         whitespace interspersed.  This level of control is not
@@ -300,7 +298,7 @@ The steps of the walk-through are as follows:
 1.  Start the server.
 
     $ ./SOCK_STREAM_srv
-    (12761|1024) Accepting connections on port 45453 
+    (12761|1024) Accepting connections on port 45453
                  on interface INADDR_ANY using IPPROTO_SCTP
     (12761|1024) starting server at port 45453
     (12761|1024) select timed out
@@ -308,7 +306,7 @@ The steps of the walk-through are as follows:
     (12761|1024) select timed out
     (12761|1024) select timed out
     ...
-    
+
     The server will continue to print, periodically, the message
     "select timed out" as it waits for clients to connect.
 
@@ -317,7 +315,7 @@ The steps of the walk-through are as follows:
     $ ./SOCK_STREAM_clt -s 7 -c 1000
 
 3.  Observing the debugging output from the server, you should see
-    evidence that the client has connected.  
+    evidence that the client has connected.
 
     (12761|1024) select timed out
     (12761|1024) select timed out
diff --git a/ACE/performance-tests/SCTP/run_spectrum.config b/ACE/performance-tests/SCTP/run_spectrum.config
index cb2beb17f5e..ca9a8968ac9 100644
--- a/ACE/performance-tests/SCTP/run_spectrum.config
+++ b/ACE/performance-tests/SCTP/run_spectrum.config
@@ -1,6 +1,3 @@
-#
-# $Id$
-#
 # This is the default configuration file for run_spectrum.pl.
 # Configuration options given in this file will be passed to
 # SOCK_STREAM_clt or SOCK_SEQPACK_clt.