Understanding the iodine landscape

[Lanchon]

hi @frekky,

thanks for your work!!!

years ago i used iodine when the only protocol option was ping-pong -which was unworkable for connections with any latency to speak of- and never used it again since. at the time i thought of forking iodine myself to fix this, but never got to do it.

in 2015 you contributed an update to yarrick/iodine that included a sliding window protocol to decouple throughput from latency and fix this issue. however, for whatever reason it was never merged.

later you kept on developing your fork for many years, to an old pre-0.8-stable, master in 2017, and unsable to this date.

i have a couple of open questions that would help me and other newbies understand the iodine landscape as it is now. hopefully you can clarify some.

1. did "mainline" yarrick/iodine merge any competing solution to increase throughput in high latency networks?

2. why, do you think, your changes were not mainlined?

3. if someone where to use your fork, what version/branch would you recommend?

again, thanks so much for your work!

[Lanchon]

i tested the unstable branch. iodined triggers GCC buffer overrun protections, and iodine causes seg faults.

the master branch seems to work well, but the fragment size binary search seems to be broken.

[frekky]

Hi @Lanchon, thanks for your feedback! Glad to know that someone finds my improvements useful.

As some background, I unfortunately never quite got to the point of fixing up the last few bugs before moving on to developing new features (see the unstable branch), which never quite got fully implemented. I've not had much time to work on it lately but will see how I go in the next few months.

The master branch contained what was the last-somewhat-working version, and pre-0.8-stable was probably the last-mostly-working version. The unstable branch includes significant refactoring and protocol changes to add HMAC-MD5 packet authentication and better replay prevention mechanisms, although the implementation of those changes is nowhere near complete and it's not currently in any meaningfully usable state.

To hopefully answer all your questions - the "original" yarrick/iodine actually works, although it is slow, whereas my fork simply hasn't been tested enough (and still contains many bugs) to be practically usable. If you're looking for something which is faster than the original, the pre-0.8-stable branch will probably work well enough for some situations.

For you and anyone else reading this - if you have any time to test or work on the code, any contributions would be greatly appreciated :)

[Lanchon]

thanks!

well after unstable, i sort of gave the master branch a try. i compiled the code for my linux box, and after minimum testing i also compiled it in/for my ddwrt router augmented with entware. that was a bit of pain because entware does not have autotools, but now my router is running your master. it also runs a wireguard VPN server.

as i said before, the auto fragment sizing seems not to work. the branch also has issues with 1.1.1.1, but on 8.8.8.8 it works well.

so some testing...

in the old days i could barely run a chat session on iodine. now i can fully surf the web. with your master nesting wireguard nesting my surf session, with traffic from the iodine client on my PC bouncing against 8.8.8.8 and then coming back to my router which peeled iodine and wireguard and bounced it back to the open internet, i was able to... watch youtube videos without interruptions! absolutely amazing!!! :)

i also compiled the branch for my rooted android. works but i haven't yet automated the connection setup. btw, on my PC i'm using the gnome network manager iodine extension, so i just click and connect.

so...

you are telling me pre-0.8-stable is preferable to master? ok, lol :((( i had imagined master had fixed some pre-0.8 bugs.

anyway, from your message i expect pre-0.8 to be more dependable in the field compared to master. but would it represent a regression in performance?

thanks again, great work!!!