Author Topic: V .19.26 UDP code screwed up, it was working and tested  (Read 3323 times)

0 Members and 1 Guest are viewing this topic.

Offline scripter

  • Regular
  • **
  • Posts: 88
  • Karma: +2/-0
    • View Profile
V .19.26 UDP code screwed up, it was working and tested
« on: August 24, 2008, 01:35:48 AM »
Don't blame me.

It doesn't even compile. That means it's not tested.

What I did was completely tested and working on Linux as I said before. It's not my fault.

Maybe there was a timing thing between when I posted the patch with the reliable UDP code (UDT) and it will be included later.

I posted the patches to sourceforge and that should generate a e-mail directly to the devs.

I see two new versions with no UDT, is that the answer to the UDT question?

If there's still a concern about including other's code in OFF (meaning UDT), please take out SHA1, Base64, and all the RSA, AES stuff.

The code I wrote didn't interfere with ***ANY*** other code, I was careful about that. When the "use_udp" variable wasn't set it did *exactly* what it did before, using TCP. The default setting was 0 (disabling UDP mode).

I spent a lot of time testing the code I made. That's all in the trash now, why?

With UDT you would make a big leap forward into reliable UDP, today, now, with little time spent on trying to develop the same thing yourself. (why do I have to try to promote this anyway? It just makes sense)

UDT has been tested and in use since at least 2001. Bugs have been fixed. The interface to it is defined in documentation so that shouldn't change. You can standardize on this one version of code and never change it again if you want, leave the code as is forever if you want, it works great. It does everything we want it to do.

You, the users, can still do reliable UDP with V.19.24 and my patch if you want to see if it works on your mesh, local LAN network or whatever. V.19.24 still shares files OK and could probably be used for a local sharing situation for the next year if you wanted to.

It's a little frustrating at this point, I was going to do more work on this and other improvements to OFF but now I've stopped, I hate wasting my time.
« Last Edit: August 24, 2008, 01:38:33 AM by scripter »

Offline OFF-meister

  • Regular
  • **
  • Posts: 98
  • Karma: +3/-0
    • View Profile
Re: V .19.26 UDP code screwed up, it was working and tested
« Reply #1 on: August 27, 2008, 04:08:43 PM »
Your code has not been discarded, it is waiting for review and inclusion
in the main tree. This is not a fast process, especially when it requires
an external library. We must be sure the library builds and works on
all platforms, there is not just the one makefile that you patched to
be modified.

We have not yet decided if we want to dependent on another library, as I
said before this has caused us several nasty problems in the past.

The patch makes UDP and either/or option, we would prefer nodes to be
capable of both types of communication to avoid splitting the network.
We are working on making this easier, as time permits.

I'm afraid you can't submit a large change like this (which requires an
external library and changes the client protocol) and expect it to be
included in the main dev tree without any delay. Those of us working
on OFF are typically time-poor, and this means both that dev must be
priority driven and that we don't generally have time to monitor forums
(much as we are thankful to planetpeer for providing this place for
discussion). I would urge you to please be patient.

I would also urge you to visit our IRC channel at
where you could help us with these issues. I'm sure we would be able to work
something out.

Offline scripter

  • Regular
  • **
  • Posts: 88
  • Karma: +2/-0
    • View Profile
Re: V .19.26 UDP code screwed up, it was working and tested
« Reply #2 on: August 27, 2008, 09:07:09 PM »
OFF-meister, thanks for the info. You are right, I should have included some sort of #ifdef so that it only appeared on linux compiles for now.

Can you please tell me in some detail how I can compile the windows version on a linux box? Wine is available on Ubuntu and I'm sure I can download and install any open source solutions that are available.

I see the code that starts to make it so that it can work with both TCP and UDP on at the same time, but doing that is going to take a lot, lot more work.

The GUI is going to need to be modified to show what mode the connections are in, how many UDP connections are allowed etc.. and some sort of connection manager will need to handle what type of connection is best, and possibly each node in the known nodes.txt list will have to indicate what type of connection worked best last time. There are probably other things that will come up.

It's probably a good idea to research how I2P handles UDP and TCP since they have been doing it for a while.

That's why I thought a simple patch and a on/off switch would be best for now and less time consuming for the devs.

Right now there are special applications such as Wifi and LAN sharing that are not part of the normal network but could help create more interest in OFF. I doubt anyone is going to turn this thing on and expect other people on the internet to have their nodes set to UDP also. It's not going to split the network, it's just for testing.

That's why I called it "experimental UDP", so people can test it out in different situations and see how it goes. It will be good to have some feedback on what applications UDP and OFF are best for.

Testing needs to be done because someone may find one big reason the whole UDT thing needs to be scrapped. I hope not but it's easily removed at this point, no one is expecting it to be there as a standard feature yet.

Nemo has a great situation for testing this, a long distance mesh network with many hops.

I think moving forward if I could figure out how to compile this on windows (in linux preferably) and get it to include the UDT stuff on those 2 "big" OSs, then a #ifdef would take care of the rest for now.

I would think that the SUSE and deb versions would compile the same as Ubuntu did, with no problems.

As for IRC, I don't see how constant interruptions at random times and trying to sync up with other people's schedules saves time when here you can read and post when you are compiling, running a long test, or on a break of some type.