Hey.

Client.
- Creates a UdpClient.
- Starts a Listen-Thread for listening at the server with UpdClient.Receive

Server.
- Creates a UdpClient.
- Creates one thread for listening to messages
- and one Thread.Timer (with function assigned to it) for sending out positions of every client to every other client.

It works and so on. But it seems like the server will stop sending messages after a while. I counted the messages sent. When i have 1 client it will send around 60-100. If i have 5 clients, it will send 20-30.


Error could therefore be Either the UdpClient, The threads or the Timer (with function assigned to it..)

Could not find anything on the web regarding this.


[sub]Also i think i found a bug on the forum. If account is blocked because of password-misses - you can reset password to log in. Hehe.[/sub]

Well i have narrowed it down to the Timer function, wich is pretty much improvised i think. (Mod can probably move topic now..)

public void startServer()
{
udp = new UdpClient(80);
listenthread = new Thread(listenAndHandleMessages);
listenthread.Start();
...
...
Timer timer = new Timer(new TimerCallback(updateAndSendMessages), null, 0, 10);
}



void updateAndSendMessages(Object obj)
{
// send to clients.
}


I use null and i have an parameter "object" in the function. I do not use it, do i have to use it in some way? I mean, the code works. But stops fireing the timer for some reason..

First, I think the timer variable should not be local like how you have it. It should be a class member or a global variable, depending on the rest of the code, so you keep an active reference of it alive so it is not GC'ed. I can't say I know for certain if that would cause a problem or not in the long run, but that looks really suspicious to me.

Second, when a timer seems to go poof, it is usually because you have a deadlock somewhere in the system or unhanded exceptions. Since you are using threads, I'd suggest you start combing your code for any possible places of deadlock or thereof lack of locking that might cause issues.

Ah. It was because of the GC. Thanks!

[s]And yes i probably have deadlocks. Especially when i try to read from a dictionary and some other thread tries to add in it. I do lock it with lock(){} and it seems to happen only sometimes..[/s]

edit: seems like the code will stop here when i have a bunch of clients. 100 clients = stop. They wont receive messages.. When i have like 5 it works forever.
I use lock(){} every time i use my collections, adding reading and such.. Is this bad?



void listen()
{
while (true)
{
Console.WriteLine("listening");
byte[] data = udpclient.Receive(ref ipendpoint); <--- here i guess..
if (data.Length != 0)
{
char[] splitter = { ' ' };


[s]Basically. What should i use for being able to listen (aka add clients while running) and sending (send positions to other clients) also while running?[/s]
[s]
[/s]
The code does work. But i used my external IP wich made the messages get lost i assume. Changed it to localhost and now it works again. With 100+ clients.

It's hard to say without knowing more specifics of how everything is setup, how you are testing, and what the rest of your code looks like.

If you are trying to run 100 clients on one PC and your UDP messages are too large or are being sent too fast, it's possible you are simply overwhelming your network. If you have a router that has any features for managing traffic, it's possible it's opting to simply drop most of the packets. Alternatively, if you are trying to run a stress test between two different networks, it's possible your ISP has certain limitations on the UDP traffic and will drop most of it since it might look like "suspicious activity". Those cases are usually triggered when testing with the same (or really similar ) packet over and over so it looks like an attack. You should also check out the Forum FAQ because it provides some more details regarding UDP and NAT punch through that you might have to make use of as well.

If you say it works fine on localhost with a lot of connections, then I'd start considering network issues first rather than specific code issues. However, you do still need to make sure you are catching exceptions where appropriate and add enough debugging information to know what is going on for sure. When it comes to lock and collections, you will want to read this: Why are thread safe collections so hard? It goes over the basics of a lot of mistakes people make with their implementations. There are also other important resources for using threads and locks, but it's something you just have to research and learn if you are going to be making use of them.