I'm not familiar with HAM, but I am familiar with communications protocols. The problem seems to be that you're using a synchronous protocol like TCP. Other BitTorrent-like protocols might speed things up considerably. I can do some research. You list a few, but what specific hardware systems are you trying to be compatible with?
Discussion
No, I'm not using async tcp, I'm not sure what you mean. There is no networking stack other than connecting to the tnc on an ip, and the webserver front end. Everything is over ham radio packets which are not duplex.
Any hardware tnc modem that uses KISS is compatible. It is up to the user to try.
Thanks for your input, but I think we are on different wavelengths so to speak as to what HAMSTR is.
Sorry, my internet comparisons aren't helping. You said that you're doing this:
T: Connection
R: ack
T: ready
R: ready ack
T: request to send
R: ready
T: Note1
R: ack
T: Note2
R: ack
T: final done
R: done ack
I'm suggesting:
T: Ready to send
T: Note1
T: Note2
T: ErrorCorrectionA
T: Maybe: ErrorCorrectionB
T: Done
R: Maybe: request to resend partN
R: Done ack
So, half as many packets, no channel downtime, and the possibility of many receivers. This is the difference between "TCP" and "BitTorrent". I don't it's incompatible with your hardware goals
While you are absolutely correct that would save packets and time, there are way too many packets lost in HF radio for something like that, unfortunately. It is not uncommon to miss over other, every third packet. Even the small ones. Something like ardop or Vara does their own acks and systems for error correction, which work fine. But there is zero chance you can proceed with our them and still keep the connection going. I'm fact, on HF, sudden complete signal drop is common.
I'm also in no way going to redo the packet stack at this point, lol.
The whole idea behind forward error correction and fountain codes is that you spray a lot of data, and the other party eventually checks in to tell you what they missed. I'll do my homework on HAM and check out your git repo. Carry on! 🫡
Sounds good. I do appreciate the feedback.
In the end, the HF packet radio software fldigi and reticulum network are the goals. More flexibility. But ardop seems doable as well.
Lots of fixes and features missing first however, like a decentralized server auth system.
Also, you can't have many receivers in ham radio data modes. Not legally at least. You must announce yourself and where you are sending it to. 2 stations cannot be using the same callsign at the same time as different receivers if that makes sense.
But by all means, fork it and do whatever you like.