Quote:Original post by wodinoneeye
*** Lots of UDP issues ***

At this point it is worth saying that if you choose to go with an existing middleware solution, such as enet, or RakNet, all these troubles will magically waft away...

Quote:Original post by swiftcoder

Quote:Original post by Erik Rufelt
You will never receive corrupted data, not even on the internet, but duplicated and lost packets are possible. On the internet it's to be expected, and on LAN it's still possible. It's extremely unlikely on a LAN though, so you can pretty much ignore it if you want to, you probably will never lose a packet while testing on your LAN.

The downside is that actually testing your UDP code on a LAN can be difficult. A trick I use to to test my UDP code while running on a LAN is to flood the LAN with junk data - which will cause many of your legitimate packets to be lost. I find that netcat'ing /dev/zero between the test machines does a wonderful job [smile]

One way an author in one book mentioned was to have a testing mode which randomly discarded packets as they came in. And by upping the probability that any one packet was disascarded you could really hammer your mechanism.

Something I just thought of would be another scenario where N packets in a row would be discarded or in another packets would be held for a while and then inserted (probably could randomly duplicate them as well).

I seem to recall there are test programs that do this kind of thing for big $$$
but that it wouldnt be too hard to have a computer in the middle running a program that did stuff like this (basicly a packet forwarder that had all these fun behaviors controllable).

Quote:Original post by wodinoneeye
One way an author in one book mentioned was to have a testing mode which randomly discarded packets as they came in. And by upping the probability that any one packet was disascarded you could really hammer your mechanism.

Something I just thought of would be another scenario where N packets in a row would be discarded or in another packets would be held for a while and then inserted (probably could randomly duplicate them as well).

I seem to recall there are test programs that do this kind of thing for big $$$
but that it wouldnt be too hard to have a computer in the middle running a program that did stuff like this (basicly a packet forwarder that had all these fun behaviors controllable).

Ja. I was considering implementing a proxy server which drops a configurable percentage of packets, and both delays and reorders others. Unfortunately, free time is at a premium these days...

>wodinoneeye

I am working on not delivered or duplicated packets too. There are two types of packets now, important and not important packets. important ones are kept in an array and send again and again until clients responses with something like "packet number 42 is delivered". clients also checks old packets to be sure that packet is not duplicated

well it works on lan :D I randomly rejects some important packets from client and server send same ones again :) I am on at a campus for now, so I won't be able to test it until I return home

I am not sure about how complex network I will build for this project. In the beginning I decided to use tcp and send state of the clients in each frame, and server send them to all other clients. I decided to only work on LAN so bandwidth wouldn't be a problem. But now I decided to use UDP packets and handling network myself.

>swiftcoder
I don't like using a library which I can't implement. I am working on this project purely to get better at game programming and I don't believe depending on libraries too much will help me.

Quote:Original post by shultays
>swiftcoder
I don't like using a library which I can't implement. I am working on this project purely to get better at game programming and I don't believe depending on libraries too much will help me.

Fair enough - I used to feel that way too. However, I suggest you purchase a good textbook on networking (Tanembaum's Computer Networks is definitely worth a look), as reliable message transfer is a real can of worms.

Quote:Original post by wodinoneeye
I was considering implementing a proxy server which drops a configurable percentage of packets, and both delays and reorders others. Unfortunately, free time is at a premium these days...

In one of the Game Programming Gems (I think it was GPG3) was a program which was working as a proxy and it was droping, duplicating and delaying UDP packets.

you have to send your packets to a different ip/port than intended, but for my fast testing this was a great tool.

You get the tool you need and a good book to read for not to much $$.

Somewhere in your code, there will be a call to sendto(). You can replace that call to sendto() with a call that will randomly drop, delay, duplicate or re-order packets. It's not perfect, but when done right it'll find 80-90% of the bugs you'll get by running on the wider internet.

Note that some things will be hard to replicate exactly, like the return code from sendto() for cases where you got an ICMP "address not reachable" message (meaning the client terminated), but it sure beats doing nothing, and is very simple to implement!