cs442a07@cs.iastate.edu (Sunny G) (02/18/91)
I have plans for a new protocol.... out of respect for my name, I call it SGMODEM. This protocol is for people who talk to mainframes or download over connections which strip certain characters/respond unfavorably to others (like myself, here at Iowa State University, where we have a direct linkup to the computers... but these linkups process XON/XOFF, as well as barf on NULs... and then when telnetting from the central puter to the one where all my homework is, that one grabs ^]... etc etc. I was wondering if anybody would care to grab this idea and implement it (something on Unix, and something on Ibm. Unix->Ibm transfers are more important. ) Feel free to grab the idea and make money if you wish, just send me a working copy, please. ------------- In writing this message I decided, hey, I might as well post almost all transactions are done using a working set... this working set can either be assumed by the sender or actively investigated (and saved, for later assumptions.) If you have N characters which work reliably, then N-1 are data and the Nth is a flag. To transmit a number (not just a byte) follow the routine: procedure sendcode(integerlikething tosend) begin if tosend>=num then begin sendch(table[num]); sendcode(tosend div num); end; sendch(tosend mod num); end; (yes I do write in pascal... I dont have harddrivespace for C. Care to send me a free harddrive?) Thus, if the working set is "0123456789f" then sending 287 would be "ff287". Once a working set has been established, everything is done by the receiver... they request the filename, size of file, protection (if they want to), a seek or a block. If a block is requested, the sender sends starting position, length, <data>, checksum. As all these are just numbers, it works out kinda well. I havent thought about sending the data as anything other than sendcode(byte), though I suppose that sendcode(word) would waste less stuff (or maybe it would waste more - more flag bytes.) A special format could be made for text files - as we are not seding bytes of data but rather sendcodes, we could say 256=>'\n', 257=>'\t', 258=>'\h' etc. That takes care of the problem of unix \n being different from Ibm \n. How does the protocol differentiate text/binary files: easy. either specify when sending: -b or -t switches, or actively search the file for non-text bytes. If there is a non-text byte, then it must be a binary file. I suppose multiple files can also be dealt with... receiver requests stuff like "end of files?", "nextfile", "start at the first file again", "skip to Nth file". Everything is still in developmental stages. I hope to have it done by the time I'm 25 (19 right now... heheh.)