Hi all,

I am having a hard time finding a control or DLL or code that will allow me to implement ZModem file transfer functionality to my app. My app uses telnet and terminal emulation controls to connect to IP devices.
I found lots of controls to implement TCP and Telnet sessions and lots to do ZModem transfer over serial ports, but nothing over TCP.
Has anyone implemented or knows of any tools to accomplish this. Any help is appreciated.

Thanks,

George.

This seems like apple and oranges. TCP is a communications protocol, and serial port is a communication path. (Isn't it?)
In the same vein, ZModem is a file transfer protocol, and the serial port is a communication channel.

It seems if you have a modem connected to com1, you would use ZModem protocols to send info to com1. the modem would handle converting the data (the protocol) to the proper voltage levels and timing (the communication physics) and communication would take place.

Bottom line is, I want to transfer files using ZModem over Ethernet . My app happens to have a socket open with a remote device and I need to implement ZModem file transfer over that link. This has nothing to do with serial ports. I don't want to have to implement ZModem from scratch.

It doesn't make sense to implement zmodem for tcp because tcp is a reliable protocol. Implementing zmodem over tcp would only add overhead - ZModem is designed to handle errors and retransmit blocks when errors occur. TCP will handle all errors transparently. The only benefit that zmodem would provide would be a way to transfer multiple files without reestablishing the connection. You could implement a far simpler protocol for providing the ability to send multiple files without reconnecting.

Did anyone bother to ask "why" he needed to have zmodem? There are a number of programs designed for emulating BBS systems and/or feeding the output from one from false COM ports to TCP/IP. I just went looking for something similar, hoping that it would be in some language other than C, so that I could make a plugin for a telnet client I use. That way, I could log into some of these simulated BBSs and download stuff from them. Sure, FTP works too, if/when the files are available from them that way. In his case, he might be trying to run one of these, and needed some way to test it. In my case, the client I am using doesn't have it, so I can't download the re-roller for a game I want to play, which means either a) coding one myself or b) making a plugin to support zmodem.

As for the absurd idea that TCP would handle all that stuff.. Well, why the @#$#@$ did anyone bother designing FTP, bittorrent, or those other "redundant" protocols, if all you need to TCP/IP. lol FTP, bittorrent, HTTP, etc. are "all" layered over top of TCP/IP, some are transfer protocols themselves, and not all of them that are work that well. FTP, for example, can be tied to a server that doesn't allow resuming, or be written so badly in the client/browser its in that it can't handle certain failure/time outs/errors properly. More than a few times I have lost hours from a download because the damn server refused to allow a resume, or timed out, and the damn FTP protocol insisted the entire file was completed, even when it was like 1k short...

Point being, there is a legitimate reason to want to use zmodem, if you are running, connecting to something that emulates BBS servers. And arguing that you don't *need* or that there are better existing protocols, misses the point entirely, isn't always true, and **all** of them add overhead to TCP/IP anyway, making that argument totally meaningless. The only time you "ever" use anything close to pure TCP/IP is for something like telnet, and even then there are protocols added to support ANSI, colors, MXP, Pueblo, etc, etc, etc.

To answer you Geogomez. Its hard to find anything that does what you want. I know, I have looked. The biggest issue I can see in coding one is realizing that zmodem assumes that "it" will be building the packet. I.e., it assume it will receive a z, then an r, etc. and, I assume, works on it as it goes. So you have to "fake" this process, since TCP/IP is going to give you the entire string, while a modem only gives you each character, one by one. If it instead builds a complete string, then tries to parse the string (which would be redundant on a COM port, so isn't likely), then it would be even easier, but I doubt it.