UDP/IP multicast for P2P

>>57071042
>UDP
>for p2p
nigga

>>57071115

Why not?

>>57071115
>>57071133


*Why is that a bad idea?

>>57071115
Why would you need TCP?

>>57071133

TCP works by sending you data piece by piece. Your computer sends an acknowledgement every time it gets a packet. If the server doesn't get that acknowledgement it assumes the packet got lost or fucked up somewhere and sends it again until your computer has everything it wants.

UDP just sends packets nonstop and doesn't care if you get them or not. This is bad in P2P because if either of your connections mess up at all then the whole file is fucked.

>>57071425
Would something like QUIC be a better compromise?

>>57071337
please read about what TCP does and why it's commonly used.

>>57071425
UDP is actually alright for P2P. Just ID the packets and rerequest the ones you never got. Checksum stuff for integrity.

>>57071337
You wouldn't, you don't need flow control. There's no need to get the data in order, just to get it.

>>57071653
>Just ID the packets and rerequest the ones you never got. Checksum stuff for integrity.
you do realize that's exactly what TCP does and you're just reinventing the wheel instead of using the proven system?

>>57071653
You may never get the complete file if you try that method. You can end up endlessly getting a wrong checksum if even one packet drops. TCP ensures that all dropped packets are sent again and received.

>>57071716
God I was on a robotics team that needed to make a video feed for the robot work on a 2G connection. Fuckers thought UDP was a good idea to do the following:

>first packet should be a "start transmission" packet
>we should send that packet 50 times just in case it's not received the other 49 times, we'll just write in code to ignore the rest
>each UDP packet should also include a checksum verification
>at the end of each burst, we should send a "end transmission" packet that states how many packets were sent and an overall checksum of the whole transmission
>we should also send the end transmission packet 50 times just in case.


>we should identify each packet so that if a packet gets lost we only have to transfer that single packet
>no that's retarded, why would you waste those extra bits? It's not like the connection will be poor, dropped packets are an uncommon occurrence in 2k14.

Two years of therapy still hasn't unfucked me from that conversation.

>>57071716
Nope, TCP does a shit ton more you don't really need. There's a lot of overhead.

>>57071749
You must have missed the part about "rerequest the packets you never got". Also, data loss for video and audio files is no big deal, and that's what P2P is used for anyway.

>>57071792
>Nope, TCP does a shit ton more you don't really need.
Yes.
>There's a lot of overhead.
No lol

>>57071787

>be in a team full of idiots who can't use UDP properly and know jack shit about telecom
>blame UDP instead

Wow, I can see why you were on that team too.

>what are acknowledgements?
>what is dallying?
>let's just send things many times instead

UDP is used for video feeds all the time, and I'd love you see you get TCP to work without constant video lockups on a 2G connection.

>>57071787
I'm so sorry for you anon

>>57071821

>no lol
OK son, I can see you've never done any network programming.

>unironically considering a transport protocol that's gonna force you to set up a new connection for every single request on a request/reply use-case
You are a little baby.

>>57071840
Don't be, he's an idiot too. See >>57071833

>>57071792
You said you wanted to checksum things for integrity. If you don't care if packets are dropped then why do you want to checksum? Stop moving the goal posts to suit your argument.

>>57071653
So what...TCP?

>>57071833
>think I'm blaming UDP instead of recalling a triggering story
>getting this defensive over a protocol

Victim complex sure is strong in you, Anon.

>>57071863
>every single request on a request/reply use-case
that's ONE use case.
reliability is more important than latency for most data transfers.

>>57071883
You moved the goalposts first here >>57071749, faggot, I just moved them back where they were.

Most p2p torrent traffic is µTP which is UDP based

https://en.wikipedia.org/wiki/Micro_Transport_Protocol

There are many other p2p systems also use some form of rUDP, they prefer UDP over TCP because of udp hole punching technique to traverse NATs

>>57071042
Multicast is basically broadcast TV. It's the opposite of P2P.

It was designed to let 100+ users receive the same data at the same time without overloading the broadcaster.

P2P basically solves the same problem by distributing unicasts instead of multicasting.

This has the additional benefit of not requiring broadcast timeslots, and more importantly, it actually works over the internet which multicast rarely does due to lack of interest.

>>57071042
Good concept but in practice the whole network will be slowed down to the speed of the slowest link