On 2019-07-07 21:40:27 +0000, Digital Man -> Ozz Nixon said:
Firstly, XMODEM is a pretty bad protocol (no file name/metadata, up to 127 bytes of garbage tacked on received files, no streaming). If you're going to work on extending any legacy protocols, I would start with YMODEM at
minimum.
I am all for it... their XModem extensions apply to both X and Y. Does SyncTerm YModem support more than 1K? I am keen on publishing protocols
like -G or Windowed, so it is push w/o epecting error(s).
I did a simple terminal, and pushed 480Kbs up to the server... which
was 100% saturation of my outbound at the house (I know SLOW).
The protocol is VERY simple (like Modem7 & YModem - with a few header
changes):
Like BinkP CRC mode = $80000000 means start at -1 (wait for client to
send 0, or resume point)
Data_Len_Byte = Value * 1024 = Block Size, acceptable values 1, 2, 4, 8, 16,
32
EXAMPLE:
========
C: Sender Wait for Ctrl-E (Enquiry) up to 30 seconds, timeout=return to BBS
S: STX + null terminated filename + EPOCH 64bit (ASCII, ZERO PAD LEFT)
+ FileSize (ASCII) + CRC16 + Data_Len_Byte + $80000000 ETX (as we
expect no errors on TCP most of the time, Data_Len_Byte and $80000000
and ETX are not part of CRC16)
C: $00000000 (denotes start sending at 0th byte, could be any value up
to $7FFFFFFF)
(*) If timestamp has changed, client will always send $00000000
(*) If partial exists, timestamp matches, send FileSize(handle) in HEX
[8 characters]
(**) Where $00000001 = start at byte 1, and $10000000 = start at byte 268,435,456 and $7FFFFFFF is the maximum RESUME pos (2,147,483,647 -
sorry if you needed to resume at 5gb - this will always resume at
2.1gb).
S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
{...}
S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO + EOT
Return to BBS Success.
1. When a Side is waiting for a reply, timeout is 1000ms (1 second,
18.2 ticks) - timeout = fatal (cancel xfer)
2. We do not scale up and down, Data_Len_Byte applies from first to
next to last block, where last block can be anywhere from 1 to
Data_Len_Byte in length.
3. When resuming xfer or starting from 0 - First Block# is 1 - do not
try to calculate last block received on a resume, as it could be a
partial if resuming at a different Data_Len_Byte size - which is
acceptable.
I am still testing this - going to put the script on 2 servers with
10gig fiber between them and see how fast can I push this - and would
it make send to have packets larger than 32kb + 5b.
Ozz
--- ExchangeBBS NNTP Server v3.1/Linux64
* Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)