Suzie

home *** CD-ROM | disk | FTP | other *** search

/ Suzie / Suzie.iso / ft21$$$$.tmp / hydracom / hydracom.doc < prev next >

Wrap

Text File | 1994-10-13 | 67.1 KB | 2,078 lines

HydraCom Version 1.00 A sample implementation of the HYDRA Bi-Directional File Transfer Protocol HydraCom was written by Arjen G. Lentz, LENTZ SOFTWARE-DEVELOPMENT COPYRIGHT (C) 1991-1993; ALL RIGHTS RESERVED The HYDRA protocol was designed by Arjen G. Lentz, LENTZ SOFTWARE-DEVELOPMENT and Joaquim H. Homrighausen COPYRIGHT (C) 1991-1993; ALL RIGHTS RESERVED Blank page HydraCom Blank page HydraCom HydraCom Table of contents Page i 1 General Information . . . . . . . . . . . . . . . . . . . . 1 1.1 Protocol information . . . . . . . . . . . . . . . . 1 1.2 Program description . . . . . . . . . . . . . . . . 1 1.3 Program features . . . . . . . . . . . . . . . . . . 2 1.4 System hard- and software requirements . . . . . . . 2 1.5 Disclaimer . . . . . . . . . . . . . . . . . . . . . 2 1.6 HydraCom / source license . . . . . . . . . . . . . 3 1.7 Hydra protocol license . . . . . . . . . . . . . . . 4 1.8 Credits . . . . . . . . . . . . . . . . . . . . . . 5 1.9 Acknowledgements . . . . . . . . . . . . . . . . . . 5 1.10 Hydra in other software (also FidoNet mailers!) . . 5 1.11 Other environments/operating systems . . . . . . . . 5 1.12 Where to send your spare funds . . . . . . . . . . . 6 1.13 Support and contact addresses . . . . . . . . . . . . 6 2 Description of specific features . . . . . . . . . . . . . . 7 2.1 Split screen chat during a Hydra session . . . . . . 7 2.2 Resuming aborted transfers . . . . . . . . . . . . . 7 2.3 Networks and Multitaskers . . . . . . . . . . . . . 7 2.4 Using a FOSSIL driver . . . . . . . . . . . . . . . 9 2.5 Using a Video FOSSIL . . . . . . . . . . . . . . . . 9 2.6 AutoStart Hydra transfers . . . . . . . . . . . . . 10 2.7 Aborting a Hydra transfer . . . . . . . . . . . . . 10 2.8 Configuration utility HydraCfg . . . . . . . . . . . 10 2.9 Reliability . . . . . . . . . . . . . . . . . . . . 11 2.10 Protocol performance . . . . . . . . . . . . . . . . 11 2.11 HST and other half-duplex links . . . . . . . . . . 12 3 Commands and Options . . . . . . . . . . . . . . . . . . . . 13 3.1 Options . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1 port N . . . . . . . . . . . . . . . . . . . . . 14 3.1.2 speed N . . . . . . . . . . . . . . . . . . . . 14 3.1.3 line N . . . . . . . . . . . . . . . . . . . . . 14 3.1.4 parity . . . . . . . . . . . . . . . . . . . . . 15 3.1.5 dropdtr . . . . . . . . . . . . . . . . . . . . 15 3.1.6 nocarrier . . . . . . . . . . . . . . . . . . . 15 3.1.7 noinit . . . . . . . . . . . . . . . . . . . . . 15 3.1.8 handshake <flg> . . . . . . . . . . . . . . . . 15 3.1.9 log <file> . . . . . . . . . . . . . . . . . . . 15 3.1.10 level <loglevel> . . . . . . . . . . . . . . . . 16 3.1.11 result <filename> (DSZ logfile) . . . . . . . . 16 3.1.12 noresume . . . . . . . . . . . . . . . . . . . . 16 3.1.13 nostamp . . . . . . . . . . . . . . . . . . . . 17 3.1.14 receive <path> . . . . . . . . . . . . . . . . . 17 3.1.15 nobell . . . . . . . . . . . . . . . . . . . . . 17 3.1.16 mailer . . . . . . . . . . . . . . . . . . . . . 17 3.1.17 nooriginator . . . . . . . . . . . . . . . . . . 17 3.1.18 hdxlink . . . . . . . . . . . . . . . . . . . . 17 3.1.19 txwindow N . . . . . . . . . . . . . . . . . . . 18 3.1.20 rxwindow N . . . . . . . . . . . . . . . . . . . 18 3.1.21 link options . . . . . . . . . . . . . . . . . . 18 3.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1 send [<filespec> ...] [@<ctlfile> ...] . . . . . 19 HydraCom Page i Page ii Table of contents (continued) HydraCom 3.2.2 get [<path>[<name>]] . . . . . . . . . . . . . . 20 3.2.3 term . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Default configuration file . . . . . . . . . . . . . . . 21 4 Using HydraCom as an external protocol . . . . . . . . . . . 22 4.1 Interface methods . . . . . . . . . . . . . . . . . . . 22 4.1.1 Opus-style external protocol interface . . . . . 22 4.1.2 DSZ-style external protocol interface . . . . . 23 4.1.3 Exit codes (errorlevels) . . . . . . . . . . . . 23 4.2 Using HydraCom with terminal programs . . . . . . . . . 24 4.2.1 Telix . . . . . . . . . . . . . . . . . . . . . 24 4.2.2 Communique . . . . . . . . . . . . . . . . . . 24 4.2.3 Commo . . . . . . . . . . . . . . . . . . . . . 25 4.2.4 Procomm Plus . . . . . . . . . . . . . . . . . . 25 4.2.5 TeleMate . . . . . . . . . . . . . . . . . . . . 26 4.2.6 Boyan . . . . . . . . . . . . . . . . . . . . . 26 4.2.7 Qmodem . . . . . . . . . . . . . . . . . . . . . 27 4.3 Using HydraCom with BBS software . . . . . . . . . . . . 28 4.3.1 Maximus . . . . . . . . . . . . . . . . . . . . 28 4.3.2 Opus . . . . . . . . . . . . . . . . . . . . . . 28 4.3.3 QuickBBS and RemoteAccess (FileDoor) . . . . . . 29 4.3.4 RBBS-PC . . . . . . . . . . . . . . . . . . . . 29 4.3.5 Wildcat! . . . . . . . . . . . . . . . . . . . . 29 4.3.6 XBBS . . . . . . . . . . . . . . . . . . . . . . 31 Page ii HydraCom HydraCom Page 1 1 General Information 1.1 Protocol information Full specifications of the Hydra protocol as well as the HydraCom sources (in C) are freely available. Developers may use either or both to implement Hydra into their own software, port Hydra to other machines and operating environments, etc. The packages containing these files have been widely distributed, but will always be available from the authors' own systems. Please refer to the license and other important information further along this document. 1.2 Program description HydraCom is a stand-alone driver which implements the Hydra bidirectional file transfer protocol developed by Arjen Lentz and Joaquim Homrighausen. HydraCom provides a service for communications programs which do not (yet) have with Hydra support internally. HydraCom can be installed as an external transfer protocol driver like other external drivers. HydraCom also provides a simple terminal function. Because HydraCom's sources are available, they can also serve as a sample implementation of the Hydra protocol for other developers to take a look at. HydraCom Page 1 Page 2 HydraCom 1.3 Program features - Simultanous bidirectional file transfer - Split screen chat during Hydra session, without line noise - Comprehensive manual for installation and advanced features - Program source code and protocol specification freely available - Stand alone or external call from any BBS or terminal software - Compatible with both Opus and DSZ style interfacing - Hydra (and HydraCom) can be used in FidoNet Technology Mailers - Userfriendly full-screen setup utility HydraCfg, mouse supported - Good stability on bad connections, speedy error recovery - Safe protocol, no deadlocks or misunderstandings - Tolerance towards network and satellite delays - Handles 7-bit or even less transparent connections - Seperate escaping options for Telenet, XON/XOFF, 7bit, etc - Maximum performance without ever compromising reliability - All packets (including chat packets) protected by CCITT CRC-32 - Retain file's original size and date/time - Automatic startup with special character sequence (AutoStart) - Resume aborted transfers without unfinished files floating about - Numerous transfer options for sysop and users - Supports FOSSIL and VideoFOSSIL - Internal communication routines supporting 16550 UART - Hardware and software flow control - Shared file open for network operation - Internal small terminal with ANSI/VT100 emulation and AutoStart - Fast screen writes, DESQview aware - Releases spare CPU time to DESQview or DOS 1.4 System hard- and software requirements - IBM XT, XT286, AT286, 386, 486, PS/2 or clone/compatible computers. - MS, PC or compatible DOS version 3.00 or higher. - About 128K of free memory space. - HydraCom is able to operate with certain non IBM-compatible serial hardware, provided a suitable FOSSIL and perhaps video FOSSIL driver is installed. There are various FOSSIL drivers available for true compatibles, like Opus!Comm, X00 and BNU, but also for the Tandy 2000, Heath Zenith, DEC Rainbow, Philips :YES and many others. Some of those are implemented as TSR (Terminate and Stay Resident) programs, others (like X00.SYS and BNU.SYS) as device drivers.In addition, use of a Video FOSSIL is supported. 1.5 Disclaimer This program is provided "as is" and comes with no warranties of any kind, either expressed or implied. In no event shall the authors be liable to you or anyone else for any damages, including any lost profits, lost savings or other incidental or consequential damages arising out of the use or inability to use this software. Page 2 HydraCom HydraCom Page 3 1.6 HydraCom / source license HydraCom, its associated utilities (HydraCfg) and the HydraCom sourcecode may be freely distributed, copied and used, no fee charged. All files, executables and sourcecode remain the copyrighted property of Arjen G. Lentz and LENTZ SOFTWARE-DEVELOPMENT. The distribution archives should remain intact with no files removed or modified. For special purposes, it is allowed to repack the archives using a different compression system. HydraCom may be bundled up with for instance terminal or BBS packages, even commercial ones, provided the buyer/user is clearly informed about the fact that Hydra and HydraCom are free, not owned by the distributor/retailer in question, and is not included in any possible charge regarding the rest of the package. This documentation must also be present so the user can inform himself about Hydra and HydraCom. The same rules apply to inclusion in shareware and CD-ROM libraries. In all cases, the author of HydraCom must be given credit in any informational screens and literature that contain such information. The Hydra/HydraCom sourcecode may also be freely used and integrated into other software or library, provided this is clearly stated in any informational screens and literature pertaining to this program, and credit is given to the original author. If the sourcecode of that program or library is released or otherwise published, the notices present at the top of every Hydra/HydraCom source file must be retained in their original unmodified form. In addition to the above license, everyone using any part of the sourcecode, programs or files is fully bound by the general license of the Hydra protocol as present in the Hydra protocol description document. For easy reference, the paragraph in question is reprinted below. Any use of, or operation on (including copying/distributing) any of the above mentioned files implies full and unconditional acceptance of this license and disclaimer. HydraCom Page 3 Page 4 HydraCom 1.7 Hydra protocol license You are granted a license to implement the HYDRA file transfer protocol, HYDRA hereafter, in your own programs and/or use the sample source code and adapt these to your particular situation and needs; subject to the following conditions: - You must refer to it as the HYDRA file transfer protocol, and you must give credit to the authors of HYDRA in any information screens or literature pertaining to your programs that contains other such information (credits, your own copyrights, etc.). - HYDRA will always remain backwards compatible with previous revisions. HYDRA allows for expansion of its features without interfering with previous revisions. It is, however, important that different people do not expand the protocol in different directions. We therefore ask you to contact us if you have any needs/ideas regarding HYDRA, so development can be synchronized and beneficial to all. - If your implementation cannot converse with past or future revisions as supplied by us, then you must refer to it as "HYDRA derived", or as "a variation of HYDRA", or words to that effect. Page 4 HydraCom HydraCom Page 5 1.8 Credits Zygimantas Cepaitis, Jan Stozek, Jac Kersing, Joaquim Homrighausen, Jeroen van Drie, Martin Cleaver, Henk Wevers, Jan Bredenbeek, Ron van der Nagel, and all other equally friendly creatures of the universe and cyberspace are hereby saluted in gratitude for their diverse efforts regarding the Hydra protocol and this software. HYDRA was designed by Arjen G. Lentz, LENTZ SOFTWARE-DEVELOPMENT, and Joaquim H. Homrighausen. 1.9 Acknowledgements - IBM PC, XT, AT, PS/2 and PC-DOS are trademarks of International Business Machines Inc. - MS-DOS is a registered trademark of Microsoft Corporation. - All other brand and product names are trademarks or registered trademarks of their respective holders. 1.10 Hydra in other software (also FidoNet mailers!) It's simple, nag the author of that software and give him this package with all the information. There is not a single reason for the developer in question not to integrate the Hydra protocol in his/her software. It will even add to its value. And if they don't do it now, they'll have to later after the competition has done it... A number of FidoNet technology mailers offer Hydra as their primary protocol. Please refer to the HYDRA specifications for detailed information about HYDRA in FTS-0006 (YooHoo) and EMSI mailsessions. 1.11 Other environments/operating systems Ports of a Hydra source (or a new implementation) to other platforms and operating systems are strongly encouraged. Because of the protocol's extreme flexibility Hydra may run on machines with the most severe restrictions where other protocols could never work. Please send us a note if you've implemented or ported Hydra, so we can keep track of its progress accross the different platforms in cyberspace. If you can send us sources or executables, even better. We will try to maintain a library of all this stuff. HydraCom Page 5 Page 6 HydraCom 1.12 Where to send your spare funds The HydraCom executable and full sourcecode have been made available free of charge in order to aid rapid distribution, acceptance and integration of this new protocol in existing and new libraries, terminal, BBS and other software, and the like. However, a donation recognizing my work would be very much appreciated, especially if you are making money of it yourself. Such donations will be used specifically on small practical datacommunications projects and investments in Eastern Europe I am involved in, at this moment particularly in Lithuania. Unless you don't want it, your name will be listed in a support file. If you contact me at the address below before sending a donation, I may be able to provide you with an address or account number in your vicinity rather than having you waste time, effort and money on international transfers. Any donation, however small, will thus be used purposefully for the good of communications in general. If because of Hydra you are making a lot of money off your Bulletin Board, library, software or distribution business, you may want to consider a larger or periodical donation. Thanks for your support! Arjen Lentz. 1.13 Support and contact addresses This software being free, there is no real support it. However, I will try to help you solving any problems if you ask nicely, and perhaps other users can be of assistance too. In FidoNet a HYDRA conference may be available near you for discussing the protocol and its implementations. Hydra and HydraCom were designed and written by: Arjen G. Lentz, LENTZ SOFTWARE-DEVELOPMENT Langegracht 7B, 3811 BT Amersfoort, The Netherlands AINEX-BBS +31-33-633916 (V.32BIS/V.42BIS/HST14k4) FidoNet node 2:283/512 (Arjen Lentz) Internet: arjen_lentz@f512.n283.z2.fidonet.org Hydra was designed in cooperation with: Joaquim H. Homrighausen 389, route d'Arlon L-8011 Strassen Luxembourg FidoNet 2:270/17 joho@ae.lu Page 6 HydraCom HydraCom Page 7 2 Description of specific features 2.1 Split screen chat during a Hydra session During a Hydra transfer you can chat with someone on the other side, and without that dreaded line noise! Just like all other packets, chat data is protected by CRC-32 and retransmitted when it doesn't come accross unscaved. Once a Hydra session is past the init state, you can start chat chat mode on your side by pressing Alt-C. A message is sent to the remote informing about this fact. You type in the bottom window, and any text from the remote appears in the upper window (split screen). Meanwhile you can still keep track of the file transfer progress at the op of the screen. The chat option does not effect protocol reliability. A Hydra session is prolonged even after all files have been sent/received, but only so long as both sides are active in chat mode. If one side quits, the session is then immediately finished. You can end chat mode on your side by pressing Alt-C again. If you type nothing in 60 seconds, chat mode is automatically ended. Hydra will inform you in your local window at what point it iss possible to start a chat mode. Similarly, informative messages about the chat facilities on the other side will appear in your remote window. During file transfer, chat text will appear in chunks. A smooth chat would serously degrade performance of the file transfers! Bulletin Board sysops may want to disable the bell noise of the chat facility with the 'nobell' option. Chat will still be available then, but without unwanted noise from the remote. 2.2 Resuming aborted transfers HydraCom does not allow such uncompleted files to float around on your disk, but rather renames the file to a unique file name and keeps a log with the original file-information of all interrupted transfers in that directory; this is an especially useful feature for BBS, because you can now enable bad-transfer recovery on upload without having to keep track of incomplete files. And for users it saves time because they do not have to transfer the complete file allover again, but only the part which was not yet transferred. This feature may be disabled with the 'noresume' option. 2.3 Networks and Multitaskers HydraCom opens files in shared mode so that it may be used in a multiline environment on LANs and under multitaskers such as DESQview. You just need to make sure any control files have different names (correct task number, in case of the Opus-interface). HydraCom Page 7 Page 8 HydraCom 2.4 Using a FOSSIL driver In addition to the internal serial communication routines the program can also make use of the popular FOSSIL interface, which enables less- compatible MS-DOS machines to run the same software without special modifications, just after loading another FOSSIL driver designed for that machine. The internal communication routines automatically detect and use FIFOs in the the 16550 UART, providing better throughput at high speed. A 16550 also decreases the chance of bytes getting lost (overrun). Also on some fully compatible machines a FOSSIL driver may give better results than the internal routines. Most BBS and point systems will usually already have a FOSSIL driver resident. For best results, set the FOSSIL receive and transmit buffers to at least 4KB (4096 bytes). HydraCom will complain if either or both are smaller, but the program will still function. Smaller buffers may cause more CPU time to be used, a lower transfer performance, and bytes may be lost causing transmission errors. 2.5 Using a Video FOSSIL The distributed executable HydraCom.EXE uses a windowing library which features fast direct screen access (DESQview aware), internal extended ANSI/VT-100 emulation for the terminal, and the capability to use a Video FOSSIL (like the VFOS_IBM/VFOS_BIO BinkleyTerm screen drivers by Bob Hartman). If you use a Video FOSSIL with HydraCom, make sure you have very recent version! Old versions of VFOS_IBM and VFOS_BIO have a bug in a couple of functions that the windowing library uses. BinkleyTerm does not use these functions, so you may not have noticed this problem before. Contact me for patched versions, or the corrected Video FOSSIL source files. All information HAS been forwarded to Bob Hartman. Note: when compiling the HydraCom sources yourself without modification, console I/O functions are used because the windowing library is not freely available. Contact me if you are interested in purchasing this library anyway (includes the complete sources in C and inline assembler). Page 8 HydraCom HydraCom Page 9 2.6 AutoStart Hydra transfers A Hydra session can be started automatically upon receipt of a special AutoStart sequence: ASCII: 24 99 65 92 102 53 92 97 51 24 97 Chars: Ctrl-X c A \ f 5 \ a 3 Ctrl-X a This is the Hydra START packet, which is always hex-encoded for clear passage through even the most restricted links. Before the START packet Hydra also transmits the letters 'hydra' in lowercase followed by a CR (ASCII 13), to start the Hydra protocol from for instance a Unix command line. To be certain the string is detected, strip the 8th bit of all incoming bytes and then ignore all ASCII characters 0-31 and 127 except ASCII 24 before comparing it to the next character in the autostart string. 2.7 Aborting a Hydra transfer A Hydra session may be aborted at any moment by pressing the Escape key. When your end is not engaged in a Hydra session but the other side is, typing at least 5 consequtive Ctrl-X will abort the remote Hydra. 2.8 Configuration utility HydraCfg To create and edit the default configuration of HydraCom, a utility HydraCfg is provided where all options and settings can be changed and checked in a user friendly full screen windowed environment. If a mouse driver is present, it may be used to move the cursor around and select options. When HydraCfg is called without commandline parameters, it searches for HydraCom.EXE first in the current then in all the directories listed in the DOS PATH. If found, and a file HydraCom.CFG is also present in that directory, that is the file that will be read and edited. If HydraCom.CFG doesn't yet exist, HydraCfg asks if you want to create it. If HydraCom.EXE is not found, a HydraCom.CFG may be created/edited in the current directory. You may also specify a full path/filename of a HydraCom.CFG style file on the HydraCfg command line, in which case no search is done. See the section about the default configuration file for more information. HydraCfg can provide additional information about options on the bottom line of the screen, if the file HydraCfg.HTX (helptext) is present in the same directory where HydraCom.EXE is located. HydraCom Page 9 Page 10 HydraCom 2.9 Reliability A remote machine may crash, jump out of a batch file or otherwise die on you while you are on-line. Hydra maintains a special braindead timer, aborting a session when there has been no REAL progress for two minutes. This may save you a lot of money when using Hydra in an automated environment, especially on international phonecalls! Other protocols have been known to keep a transatlantic line open for more than 6 hours with nothing happening.... big auch. The Hydra protocol has been designed in such a way that deadlocks or misunderstandings between the two sides cannot occur. Hydra is extremely tolerant towards network and satellite delays. If Hydra reports a 'timeout' or 'retry', this does not necessarily mean something terrible is happening. The protocol has a different design and therefore behaves differently from what you will be used to. If things go really wrong the transfer will be aborted anyway so there is no need to worry, the messages are just so you have some information about what is going on. For example, Hydra sometimes re-transmits a packet after a number of seconds, just in case the other side has missed it previously. Because of line delay the acknowledgement to the original packet may already be under way. In this case the duplicate packet is ignored, so the transfer is not delayed. If a packet does get lost, this alternative tactic speeds up recovery. 2.10 Protocol performance Contrary to the hype surrounding other protocols, Hydra does not pretend to be the fastest file transfer protocol in cyberspace. In general it is about as fast as the other top protocols, giving you a choice on grounds of reliability and versatility rather than outragious claims. Every protocol has a certain amount of overhead because of error detection and other facilities; this overhead has of course been minimized, but Hydra will not provide the user with options to increase performance in such a way that reliability is affected. This is what other protocols sometimes do, and often don't tell the user about it (nor of the consequences). Even so called 'errorfree connections' such as MNP and V.42 links are NOT 100% errorfree. Some errors slip through, and sometimes a byte gets lost or mangled between the modem and the computer or the communications routines. And to be fair, the actual gain in performance is always minimal; in rounded percentage terms it sounds appealing but in effect most claims amount to no more than about 10 seconds on a transfer of more than 10 minutes. Hardly worth it, wouldn't you agree? Page 10 HydraCom HydraCom Page 11 Some other bidirectional protocols add up the performance of the two directions, of course giving nice figures when comparing to unidirectional protocols. But this is really unfair. Hydra reports separate figures for each file transfered, and stays on the conservative side. You should not trust the performance ratings for transfers which last less than a minute! Okay.. you don't have to believe all this: ignore the numbers reported by the various protocols, and time a transfer yourself. Make sure you use a file large enough for at least 5 to 10 minutes transfertime, otherwise the results will not be reliable for comparison. And watch the behaviour of a protocol on for instance a bad connection; will it choke and abort or handle the situation well? 2.11 HST and other half-duplex links Hydra can also handle HST and similar links that have one high-speed channel and only a low-speed backchannel. Simultanous bidirectional transfer is not effective in this case, causing continuous line turnarounds and slowing down transmission dramatically. If you are a user, want call a BBS at HST speed, and upload and download in the same session, use the 'nooriginator' and 'hdxlink' options together. HydraCom will then first receive all files, then transmit. If you set the options even for other real full duplex connections like V.22(BIS) and V.32(BIS), HydraCom will not use its bidirectional capability then either. So use this only when required by the specific modem connect. In practise, it is easier if you just upload and download in a seperate Hydra session if you have an HST connect. Then there is no need to use these options at all. Bulletin Board sysops should NEVER set these options at all! The Hydra protocol is protected against deadlock; if both sides are in one-way transfer mode, this will be detected and one-way mode switched off. Of course, if you can choose between for instance an HST and a real full duplex connect, the choice is easy... full duplex every time! HydraCom Page 11 Page 12 HydraCom 3 Commands and Options Usage: HydraCom [port N] [speed N] [<options> ...] <command> [<parms> ...] General: options: port N Comport [1..16] (default COM1) speed N Com-speed [300..57600] (default current speed) line N Actual line speed (use 'speed' to set comport) parity Set 7E1 instead of 8N1 (forces option highbit) dropdtr Drop DTR if carrier is lost nocarrier Disable carrier detection noinit Don't init/deinit FOSSIL driver handshake <flg> Enable soft (XON/XOFF), hard (RTS/CTS) or both log <file> Logfile to log the goings on level N Level of logging, 0=max, 6=min (default=2) result <file> Log transfer info to DSZ compatible logfile noresume Disable receive bad-transfer recovery nostamp Don't stamp with original but current filetime receive <path> Path to store any received files nobell Disable bell noise in Hydra session chat feature link options: mailer Mailer mode, used by Dutchie (see documentation) nooriginator Not originator, fallback to one-way transfer allowed hdxlink Force one-way transfer mode (only with nooriginator) xwindow N Transmitter window size (default 0=full streaming) rxwindow N Receiver window size (default 0=full streaming) option xonxoff Escape/strip XON/XOFF characters option telenet Escape/strip Telenet escape option ctlchrs Escape/strip ASCII 0-31 and 127 option highctl Apply above three also for 8th bit option highbit Encode for 7 bit, strip 8th bit commands: send [<fspec> ...] Send <fspec>/@<ctlfile>/nothing + receive get [<path>[<name>]] Only get file(s), if name is specified, get first file (name override) and skip all others term Small terminal + send & AutoStart capability Page 12 HydraCom HydraCom Page 13 3.1 Options An option modifies the default settings of HydraCom, like the communications port number and speed of the communications port. Each option consists of a keyword, sometimes followed by a string or number. Keywords may be abbreviated to their first three letters. For example: POR 2 means that HydraCom should use com port 2. This is not true for any parameters following an option, these should all be fully spelled out. Case is not important. Invalid options and parameters are ignored. 3.1.1 port N Select the comport HydraCom will use, in the range of 1 to 16. The default value is COM1. The internal communication routines can only handle port COM1 to COM4 (3F8/IRQ4, 2F8/IRQ3, 3E8/IRQ4, 2E8/IRQ3). 3.1.2 speed N When using a FOSSIL driver, valid communication speeds are 300, 1200, 2400, 4800, 9600, 19200 and 38400 bits per second. With the internal async routines, any speed between 300 and 57600 BPS may be given. If the SPEED option is not specified, HydraCom will use the current speed of the port. Locking of the speed should be done in the FOSSIL setup, not in HydraCom. If the FOSSIL is locked the speed statement does not have any effect. 3.1.3 line N For high-speed modems, the SPEED option determines the speed of the comport while LINE determines the speed that will used for efficiency calculations, data packet size and timeouts. It is absolutely vital that HydraCom knows what speed the line has, and the program has no way of knowing unless you inform it! If the FOSSIL is not locked and the speed option is present, the line option need not be specified as well. The thresholds for data packet size and timeouts are at 1200, 2400, and 4800 bps. Ie. if speed is set to 38400 but the actual link speed is 14400, there's no need to use the line option as for HydraCom there is no practical difference between 14400 and 38400 when calculating the necessary figures. But if the comport is locked at 9600 or 38400 and the line speed is 2400 or even lower, you'll have problems if you don't specify the correct line speed here. HydraCom Page 13 Page 14 HydraCom 3.1.4 parity The parity option selects 7 databits, even parity (7E1) instead of the default 8 databits no parity (8N1), also forcing 'option highbit' so the Hydra protocol makes the necessary arrangements for a 7-bit connection. 3.1.5 dropdtr This option will probably only be useful for BBS with modems set to auto-answer. If specified, HydraCom will lower the DTR (Data Terminal Ready) line on the serial port. For HAYES-compatible modems with a set-up of S0=1 or something similar, this will cause the modem NOT to answer the phone while the DTR remains low. The BBS then has time to recycle and raise the DTR again when ready for the next call. 3.1.6 nocarrier Mostly of use with certain null-modem cables or stand-alone operations within the HydraCom terminal function, this option configures HydraCom so it will not check the DCD (Data Carrier Detect) line on the serial port. Normally, HydraCom will abort upon loss of carrier. 3.1.7 noinit Do not initialise the FOSSIL on startup. Running under some software like the mailer program Dutchie, HydraCom is not required nor supposed to initialise the resident FOSSIL driver. This option will make sure HydraCom will refrain from attempts at initialisation. 3.1.8 handshake <flg> This option allows the enabling of various types of flow control. SOFT enables xon/xoff handshaking, HARD enables rts/cts handshaking, and BOTH obviously enables both software and hardware flow control. FOSSIL drivers force RTS/CTS handshaking for a locked communications port. The internal communications routines (ie. the one used when there is no FOSSIL driver present) do not support XON/XOFF handshaking, nor do they apply RTS flow control (modem->computer). CTS flow (computer- >modem) is supported. Setting software flow control automatically forces on 'option xonxoff' to make sure Hydra escapes these characters in its packets. 3.1.9 log <file> If specified, HydraCom will log messages to this file as well as printing them on the screen. The output is similar to the format used by programs like Dutchie, The-Box, BinkleyTerm, Opus and Maximus. Page 14 HydraCom HydraCom Page 15 3.1.10 level <loglevel> This option is only really useful if LOG is also specified. Loglevel may be anything from 0 to 6. Level 0 logs anything up to Hydra packet control data. Level 6 logs only severe or fatal errors. The default loglevel is 2. 3.1.11 result <filename> (DSZ logfile) This option will create or append a DSZ (by Omen Technology) compatible log file, which some programs (such as the RBBS-PC or XBBS BBS) use to determine the outcome of a transfer. The format is as follows: <res> <byts> <bps> bps <cps> cps <err> errors <flow> <last> <fname> <sn> <res> H = file is sent, R = file is received. <byts> Actual number of bytes transferred. <bps> Line communication speed in bits per second. <cps> Protocol performance in characters per second. For very short transfers a rating of 9999 cps is given. <flow> Number of transmission errors occurred (0). <err> Number of flow control stoppages (0). <last> Size which was used for the last block in the transfer (1024). <fname> Full path and file name. <sn> Serial number of the program on the other side (0). HydraCom will not write a result line for aborted transfers, but the result file itself will always be created (empty). Prior to processing any other options the DSZLOG environment variable is checked and (if present) copied to the RESULT option file name. 3.1.12 noresume By default, HydraCom uses an internal mechanism to keep track of interrupted transfers: It keeps unfinished received files BAD-XFER.??? where ??? is a counter from 000 to 999 used to create a unique file name. The original file name, date/time and size of the file are logged to a file called BAD-XFER.LOG. Both files reside in the directory where files are received. With NORESUME, HydraCom will not keep/log unfinished downloads but instead deletes the partial file. HydraCom Page 15 Page 16 HydraCom 3.1.13 nostamp Don't retain the original file date/time information which was transmitted, but stamp received files with the current date/time. Some BBS software requires this to be able to scan for new files. 3.1.14 receive <path> Files received through HydraCom will be stored in directory <path> if this option is used. Otherwise files will accumulate in the current directory. 3.1.15 nobell Normally, the BEL character (Ctrl-G) will cause the remote system to give a short beep. This may not be desired if HydraCom is for instance used under a BBS, so with this option you can disable the beep. It only applies to the chat mode during a Hydra tranfer session. 3.1.16 mailer Selects mailer mode, changing HydraCom's behaviour slightly as required by the Dutchie mailer which uses it as an external protocol for FidoNet technology mail sessions. 3.1.17 nooriginator Instructs HydraCom to NOT act as the 'originator' side in case of trouble during a transfer. The 'answer' side will switch to one-way transfer mode under certain conditions (equivalent to the hdxlink option). Normally you won't need this option yourself, its main use is for programs like Dutchie in combination with the 'mailer' and 'hdxlink' options. Refer to the section about HST and other half-duplex modems earlier in this document for a more complete description of these options. 3.1.18 hdxlink Forces one-way transfer mode (half duplex Hydra, disables bi- directional transfers). This option only works if nooriginator is enabled as well. This option is meant for use on HST and similar asymmetrical connections. Refer to the section about the 'nooriginator' option above for more information. Page 16 HydraCom HydraCom Page 17 3.1.19 txwindow N The number of bytes to send before remote acknowledgement of reception should be received. If it's set to 0 (default) HydraCom won't wait for acks and use continuous streaming. In severe situations, this option may be necessary for links via packet switched networks and sattelites to prevent runahaid (windowed streaming). Primarily, this option is used when the machine on the other side cannot handle simultanous serial and disk I/O (segmented streaming). The exact receive and transmit window sizes are negotiated individually by the two sides at the start of a Hydra session, so if the other side has set a more limited value, that is the window size that will be used for that direction. 3.1.20 rxwindow N The number of bytes to receive before acknowledgement (ACK) should be returned to the sender (default 0=none). Refer to the description of the 'txwindow' option above for more information about windowed transmission. 3.1.21 link options Link options are used to send data over nondefault lines (such as 7- bit links, and such). Hydra will encode all data to a suitable format, send it, and the receptor will decode the data back to it's original format. option xonxoff Escape/strip XON/XOFF characters. (ASCII 17 and 19) option telenet Escape/strip telenet escape sequence CR-@-CR (ASCII 13,64,13) option ctlchrs Escape/strip ASCII characters 0 to 31 and 127. option highctl Makes xonxoff/telenet/ctlchrs also escape/strip their respective characters if the high bit. option highbit Encode for 7 bit transfers. (encodes 8 bit to 7 bit) HydraCom Page 17 Page 18 HydraCom 3.2 Commands HydraCom expects a command at the end of the command line (ie after all options). There are three possible commands: send, get and term. Send is for sending files, get is to just receive files without sending any, and term is the mini terminal. All commands normally abort upon loss of carrier unless the 'NOCarrier' option is used. 3.2.1 send [<filespec> ...] [@<ctlfile> ...] The send command causes HydraCom to send <filespec.ext>. If no file specification is given, this command will just act like a get and just receive files. @<listname.ext> will cause HydraCom to read a file called <listname.ext> in [<drive:\path>] and send the files specified in that text file. Each entry in that file should be placed on one line eg, when you want to send TEST.*, NEWHYD?.ARJ and PAL_112.C, you could place them in SEND.TXT, which could contain: C:\MAIL\FILE\TEST.* C:\DOCS\NEWHYD?.ARJ E:\C\DEVLP\PAL_112.C Normal file specifications and multiple @ctlfiles may be used on one commandline, and you can specify paths and the usual DOS wildcards * and ? (which are expanded to the file names which match the specification). In @ctlfiles aliasing and transfer options may be used. Aliasing means that HydraCom will send a file with an alias name, specified after that name, so if your @-file contain a line C:\DOCS\ANY.TXT 01A551FC.A0D then HydraCom will send the file ANY.TXT as 01A551FC.A0D. A '#' sign as the first character on a line will cause HydraCom to truncate the file(s) to zero length after succesful transfer. A caret (^) tells HydraCom to delete that file after it has been sent. Page 18 HydraCom HydraCom Page 19 3.2.2 get [<path>[<name>]] The get command may be used if there are no files to be sent, just received. With no parameter, get will put received files into either the current directory or the directory specified in the 'receive' option. If a path specification follows the get command, this overrides the 'receive' option. A get path specification MUST have a trailing backslash! If a filename specified, HydraCom will receive just one file, store it with the specified name, and refuse any other files the remote wants to send. This 'feature' is provided because some software cannot handle batch uploads and wants to know the name of the single file before the transfer. 3.2.3 term This activates HydraCom little built-in dumb terminal. HCOM_DOS has ANSI emulation if you have ANSI.SYS loaded; HCOM_GEN has an extended ANSI/VT-100 emulator in its windowing library. Downloading in the HydraCom terminal is fully automatic, HydraCom detects the remote has intiated a Hydra session (AutoStart). Any files in the upload queue will also be transmitted. There are several options and commands in the terminal mode: PgUp: Enter/edit file upload queue; HydraCom asks for file specification(s), wildcards are allowed. You may NOT specify a @ctlfile. No upload is started with this command, the specified files will be sent when either the remote initiates a session or when you press PgDn. PgDn: Download; HydraCom initiates a Hydra session and waits for incoming files/packets. Any files selected with PgUp will be sent. You cannot select files for download within HydraCom, you must do this within the BBS you're calling; ie. you can not just 'request' files from the remote during a Hydra session. Alt-X: Exit the terminal and HydraCom. Alt-C: Clears the screen and puts the cursor in the upper left corner. Alt-H: Hangup (on hook), this command drops the DTR line and causes an immediate log-off (BBS do have a G)oodbye command.. use it!). Alt-E: Toggle duplex, this command toggles the local echo mode. Alt-B: Toggle stripping the 8th bit of all incoming characters. This toggle is forced on if the 'parity' commandline option has been specified. HydraCom Page 19 Page 20 HydraCom 3.3 Default configuration file At start-up, HydraCom will check whether a file named <exename>.CFG exists in the directory where the HydraCom executable resides, and if it does, scan it for options. This is always done first, regardless of what interface method is used to pass other commands and options. By <exename>.CFG we mean that, if for instance the HydraCom executable is named HydraCom.EXE, the name of the configuration file checked for would be HydraCom.CFG. C:\WORK\HC.EXE will search for C:\WORK\HC.CFG. Each line in the configuration file may contain an option and possible parameters. Everything after a semicolon (;) will be ignored (comments). ;----------[ sample terminal configuration file ]---------- port 2 speed 38400 receive c:\comms\download\ nocarrier log c:\bbs\hydracom.log level 4 The configuration file may not contain a command (send, get or term). Statements on the command-line override those in the configuration file. You can use the utility HydraCfg to create and edit a default configuration file for HydraCom in a more userfriendly environment (full-screen windowed, mouse support, information and help texts). Page 20 HydraCom HydraCom Page 21 4 Using HydraCom as an external protocol HydraCom can be used within a lot of, if not all, communication programs which support intelligent DOS access like errorlevels, shelling to batch files, spawning, etc. Most programs have external protocol support themselves, but HydraCom can also work with programs which can use only external view or edit programs. In that case you can call exactly the same batch file as described for Procomm Plus. You could for example put the upload batch file instead of a view utility and fill in the download batch file instead of the editor utility. When you are asked what file to view, you'd fill in the filename(s) to be uploaded. 4.1 Interface methods 4.1.1 Opus-style external protocol interface HydraCom can operate as an Opus external protocol driver, as used in the Opus bulletin board system and various mailer, BBS and terminal packages which utilize the Opus method of calling external protocol drivers. Upon exit to the external protocol writes an Opus-style control file, the name of which depends on the file name of the executable HydraCom. If, in your case, HydraCom is called HydraCom.EXE, then Opus will write a file called HydraCom.CTL to the drive/path where HydraCom.EXE resides, from which HydraCom will read all necessary information about the transfer. Hydra will create a special Opus-format logfile HydraCom.LOG (in the same directory where HydraCom.CTL was stored) which provides the BBS software with a list of files that were sent/received. The Opus 1.0x method is quite similar to the way Opus 1.10 and later versions call external file transfer protocols. HydraCom handles both methods. The Opus-protocol interface mechanism is automatically used if a .CTL control file is found. If a task number (-tN where N is the task number) is specified on the HydraCom commandline, the new method is used which merges a task number into the filename of the control and log files for multi-line operation. A control file for task 3 when calling HydraCom.EXE would be named HydraC03.CTL. Note: any commandline parameters after the -tN option are ignored, HydraCom immediately proceeds with processing the .CTL file. HydraCom Page 21 Page 22 HydraCom HydraCom uses the -pN (port number, 0 based) and -bN (speed) from the commandline, other Opus-style parameters are ignored. In the .CTL file the following Opus-style options and commands are used and fully implemented in HydraCom: port Com port, identical to the 'port' commandline option. baud Com speed, like the 'speed' commandline option. modem Extended modem information like real line speed, handshake options, carrier mask. log Log file, identical to the 'log' commandline option. upload Where received files are to be stored; like the 'receive' commandline option. send Specification of file(s) to be sent; DOS wildcards are allowed, as well as the special transfer options. If the file specification is preceded by a # character, the specified files will be truncated to zero-length after successful transmission. A ^ character has the files deleted after successful transmission. If another name is specified on the same line (no path), this name is given to the remote instead of the real name (aliasing). get As Hydra is a full duplex protocol, this command is completely ignored. A receive path should be specified using the 'upload' or 'receive' option. Other (unknown to HydraCom) Opus-style commands are just ignored. All HydraCom commandline options (not commands!) be also be present in a .CTL file. Take care that all options are listed in the .CTL before the first 'send' line, otherwise those options will not have been read yet. 4.1.2 DSZ-style external protocol interface HydraCom can be called by any program using the DSZ style of passing options/commands; of course the options and commands differ from DSZ, but the basic mechanism is the same with support for @ctlfiles and usage of the DSZLOG environment variable. For more information on the format of the DSZ result logfile, see the section about the 'result' option. 4.1.3 Exit codes (errorlevels) Some programs check error codes to decide whether a transfer has been completed successfully or not. HydraCom uses the following errorlevels: 0 Normal termination 1 Transfer aborted, carrier lost, etc. 255 System error: not enough memory, etc. Page 22 HydraCom HydraCom Page 23 4.2 Using HydraCom with terminal programs 4.2.1 Telix Telix 3.15 supports up to 4 external protocols, 3.20 supports 5. You need to create a single batchfile (HYDRAUP.BAT) with one line: HYDRACOM port %2 speed %1 uploads D:\DL\ send %3 %4 %5 %6 %7 %8 %9 (change D:\DL\ to the path of your own download directory) Start Telix, and from the main terminal window press Alt-O (Configure Telix), select option P (Protocol options) and select a free protocol line (A-D/E) (or replace an unused protocol): Key H Protocol name Hydra Upload filename HYDRAUP Download filename HYDRAUP BAT or script Batch DL name NO Autodownload string (press ctrl-X)cA\f5\ (autodownload string only available in Telix 3.20) Now press ENTER (returns to configure Telix) and select option W (Write setup to disk). Telix will automatically return to the main terminal window. 4.2.2 Communique HydraCom batchfile that can be used for Communique: @echo off rem HydraCom installation under Communique 1.0x rem ------------------------------------------- rem Name : Hydra rem Key : 1 rem Upload : CU_Hydra.BAT *C *B *D *U *G rem Download: CU_Hydra.BAT *C *B *D *U cls HydraCom port %1 speed %2 nocarrier handshake receive %3 send %5 HydraCom Page 23 Page 24 HydraCom 4.2.3 Commo Add the following to your COMMO.MAC file in the appropriate places: (the upload protocol menu) HydraCom using HYDRACOM.EXE {goto phyd} (the download protocol menu) HydraCom using HYDRACOM.EXE {goto phyd} (no download macro, just uses uploade macro) (upload macros) HydraCom {:phyd} {call gfnu} {exec-a HYDRACOM por %_por spe %_spe han hard rec %uldir sen %file} {} HYDRACOM.EXE And the following line to your COMMO.SET file: {aut=phyd,^XcA\f5\a3^Xa} Auto Receive, HydraCom 4.2.4 Procomm Plus This has been tried and found to work with the Procomm+ TestDrive version. For use with Procomm Plus, you need to create one batch file which calls HydraCom: HydraCom port 1 line 2400 receive D:\DL\ send %1 %2 %3 %4 %5 %6 (change D:\DL\ to the path of your own download directory) Procomm+ does not provide the line speed, comport number or the path to store received files; you should fill them in yourself. It's not terribly user-friendly and it may cause you trouble. But there's not much you can do about it except get different terminal software. You should specify the batch file in the Procomm Plus protocol set-up menu. From the Procomm Plus main menu, press Alt-S (Setup Utility), then choose PROTOCOL OPTIONS and take an empty pair of entries, either A-B, C-D or E-F, if you would choose A-B, then press A, fill in the HydraCom upload batchfilename (HPCU) without extention, and press ENTER. Then press B, fill in HPCD and press ENTER. Then press escape, select the SAVE SETUP option, and press escape again. Page 24 HydraCom HydraCom Page 25 4.2.5 TeleMate Create a batchfile, to be placed in the TM home directory: HydraCom.EXE port %2 speed %1 receive D:\DL\ send %3 (change D:\DL\ to the path of your own download directory) Now start TeleMate and from within the TeleMate main terminal window, press Alt-O (Options). Select option P (Protocol). Select a free protocol line, or replace an unused protocol: Name Hydra Key H Upload batch HYDRAUP Download batch HYDRAUP Prompt for dl name NO Exit the protocol window with the OK selection (returns to 'Options' window), select option S (Save options) and press ESC (back to main terminal window). 4.2.6 Boyan To use HydraCom with this program, run Boyan and press Atl-C (Configure BOYAN) from the main terminal window. After this, select option D (Disk, directory, files) and then option H (Path for external protocols) Now enter the drive and path where HydraCom.EXE can be found, don't forget the trailing backslash '\'. Then press ENTER (finish entry). Press ESC (returns to 'configure BOYAN' screen), select option X (External transfer protocols) and select a free protocol line entry (0-9). Protocol name Hydra Menu letter H External file HydraCom Prompt for DL-name? NO Upload \DC-[%P:HydraCom port %MD speed %MS rec dl>\ send %TF] Download \DC-[%P:HydraCom port %MD speed %MS rec dl>\ get] (Don't forget to specify the downloadpath including the trailing '\') Press ENTER (finish entry). Then press ESC (returns to 'configure BOYAN' screen) and, again, press ESC (back to main terminal window) HydraCom Page 25 Page 26 HydraCom 4.2.7 Qmodem To use HydraCom with the Qmodem communications package, enter Qmodem, and from the main terminal window, press Alt-N (Configure Qmodem) Then select option P (Protocols) and select a free protocol line entry (0-9). Select character H Protocol Hydra Upload BAT HYDRAUP.BAT Download BAT HYDRAUP.BAT Filename Prompt N Finished? press ESC (returns to 'Protocols' window) and again, press ESC (returns to 'Configure Qmodem' window), select option E (Exit) and select option S (Save Changes) Qmodem will then automatically return to the main terminal window. The batchfile (placed in the Qmodem home directory): HydraCom port %2 speed %1 receive D:\DL\ send %3 %4 %5 %6 %7 %8 %9 (change D:\DL\ to the path of your own download directory) Page 26 HydraCom HydraCom Page 27 4.3 Using HydraCom with BBS software 4.3.1 Maximus Protocol Hydra Type Batch Type Bi LogFile Hydra%K.Log ControlFile Hydra%K.Ctl ; Put in NOS (nostamp) to not retain date/time on received files DownloadCmd HydraCom.Exe por %P spe %W lin %b dro nor nob res %x:Hydra%K.Log rec %v sen @%x:Hydra%K.Ctl UploadCmd HydraCom.Exe por %P spe %W lin %b dro nor nob res %x:Hydra%K.Log rec %v get DownloadString %s UploadString DownloadKeyword H UploadKeyword R FilenameWord 10 DescriptWord 0 End Protocol Note that the DownloadCmd and UploadCmd lines are both a bit long and therefore wrapped in this document. Maximus would also be capable of using the Opus mechanism instead of using DSZ-style, but Maximus 2.00 and 2.01wb have a bug in that code which causes it to pass invalid data in the controlfile. 4.3.2 Opus Opus expects you to specify the path and file name of HydraCom in your Opus control file. Usually, you would want the user to invoke Hydra with the H keystroke, so the name of the HydraCom executable should start with a H, like HydraCom.EXE. In this case, you should add an external file transfer protocol line to your Opus control file which (in case HydraCom.EXE resides in the c:\opus directory) reads: External_file_protocol C:\OPUS\HydraCom.EXE HydraCom Page 27 Page 28 HydraCom 4.3.3 QuickBBS and RemoteAccess (FileDoor) You can offer HydraCom from QuickBBS, RemoteAccess and similar packages with the FileDoor program. For that, you would have to add the specifications for HydraCom to your filedoor configuration file: Protocol 96 T U 20 0 Hydra Usage 0 0 N Y 38400 BiDSZ HYDRACOM.EXE por $1 spe 38400 lin $2 nob rec $8 sen $3 $M Protocol 96 T D 20 0 Hydra Usage 0 0 N Y 38400 BiDSZ HYDRACOM.EXE por $1 spe 38400 lin $2 nob rec $8 sen $3 $M These settings only apply if you use a modem locked at 38400. For information about which settings to change for your modem, please refer to the FileDoor documentation and config comments. 4.3.4 RBBS-PC RBBS-PC uses a file called PROTO.DEF to define the external protocols. Here is a sample PROTO.DEF. Please refer to the RBBS-PC documentation for information concerning the syntax. "H)ydra ",0,S,8,,B,1024,,0.96,,1=E,"D:HydraCom.EXE port [PORT#] speed [BAUD] dropdtr result D:XFER-[NODE].DEF send [FILE]","D:HydraCom.EXE port [PORT#] speed [BAUD] dropdtr result D:XFER-[NODE].DEF get [FILE]" It is one physical line which should not have any CR/LF in the middle. 4.3.5 Wildcat! Wildcat! is a commercial Bulletin Board package, this paragraph will cover the implementation of HydraCom within the Testdrive version. You should create a path to your external protocols, like C:\WILDCAT\EP, where you should store all files related to external file transfers. Wildcat! will also temporarily store the sent and received files there. You should also specify this path in the Wildcat! set-up program, (MakeWild) and don't forget to add to the number of external transfer protocols, also in the set-up program. After that, you should define HydraCom within the external protocol definition part of the set-up. LTR defines the key which a user should press in order to invoke the transfer batch file. At the Up.BAT position, you should define the HydraCom upload batch file and at the Dn.BAT you should define the HydraCom download batch file. Setting the Batch field to Y(es) will allow a batch (multiple files) of files for up- or downloading, this is recommended, though the test-drive version does not support batch uploads. Please note that users cannot invoke external protocols during the period between an event and two hours before the start of that event. Page 28 HydraCom HydraCom Page 29 Wildcat! spawns to dos upon exit to HydraCom and will assign the baud rate to DOS variable %1, the communications port is assigned to variable %2 and the file name(s) (without path) are assigned from variable %3 to variable %9. The batch files must be located in the external protocol directory. Your download batch file would be: CD \WILDCAT\EP HydraCom.EXE port %2 speed %1 sz %3 %4 %5 %6 %7 %8 %9 CD \WILDCAT and your upload batch file could, for example, become: CD \WILDCAT\EP HydraCom.EXE port %2 speed %1 rz [%3] COPY %3 [%5]%4 DEL %3 where the %3 variable denominates the file which is to be received, but this does not need to be specified to make HydraCom receive a file. Variable %4 contains the path to an upload directory which has been specified by the user and variable %5 contains the full drive, path and file name. The latter two variables can be useful in the batch file which calls HydraCom, for example to move files directly to an upload area. These batch files should be named according to the batch file names which you filled in under Up.BAT and Dn.bat in the MakeWild set-up program. To allow as many (seven, %3 to %9) files to be downloaded in one batch as possible, Wildcat! does not use a path, but only uses the external protocol directory. Wildcat! will copy files which are to be sent to this directory (and delete them after the transfer) and will receive files into this directory, a DOS command line is limited to 128 characters, so this saves a path denomination before each file. You can edit PROTOCOL.HLP and add information about HydraCom to it for your users. HydraCom Page 29 Page 30 HydraCom 4.3.6 XBBS The internal XBBS version 1.06 method: XBBS needs a PROTOCOL.TXT, which is made into PROTOCOL.CTL by XPROTO.COM. You could add the next lines to PROTOCOL.TXT in order to install HydraCom in your XBBS. ;sample PROTOCOL.TXT for HydraCom Hydra ;Protocol label H ;Key to select protocol 96 ;Protocol efficiency C:\XBBS\HydraCom.EXE PORT *p SPEED *B send *F;Download string C:\XBBS\HydraCom.EXE PORT *p SPEED *B get ;Upload string type a dozen CTRL-X's ;Abort string Y ;Wildcards? Y ;Multiple file names? Y ;Simultaneous U/D? Y ;use @listfile? Y ;remote filename? Y ;Use DSZlog? N ;not yet used N ;not yet used Please refer to the XBBS documentations for the exact meaning of the PROTOCOL.TXT statements. Then run XPROTO PROTOCOL.TXT in the XBBS home directory and you got yourself a PROTOCOL.CTL with HydraCom. Page 30 HydraCom