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.