home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / PPPBCKP / SRC / SRC15B91.ZIP / WATTSRC.ZIP / README.2ND < prev   
Text File  |  1996-09-24  |  19KB  |  441 lines
  1. If you are programming with the Waterloo TCP library, the following notes
  2. may prove helpful.
  3.  
  4. General Changes                     (through 9/24/96)
  5.  
  6.     Should compile with no warnings under BCC 3.1 at the default
  7.     warning level.  Made to compile under BCC 4.x, and there will
  8.     be a couple 'obsolete function' warnings that you can ignore;
  9.     more recent versions of BCC may work also but I don't have
  10.     them to try.
  11.     
  12.     A bootp bug fixed.  TCP send window's failure to open possibly
  13.     fixed (caused slow writes), but not positive it's correct.
  14.     
  15.     Quentin Smart's (smart@actrix.gen.nz) de-fragment code is in here
  16.     now.   Since the ethernet packet buffers and UDP data buffer (in
  17.     the socket structure) are only 2K, that's the max datagram size the
  18.     fragment code can defrag, but you can increase the size of
  19.     the socket data buffer in wattcp.h (see tcp_MaxBufSize, a misnomer
  20.     since it's used to size UDP buffers to) and you'll also need to
  21.     increase the size of the packet buffers (BUFSIZE) in pcpkt.c.
  22.     You might consider using a datahandler function then the
  23.     buffer in the UDP socket structure isn't used; you can
  24.     probably save a memory copy anyway that way.  Also I don't think
  25.     the defrag code checks to see if the total packet size will
  26.     overflow the packet receive buffers, but I don't recall for sure;
  27.     that's something that should be done if it's not.
  28.  
  29.     Murf@perftech.com and I also contributed some fixes to Quentin's
  30.     code, though I think Erick may have taken credit for the bugs
  31.     when merging and altering the code Quentin provided ;-).
  32.  
  33.     I've also added code to *send* fragmented UDP packets so
  34.     you're not limited to ~1460 bytes.  I used the _mss value to
  35.     decide splits though we should really use something independent
  36.     of the tcp constants (I'm lazy).  Also this does *not* work with
  37.     sock_fastwrite().  This code probably needs a little more work
  38.     to be ideal, but it basically works. (It has been in previous releases).
  39.  
  40.     There might be some other bug fixes in here that I've forgotten.
  41.     If you're a forgotten contributor, please let us know so you
  42.     can get credit here.
  43.  
  44.     And finally, I'm not taking over WatTCP; Erick is still the guy.
  45.     I just made him promise to put release versions or dates in the
  46.     WatTCP filenames; but note that the current naming convention
  47.     (WATyymm.zip) suffers from the year 2000 problem... oh dear.
  48.  
  49.                 -- Mike Durkin (mdurkin@tsoft.net)
  50.  
  51. - - -
  52. General Changes                     (7/16/93)
  53.     I did a lot of cleaning up to make this compile more nicely and
  54.     more than a year's worth of bugs have been fixed.
  55.  
  56.     Several areas underwent protocol optimization to significantly
  57.     improve performance under certain circumstances.  Noticable
  58.     enhancements include SLIP support and fragments reassembly, but
  59.     the latter is currently disabled as I introduced a bug.
  60.  
  61. - - -
  62. General Changes                     (3/31/92)
  63.     This update has a lot of little bug fixes, optimizations and
  64.     general improvements thanks to a lot of people's input.  In
  65.     particular, Jason Dent and Graham Robinson (author of PKTMUX10).
  66.  
  67. 1. Push bit handling is improved.  This is mostly necessary for 3270
  68.    protocols, most others treat tcp as a simple binary stream.
  69.  
  70. 2. Zero window probing has been fixed.  This will keep things rolling
  71.    even when the remote machine is swamped and the network becomes lossy
  72.    around the same time.
  73.  
  74. 3. A bug in the ASCII tcp stuff was introduced on my site this month
  75.    and has been fixed.  I don't know if the bug was on my old distribution.
  76.  
  77. 4. Significant changes were made to the internal handling of acknowledgements
  78.    and handling data within the receive window.
  79.  
  80. 5. A bug used to annoy SCO and possibly other system consoles - fixed.
  81.    When WATTCP wished to refuse unwanted sessions from remote systems, it
  82.    would be missing a small flag.  Most tcp's didn't notice this flaw.
  83.  
  84. 6. Type of Service flag now RFC compliant - currently unused in non-military
  85.    installations, this flag could be used to set priorities for TELNET
  86.    sessions versus bulk data transfers like FTP, particularly over slow
  87.    lines.  Phil Karn (Mr. KA9Q) is currently researching this area and
  88.    so this upgrade should make WATTCP code react properly (unlike SunOS, BSD,
  89.    etc.) in sites which use his TCPs.
  90.  
  91. Erick
  92.  
  93. - - -
  94. Speed/Performance               (1/04/1992)
  95.  
  96.     The tcp code has undergone some mods to make it much faster, with
  97.     reads up to 120 kilobytes/s and writes up to 42 kilobytes/s on the
  98.     same subnet as my Sun.
  99.  
  100.     These speed were great, but my pc is usually on a subnet.  There, the
  101.     speeds were about 26 kB/s in writes and 70 kB/s in reads.
  102.  
  103.     For read's I was able to use good old sock_fastread.  For writes,
  104.     sock_fastwrite / sock_write just don't cut it because they are limited
  105.     to the small buffer size located in the tcp_Socket structure.
  106.  
  107.     I've added a new call which let's you get around that limitation,
  108.     sock_enqueue().  This new routine let's you specify a buffer of data
  109.     you wish to enqueue for transmission.  WATTCP records the address of
  110.     that buffer and its length, and starts to transmit it according to
  111.     the TCP rules.  You are not allowed to touch that buffer until all
  112.     the data is fully transmitted, something you can tell by using the
  113.     sock_tbused( s ) until it returns zero.  You must also keep calling
  114.     tcp_tick() or sock_tick() as those routines schedule transmissions.
  115.  
  116.  
  117.     Here is some sample code which writes out a disk file:
  118.  
  119.     tcp_open...
  120.     f->dhanle = open( ....
  121.     ...
  122.     while ( 1 ) {
  123.         /* check connection and do background stuff */
  124.         if (tcp_tick( s ) == 0) break;
  125.  
  126.         /* see if we can schedule more data */
  127.         if ( sock_tbused( s ) == 0 ){
  128.             printf("disk reading %u bytes\n", ftpdbufferlen );
  129.             if ((diff = read( f->dhandle, ftpdbuffer, ftpdbufferlen )) <= 0 ) {
  130.                 /* eof or possibly error condition */
  131.                 break;
  132.             } else {
  133.                 /* data ready to send */
  134.                 sock_enqueue( s, ftpdbuffer, diff );
  135.             }
  136.         }
  137.     }
  138.  
  139.     close( f->dhandle );
  140.     sock_close( s );
  141. - - -
  142. SMTPSERV  (in separate file: SMTPSERV.ZIP)
  143.  
  144.     This program accepts inbound mail and places it into mail spool files
  145.     almost identically to the way Phil Karn's NOS does.  You can download the
  146.     executable in pub/wattcp/smtpserv.zip.  If you find it useful or wish
  147.     to have it changed, let me know.
  148.  
  149. -----------------------------------------------------------------------------
  150.  
  151. Large Model                     (9/13/1991)
  152.     You can compile large or small model applications.  Check out the
  153.     MAKEFILE in the .\APPS subdirectory to see how easy it is to switch.
  154.  
  155.     The fullsrc.zip collection automatically produces large and small
  156.     model libraries.
  157.  
  158.     There is a potential problem when you compile applications because
  159.     you make the same mistake I did and place tcp_Socket on the stack
  160.     by declaring it an automatic variable.  The 'C' stack is normally
  161.     only four K, slightly less than the tcp_Socket structure.
  162.  
  163.     I didn't figure this one out very quickly, so tcp_open, udp_open,
  164.     and tcp_listen have code to warn you immediately and exit in case
  165.     you forget.
  166.  
  167. -----------------------------------------------------------------------------
  168.  
  169. TCP Fixes                       (9/13/1991)
  170.      The TCP portion of WATTCP has had numerous improvements.  I've managed
  171.      to significantly reduce the packet count while improving performance
  172.      and reliability.
  173.  
  174. -----------------------------------------------------------------------------
  175.  
  176. New Wattcp Programs
  177.      The latest release of MS-Kermit includes the WATTCP kernel, letting you
  178.      use it as a TELNET program.  I do not know where the ftp site is,
  179.      but it will probably be announced soon on Comp.protocols.tcp-ip.ibmpc
  180.      in the near future.
  181.  
  182.      LPD is a line printer server which will let a PC accept jobs from UNIX.
  183.      It offers some simple device restriction capabilities.  You can spool
  184.      jobs out any DOS file or device.  It requires a little few lines
  185.      of work to be used at any site other than mine.  It is available
  186.  
  187.      COMD.EXE is a simple program can be used to allow network access to
  188.      RS232 devices.  With a little work it could be converted into a modem
  189.      pool.  It is available from [129.97.128.196] pub/wattcp/comd.zip.
  190.  
  191.      If you have any improvements or new applications, please let me know.
  192.      I will gladly distribute them for you.
  193.  
  194. -----------------------------------------------------------------------------
  195.  
  196. Nested Config Files             (7/16/91)
  197.     Wattcp config files may be easily nested to allow for centralized
  198.     control of most parameters with local overrides, or user specific
  199.     extensions.
  200.  
  201.     To include a nested config file, use the following line in the
  202.     main config file:
  203.  
  204.         include = filename
  205.     eg. include = c:\local.cfg
  206.  
  207.     If the local file could not be found, a warning message is displayed.
  208.     You may wish to use a local file if it exists, but not display a message
  209.     if it does not.  To do that, simply prepend the filename with a question
  210.     mark.
  211.  
  212.     eg. include = ?c:\local.cfg
  213.  
  214.     When the nested file is complete it will return to the main file.
  215.  
  216.     The nesting limit is dependant upon the number of unused file handles
  217.     and the stack size.
  218.  
  219. -----------------------------------------------------------------------------
  220.  
  221. TCP/UDP Packet Dumps            (7/10/1991)
  222.     TCP/UDP packet dumping features have been added and may prove useful
  223.     for testing and debugging your applications.
  224.  
  225.     The debugger dumps packets, which gives you a feel for what the
  226.     kernal and the other end are trying to do.
  227.  
  228.     It's my job to try to make things go as fast as possible with as
  229.     few packets as possible (least load).  Actually, when you use the
  230.     dumping feature you usually INCREASE the packet count because the
  231.     dumper takes time which times out the scheduler and causes
  232.     retransmits.
  233.  
  234.     To include the debugging features in your program, add the line
  235.         dbuginit();
  236.     to your program *before* you call sock_init();
  237.  
  238.     To enable/disable the debugger, include the following lines in your
  239.     WATTCP.CFG file:
  240.         DEBUG.FILE=somename     # otherwise it will open a file called
  241.                                 # WATTCP.DBG in the current subdirectory
  242.                                 # somename could be con which will dump
  243.                                 # to the screen
  244.         DEBUG.MODE=DUMP         # to dump TCP/UDP data, looks a bit like
  245.                                 # DEBUG.COM
  246.    or   DEBUG.MODE=HEADERS      # to dump TCP/UDP headers
  247.    or   DEBUG.MODE=ALL          # to dump everything, headers and data
  248.  
  249.    You may write some textual data directly to the file.  Remember, you
  250.    must send a 'C' string ending with a 0, and you must include your
  251.    own CRLFs.
  252.  
  253.         db_write( char *msg );
  254.  
  255.    NOTE: If you use this feature and you also use usr_init, you
  256.          must chain usr_init as described in the programmers manual,
  257.          and as show in TCPINFO.C.
  258.  
  259. -----------------------------------------------------------------------------
  260. Good UDP Support                (6/5/1991)
  261.    Initially, only standard socket calls could be used for UDP.  That was kind
  262.    of shabby because UDP tends to be higher traffic, has no flow control, and
  263.    you wish to know record boundaries.
  264.  
  265.    The new code allows you to declare a big buffer into which the incomming
  266.    UDP packets will be bufferred.  Once initialized with sock_recv_init, the
  267.    buffer is used until the socket is closed.  NOTE: sock_recv... and the
  268.    regular socket input routines are MUTUALLY EXCLUSIVE, you can not use
  269.    one and the other at the same time.  
  270.  
  271.         byte bigbuf[ 8192 ];
  272.         byte smallbuf[ 512 ];
  273.         int templen;
  274.  
  275.         if ( !udp_open( &data, localport, remote, remoteport, NULL) ) {
  276.             printf("Error opening UDP channel");
  277.             exit( 3 );
  278.         }
  279.         /* set the big buffer */
  280.         if ( sock_recv_init( &data, bigbuf, sizeof( bigbuf )) == -1 ) {
  281.             printf("Error setting the receive buffers");
  282.             exit( 3 );
  283.         }
  284.         while ( 1 ) {
  285.             tcp_tick( NULL );           /* got to do this or sock_tick */
  286.  
  287.             /* check for incomming udp data */
  288.             if ( templen = sock_recv( &data, smallbuf, sizeof( smallbuf ))) {
  289.                 /* something received and it was templen bytes long */
  290.             }
  291.         }
  292.         sock_Close( &data );
  293.  
  294.    sock_recv... adds extra code, so it need not be used for simple UDP sockets
  295.    such as BOOTP which expects only a single packet.
  296.  
  297.    See sock_mode checksums below for more interesting notes.
  298.  
  299. -----------------------------------------------------------------------------
  300. UDP Checksums                   (6/5/1991)
  301.    sock_mode can be used to enable or disable checksums for udp sessions
  302.    using the following calls:
  303.  
  304.         sock_mode( &socket, UDP_MODE_CHK );
  305.         sock_mode( &socket, UDP_MODE_NOCHK );
  306.  
  307.    Unlike *some* systems, Waterloo TCP correctly assumes checksums are active
  308.    and allows an application to disable them on the fly as they consider
  309.    appropriate.
  310.  
  311.    Either or both sides may disable or re-enable checksums.
  312.  
  313. -----------------------------------------------------------------------------
  314. TCP Nagle Algorithm             (6/5/1991)
  315.    The Nagle algorithm is now used to collect data.  Nagle is ideally suited
  316.    to programs like TELNET (TCPPORT), etc. which send a lot of small chunks
  317.    of data.  Some programs, like X-Windows, real-time data collection, etc.,
  318.    should turn of the Nagle feature.  Nagle is on by default and should not
  319.    be disabled unless a true problem is experienced.
  320.  
  321.         sock_mode( &socket, TCP_MODE_NONAGLE ); /* turns it off */
  322.         sock_mode( &socket, TCP_MODE_NAGLE );   /* re-enables it */
  323.  
  324. -----------------------------------------------------------------------------
  325. getdomainname Changes           (6/5/1991)
  326.    getdomainname always took a string and length parameter, just like UNIX.
  327.    Now, if the length is zero, getdomainname just returns the pointer to
  328.    a system copy of the domainstring.
  329.  
  330. -----------------------------------------------------------------------------
  331. gethostname sethostname Changes (6/5/1991)
  332.    gethostname and sethostname are now available.  They work identically to
  333.    get/setdomainname() (as enhanced above).  The host name can either be set
  334.    via the WATTCP.CFG file or via bootp.
  335. -----------------------------------------------------------------------------
  336.  
  337. sock_PreRead addition           (4/26/1991)
  338.  
  339.    int sock_PreRead( void *s, byte *dp, int len );
  340.  
  341.    Some situations arise where it would be nice to read data without causing
  342.    it to disappear from the socket's buffer.  Usually that means double
  343.    buffering.  sock_PreRead works exactly like sock_FastRead, except it does
  344.    not remove the read data from the data buffers.  The returned value is the
  345.    number of bytes transferred, 0 for no data waiting, or -1 on a socket
  346.    error.
  347.  
  348.    This function is intended for special cases which are not easily performed
  349.    using other methods.
  350.  
  351. -----------------------------------------------------------------------------
  352.  
  353. sethostid addition              (4/26/1991)
  354.  
  355.    longword sethostid( longword ip );
  356.  
  357.    This function sets the system's default ip address.  Changing the ip address
  358.    will destroy existing TCP and UDP sessions.  You should close all sockets
  359.    before calling this function.  The passed ip address is always returned.
  360.  
  361.    This function is low level and rarely useful to an application programmer.
  362.  
  363.    main()
  364.    {
  365.        longword ip = 0x80010101;   /* 128.1.1.1 */
  366.        char buffer[ 512 ];
  367.  
  368.        sock_init();
  369.        sethostid( ip );
  370.        printf("IP address has been set to %s\n\r",
  371.            inet_ntoa( buffer, getipaddr() );
  372.    }
  373.  
  374. -----------------------------------------------------------------------------
  375.  
  376. setdomainname addition          (4/26/1991)
  377.  
  378.    char *setdomainname( char *string);
  379.  
  380.    The domain name returned by getdomainname and used for resolve() is set to
  381.    the value in the string passed to setdomainname().  Note that changing the
  382.    contents of the string after a setdomainname() call may or may not change
  383.    the value of the system domain string and is not recommended.  You are
  384.    recommended to dedicate a static location which will permanently hold that
  385.    name.
  386.  
  387.    setdomainname( NULL ) is an acceptable way to totally remove any domain name
  388.    and subsequently resolves will not attempt to append a domain name.
  389.  
  390.    The passed string is always returned, as demonstrated below.
  391.  
  392.    This function is low level and rarely useful to an application programmer.
  393.  
  394.    #include <stdio.h>
  395.    #include <tcp.h>
  396.    char buffer[ 512 ];  /* use a static or a calloc, do not place the name
  397.                            in a local variable on the stack, it may get lost! */
  398.    main()
  399.    {
  400.        sock_init();
  401.        puts("Enter a new domain");
  402.        gets( buffer );
  403.        printf("Was using %s\n\r", getdomainname());
  404.        printf("Now using %s\n\r", setdomainname( buffer ));
  405.  
  406.        setdomainname( NULL );
  407.        puts("Now using no domain name");
  408.    }
  409.  
  410. -----------------------------------------------------------------------------
  411.  
  412. _arp_resolve addition           (4/26/1991)
  413.  
  414.    _arp_resolve( longword ina, void *ethap)
  415.  
  416.    Given an ip address (ina), find the hardware address.  If ethap is non-NULL,
  417.    place the hardware address in the buffer pointed to by ethap.
  418.  
  419.    Each call to _arp_resolve checks a local cache to see if we already know
  420.    the hardware address.  If no entry exists for that IP address, steps
  421.    are taken to find a hardware address.  If the ip node is on our subnet,
  422.    an ARP request is broadcast, otherwise _arp_resolve is called recursively
  423.    to find the address to the gateway.
  424.  
  425.    Socket opens intrinsically call _arp_resolve and place the hardware address
  426.    in the socket structure so they are no longer dependant upon existance in
  427.    the cache.  This means existing tcp and udp sessions do not automatically
  428.    reconfigure if a new route is found to the remote host, but this is typical
  429.    of pc implementations and is quite reasonable.
  430.  
  431.    Programs which wish to force the hardware address to be in the arp cache
  432.    need only specify the ip address and NULL for the ethap buffer.
  433.  
  434.    Returns 1 on success or 0 if the ip address could not be resolved.
  435.  
  436.    This is a special use function and is rarely necessary for user
  437.    applications.
  438.  
  439. -----------------------------------------------------------------------------
  440.  
  441.