home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / PROTOCOL / TPHYD100.ZIP / README.DOC < prev   
Text File  |  1993-11-29  |  6KB  |  117 lines
  1.  
  2.     This is TP-Hydra 1.00, a Turbo Pascal 6.0 implementation of the
  3.     Hydra bidirectional file transfer protocol.
  4.     It is a port from the Hydracom 1.08 C sources by Adam Blake of
  5.     Wandoo Valley Software (Comunique terminal package) and Arjen Lentz
  6.     of LENTZ SOFTWARE-DEVELOPMENT (Hydra co-design and HydraCom).
  7.  
  8.     I (AGL) specifically participated in this effort to provide a
  9.     freely available Pascal source of Hydra, aiding further integration
  10.     of the protocol in programs.
  11.     The stuff works, and was used in the Communique 2.10 release which
  12.     supports Hydra internally.
  13.  
  14.     So, here we are....
  15.  
  16.  
  17.  
  18.     Couple of things you have to know when including Hydra in your own
  19.     program:
  20.  
  21.     The buffers are NEVER flushed or cleared, not even if errors occur.
  22.     Only for an abort, just before the cancel sequence is sent.
  23.  
  24.     New data packets are only put in the transmit buffer if there are
  25.     less bytes in that buffer than the maximum block length. This will
  26.     keep the transmit buffer always full enough, but leave the Hydra
  27.     code free to process incoming data.
  28.  
  29.     To enable maximum throughput without losing characters or slowing
  30.     down transmission, FORCE your program to use async buffers with a
  31.     minimum size of 4096 bytes each.
  32.     Of course you can't directly set the size of those buffers if you
  33.     use a FOSSIL driver. That's why The-Box Mailer and HydraCom call
  34.     the FOSSIL information function, and print a warning message if
  35.     either of the buffers is less than 4095 (yes 4095, the OS/2 VX00
  36.     reports 4095 instead of 4096 ;-)
  37.     Please don't argue, just do it. Alll this has been tried & tested.
  38.     Larger buffers are  okidoki, but generally will not improve
  39.     performance of either transfer direction....
  40.  
  41.     Depending on the system, you may need to lower RTS during disk
  42.     access to prevent losing incoming data. DOS keeps interrupts
  43.     disabled rather (too) long....
  44.     X00 and VX00 have extended FOSSIL functions supporting this.
  45.     If you use your own async stuff, make sure they can do it too.
  46.  
  47.     A general note, important not just for Hydra:
  48.     Add timers to your lowlevel byte/block transmit functions, and
  49.     the flush output buffer routine.
  50.     Some (mail)sessions have been observed to just die, while the
  51.     program stays online. Carrier is still present, and braindead
  52.     timers in the highlevel code don't go off because the program
  53.     is stuck in a lower level, waiting for some bytes to be passed
  54.     to the FOSSIL or async code.
  55.     This can happen because of hardware handshake problems, modem
  56.     retraining, whatever. In any case, it happens....
  57.     So it's in that lowlevel code that you need to add your timeout;
  58.     something in the order of a minute will do fine. No need to pass
  59.     back an error code, your high level timers should take care of
  60.     the rest.
  61.  
  62.  
  63.  
  64.     HYDRA in FidoNet technology mailers
  65.  
  66.     HYDRA is suitable for use in FidoNet mailers. It can be implemented
  67.     for EMSI and FTS-6 mail sessions. The FTS-6 (YooHoo) capability bit
  68.     for HYDRA is 0x0020 (DOES_HYDRA). The EMSI and IEMSI protocol
  69.     capability flag is HYD.
  70.  
  71.     When utilizing HYDRA in a mail session, two complete batches are
  72.     always performed. Little else differs from a normal FTS-6 ZedZap mail
  73.     session. The first batch is used to transmit all mail, files, and
  74.     file requests by both sides. The second batch is always performed,
  75.     sending nothing if there are no file requests to honor. The data
  76.     buffers are not purged between the two batches since HYDRA ignores
  77.     any leftovers from the previous batch (END packets, etc.).
  78.  
  79.     To integrate HYDRA into an existing mailer, the same code used for
  80.     the ZedZap session flow can be used, but instead of one transmit and
  81.     one receive session, two transmit sessions (or batches) are used.
  82.     When the HYDRA end of batch is initiated it will not be terminated
  83.     until an end of batch has been received from the remote and the end
  84.     of session sequence has been finished.
  85.  
  86.  
  87.  
  88.     Adam is moving from Luxembourg back to Australia, so unfortunately
  89.     he can't help with any questions....
  90.     For help, please use the worldwide HYDRADEV echomail conference, or
  91.     contact me directly by NetMail. I never use Pascal myself so a msg
  92.     in the echo will probably get you your information faster.
  93.     Of course, regarding the protocol and mailer implementation, I can
  94.     tell you everything you want to know ;-)
  95.     Refer to HYDRA.DOC (HYDRA001.ZIP and FSC-0072.A01) for the original
  96.     Hydra specs....
  97.  
  98.     Do read LICENSE.DOC before you grab the sources, and don't forget
  99.     to mention what needs to be mentioned in your docs and (C) screens.
  100.  
  101.     Well, have fun, and integrate Hydra into your software soon!
  102.     Please don't wait for someone else to do it first?
  103.     This stuff was sent directly to developers of mailer, BBS and
  104.     terminal software, those who were already aware of this source
  105.     becoming available and in fact eagerly waiting for it.
  106.     Won't tell you who they are to give them a fair chance of working
  107.     on their programs without being harrassed about when they will
  108.     release something with Hydra, but.... they are some biggies ;-)
  109.     Better you hurry up too!
  110.  
  111.     Arjen Lentz
  112.     FidoNet 2:283/512
  113.     BBS/FAX +31-33-633916
  114.     arjen_lentz@f512.n283.z2.fidonet.org
  115.  
  116.     --- end of "readme.doc" ---
  117.