|
|
|
|
Protocol FAQ Table of Contents
What is a protocol?A protocol is a (sometimes) well-defined set of packets to transmit/receive data. In the context of what you're reading, that data would be a file of some sort. With a protocol, you can transfer a file with your APRO app back and forth between non-APRO apps. APRO has a few different protocols built in: X/Y/ZModem, Kermit, ASCII and Internet FTP. All of these support the Internet transport layer (TApdWinsockPort), all except FTP support regular port (TApdComPort) stuff. Back to TopWhy use protocols?Good question, although if you had read the previous "What is a protocol" text you could have figured it out yourself. You'd want to use a protocol to transfer files between different systems. Your APRO ZModem transmitter could send files to a Linux box, or a Mac, or even to your Apple ][+. Same thing for Kermit, XModem, or any of the other protocols. Some of the protocols are really mini operating systems, such as Kermit and FTP. With those, you can get remote directory listings, do remote file management, even run programs. Most of the supported protocols also include some form of error detection and correction. It's also real cool to be able to drop names like ZModem or Kermit in everyday conversations. Back to TopProtocols and APROThere are two APRO components that do file transfer protocols: TApdProtocol and TApdFTPClient. The TApdProtocol component implements X/Y/ZModem (and their variants), Kermit and ASCII. The TApdProtocol can be used with the TApdComPort or TApdWinsockPort for use through the serial port or Winsock. The TApdFTPClient component is a little different, that's because FTP itself is a little different. The TApdFTPClient is a stand-alone component, it does not need an external port. FTP is a 2-connection protocol, so it needs a command connection and a data connection. The command connection is where the FTP commands go; the responses are sent in the data connection. Because it's using the two connections simultaneously, it can't use the serial port (that only has one connection); it uses Winsock. While protocol transfers are in operation, it's generally a good thing to disable data packets, terminals, triggers, etc. We had a a guy a few months ago that complained that his connection was dropping half-way through a ZModem transfer. It turned out that he had a data packet set up for "logoff", and he'd disconnect when he got that string. The test file he was transmitting was the design-doc for the application, and it described how to terminate the session. In case you didn't catch it, the doc had the word "logoff" in it, and he dutifully logging off. If you need more info than what is provided here, look in the APRO manual for details about the implementation of each protocol. Back to TopWhich protocol is right for me?If you're transmitting files with another system, one that already has determined which protocol(s) it supports, then the answer to this is simple: use the protocol that the other side uses. If the other side supports more than one protocol, use ZModem. All in all, ZModem gives the best balance of error detection/correction, speed and features. If you're sending text to a dumb-terminal, you can use the ASCII protocol and the terminal will treat it just like it was typed in locally. If you're doing serial connections, and have to use something other than 8N1, use Kermit or ASCII. The X/Y/ZModem protocols only support 8N1. Once you start getting into 7 data bits, they'll stop working. Kermit can support other line settings, but 8N1 will still give you better results. ASCII doesn't care what the line settings are, as long as the data fits within the constraints of 7-bit (#0 through #127, 0x00 through 0x7F). Back to TopXModemXModem is one of the oldest formal protocols. It sends full blocks of 128 or 1024 bytes each, and uses a checksum or CRC to validate that the data was received OK. Each block is sent sequentially, and verified as it is received. The transfer is started by the receiver sending <NAK>, 'C' or 'G' (XModem, XModemCRC, or XModem1KG). Once the sender gets that, the sender starts sending the blocks, which look like this: <SOH><Block#><not Block#><128><checksum> If 1024 byte blocks are used, an <STX> is used to mark the start of the header instead of the <SOH>. If the checksum/CRC matches, the receiver sends an <ACK> after each block and the sender sends the next block. If the checksum/CRC fails, the receiver sends <NAK> and the sender sends it again (up to 5 times). One thing that should be obvious from this is that XModem does not pass any file information, so the receiver has to supply a file name to save it. Also, since there is no file info, the receiver doesn't know the original file size. The result of this is that all XModem files have sizes in multiples of the block size. Back to TopYModemYModem is a modified XModem. A 32-bit CRC is used to provide a greater degree of error detection, and YModem has a block 0. Block 0 is the file info block, where things like the filename, size, creation date, etc can be passed. Like XModem, YModem is started by the receiver sending 'C' handshake character. Back to TopZModemZModem is the most popular serial protocol (FTP is the most popular Winsock protocol). The original purpose of developing this protocol was to provide a durable protocol with strong error recovery and good performance over a variety of networks (switched, satalite, etc). ZModem starts with the sender sending a ZrQInit frame, so the receiver needs to be started first. For most ZModem transmits, the sender starts by sending "rz"<cr>, which comes from the Unix world. The "rz" program is what receives using ZModem (hence the "rz", "receive zmodem"), sending that would run the program on the receiver. Back to TopKermitKermit is a file transfer protocol and more. Yes, it is named after Kermit the Frog from the Muppets. Kermit is the only real protocol supported by APRO that supports non-standard connections. You can't use ZModem over a 7E1 connection (the Zmodem escaping requires 8 data bits), but you can with Kermit. Kermit gets around the 8-bit world through character quoting. Everything that Kermit transmits is in a printable 7-bit ASCII format, so any non-printable chars (control chars) and chars with the 8th bit (0x80/#7F and above) are preceded with a quote character and the actual char is translated to something in the printable range. For example, each time you send the SOH char (#1/0x01, ^A) Kermit sends "#A". Each time you send 0xC1, Kermit sends "&A". It should be intuitive now that Kermit has a lot of overhead for binary files, most of the characters will be doubled when they are quoted. Kermit also has some RLE (Run Length Encoding) compression. Kermit starts with the sender sending the KSendInit packet, so the receiver needs to be started first. Kermit was a group project, so it has lots of options, and lots of variations. There are even Kermit servers that act as mini-remote file systems. APRO doesn't directly support the server commands, but they can be implemented relatively easily. Back to TopASCIIAh, the ASCII protocol. How much simpler could we get? The ASCII protocol simply reads a file and sends it out the port (or reads from the port and writes to a file). As the name implies, it works best with ASCII text files. For pure 7-bit chars it can also work under 7 data bit connections. There isn't a protocol handshake, nor is there any error correction or data compression. Think of it just a raw, unrefined copy from one place to another. No file information (name, size, date, etc) is passed, when the transfer starts the chars start flowing. The ASCII protocol stops when the EOF char (usually Ctrl-Z) is received, or if a timeout elapses (after a period of inactivity). One use for the ASCII protocol is when you want to display some information to a remote station, such as a report. The local report engine would create the ASCII text file, you'd send it to the other side, and the remote operator could read the report in their terminal window. Back to TopInternet FTPThe Internet FTP transfer is a completely different beast from the other protocols that we've discussed here. It is Winsock only, and client-only. Also, unlike the TApdProtocol, the TApdFTPClient does not require a separate TApdWinsockPort component, it handles the connection(s) internally. FTP actually uses two connections, a control socket and a data socket. Commands and such are handled via the control socket, data transfer is done with the data socket. Back to Top
|