p2p connection via UDP

[flape]

Have You considered possibility of sending the actual data over UDP? I think it would help in cases when the dl speed is to low ( like few 100 byte / s ) and one have to ACK every incomming trafick.

[Firon]

...which is exactly what you have to do for UDP NAT traversal.

It's easier said than done, because you basically have to re-implement TCP yourself in UDP. Don't forget that BT is a TCP protocol.

[flape]

AFAIK BT doesn't specify the transport layer ... If it's already being implemented as NAT travelsal ... good. But the point was that TCP at some point producess unnecessary outgoing traffick. It was quite a pain seeing netdump shoing that every 55B of data was ACked and I'm not alone thinking(see mailing lists) about that using TCP for BT is luxury ... the protocol can(almost ... small changes necessary ...) handle if there are packets being dropped.

[Firon]

I know, but UDP also lacks congestion control, and to re-implement BT in UDP really does take a lot of work, you have to implement most of what TCP provides yourself.

[flape]

Cognession ... yes ... first thought was , it would be still necessary some sort of ACKing but at least not for every #&^$ packed. I'll do probably some search/thinking about this subject ... Doest anything(complications) else come into your mind ?

[Firon]

Reliability, you have to implement a mechanism for that. And for rebroadcasting lost/malformed packets too.

Still, I think ludde's shown a bit of interest in trying this, but he needs documentation or something for where to start.

[flape]

Reliability: what exactly you ment? Every datagram will get sequence number. That should do. Lost/malformed packets? BT allows asking for byte-range ... -> Improvement : asking for multiple ranges in one query.

[Firon]

UDP has no reliability mechanism (as in, lost or malformed packets don't get resent nor does it send anything back to the sender about it), so you have to implement your own mechanism for dealing with lost or malformed packets.

[flape]

That's exactly the point. TCP implements reliability but the cost under some circumstances are to high.

UDP is ureliable, so NO unncessary data are not sent back.

Requested data will be put into "UDP stream" transformed into datagrams and each gets sequence number and hash so the receiver can detect lost/malformed datagrams. And then missing data are rerequested.

[flape]

To the cognession :

sender will incrementally raise the speed to the point DROP flag is being received.

DROP flag : will be sent by the receiver when more packets in a row wont be received. The problem is if the DROP FLAG packed will be dropped (( ups ...

Improvement : Sender will rise UPspeed if the TRY TO RISE will be received.

TRY TO RISE: sends receiver if there was no dropped packet over a period of time .

- complications will come if one part of the path will be made of WiFi. Standart TCP cognession alg has problems with using the full potential of the link.

[flape]

Cognession :

the idea is not to send too many "ACK" packets. Once there is "stable" speed, no "ACK" will be sent.

[Firon]

UDP doesn't send ACKs, or any packet at all to acknowledge

[flape]

Of course not, should have use another name ...

[c4rypt0]

has anyone considered that since there is no peer to peer authentication all a user would have to do to mess up a swarm would be...

join the swarm

spoof bad traffic from each swarm member to each other swarm member

wham... everyone thinks everyone else is sending bad data.

since its trivial to spoof UDP with zero chance of being caught unless you added some sort of UDP version of the TCP handshake (or some sort of shared key) so that each user knows that the data is actually coming from the real host it would be easy to cause havoc with the swarms.

[Falcon4]

*slaps forehead*

All this bitching and moaning about a couple bytes of TCP/IP acknowledgment traffic?!

What are you on, dialup? Well, even dialup has the bandwidth to handle 50-odd bytes per second ack's at the same time as ~150 bytes/sec download. If you're going that slow, a few extra bytes per second up won't hurt you.

And if it's because you're running 20 torrents on dialup... for the love of god, get broadband.

UDP doesn't need to be used. To keep µTorrent slim and clean, I'm sure ludde isn't going to bloat it down with a whole reinvention of the TCP/IP wheel on UDP. It's just unnecessary...

Good day sir.

[Firon]

Well, the actual point of using UDP would be for UDP NAT traversal, not so much to save bandwidth or anything.

[ljubo666]

My 2 cents...

Actually, this is a good idea... TCP/IP protocol is actually very insufficient and as my prof said once... if they were able to implement it all

over again... it would be definitely different i.e. better... but we all know... to change this widely used standard it would be probably crazy

At my 4th year of Computer Sc. degree we did exactly what are you guys talking about... a better "TCP" protocol using UDP

... all including reliability of protocol (even if one side crashes completely ie. no power and manages to recover quickly enough,

the proper message would be received)... I don't remember all the details how much we manage to outperform TCP/IP regarding

efficiency i.e. less exchanged messages with the same or even better reliability... but I know this... I still have all of code in my archive...

.... OK assignment was in Java just because it is much faster to do assignments in Java and still have serious complexity... semesters

are only 3-4 months and they really put huge load on you

Anyway... the code is not that complicated... or maybe it is... I remember that we spent lot of lectures about all the aspects of the protocol

but at the end it's not that long... of course if re-implemented in C++ it would take a bit longer simply because some stuff are easier done in

Java (one more reason (not the main one, but...) why it's slower)

Ok... that was my 2 cents... if somebody (ludde) wants more info, I'm ready to provide more info... if I still remember anything

I mean, I'm neither for nor against this idea of integration of "new TCP", I'm just saying what I know from the first-hand experience...

P.S. Falcon4: It's a big difference, not only few bytes, and in this case of bittorrent protocol, savings can be big... cause you can

even extend algorithm here to even more reduce unnecessary acks...since typical connection here last for a very very long time

in computer sense of time

(note: I also have a code for marshaling messages of "new TCP" between different platforms... so for example x86 can talk to PowerPC

... for those who don't get... ah it's another topic altogether... who gets it... knows it would be needed

[flape]

I write down the numbers, ok?

For :

10KB/s download -> upload 1 KB/s in ACKs

40 -> 2

300 -> 10.

Consider the afct that many or most of users of p2p have some sort of asymetric connection and every spare byte of upload is worth trying...

PS: UDP spooofing. Could you please explain or post the link to this problem? Cause mine ISP quite strict about spoofing , e.g. nothing like this is possible(every interface has assigned/allowed MAC and IP)...

[Firon]

ljubo666: if you'd like to offer any such help (code, info or otherwise), do so on IRC

[flape]

And why is utorrent trying to be as small as possible when everybody has at least 512 MB of RAM ( joking, ... not everybody ), and doest not care about the inefficency of the TCP??? And nowdays the network is still more expensive than memory )) ( if U can afford broadband U can definatelly afford 1GB of RAM !!!

[Falcon4]

That's the mindset of a bloatware Firefox developer. Memory may be cheap but there's no reason why we need to waste it. Programs used to be able to do a hell of a lot more than Azureus could, in about the same size as µTorrent, but that is a lost art form that the creator of µTorrent is trying to keep alive.

(of course I don't mean there were BT programs back then, I just mean they had as many features in a different application.)

As such, you can run your torrent program in the background without having to worry about it taking too much memory or CPU or whatever.

There's no reason programs need to eat that much memory. Just because the space is there doesn't mean it needs to be pissed away. Hell, if programs were written as efficiently today as they were back then, you could fit your entire OS and all its data INSIDE the RAM! Too bad sleek coding is an (almost) lost art form...

[c4rypt0]

PS: UDP spooofing. Could you please explain or post the link to this problem? Cause mine ISP quite strict about spoofing , e.g. nothing like this is possible(every interface has assigned/allowed MAC and IP)...

it really is trivial. Since UDP connections dont have a TCP handshake i.e. they implicitly trust the packet to have come from where it says its come from.... then anyone can create a UDP packet and send it to anyone else looking like it came from any IP.

There are literally dozens of tools to do this.

As for you ISP blocking spoofed traffic the simple answers is that whilst they say they do in reality its very very lickely they dont and more likely theya ctually cant. Either way there are plenty of places that you can spoof from. e.g. just about everywhere

Most of the time UDP is used in applications that have 3 main interests:

1. Shifting as much data as possible

2. Getting it there as fast as possible

3. If its late or corrupt then it wont matter cause we dont want it anyway e.g. video streaming

The key is that UDP is conectionless.

I love the idea of faster P2P using UDP and NAT traversal is always interesting for many many users but until someone tells me why i couldnt just pollute the swarm with source spoofed UDP packets then i would be very wary of adopting it.

[flape]

It's quite unlikelly that someone will show such a behavior... but even though you can still sign the packets.

[c4rypt0]

i dont get you?

Are you saying that people just wont pollute the swarm out of their good nature?

Also signing packets yes i agree... but thats a solution to the problem that would need discussed etc.

[flape]

I ment that somemone would try to spoof packets in order to make someone being banned for sending bad data ... What good would it be? The bigger the swarm the better, isn't it?

Security : seq number starts at random value ... even if U could spoof packets U would have to guess the number ... So spoofing is quite out of question

I thing it would be good, if we go back to ljubo666's offer. I think we should go through the code( if it's not a secret ) and try to reconstruct the protocol...