Server TCP Broadcast/Multicast to Clients? [C#/CS 2005]

[Shaitan00]

I am encountering some performance issues with my SERVER<->CLIENTs tcp communication and I think it is related to how I perform my communication.

Specifically - the way it works today - I have tried the following two approaches:

1- Foreach Client the main form launches (create and start) a thread per client (so many threads), each thread performs the tcpclient connection, sends the data, and then close.

2- Main thread launches a single thread (create and start) which will loop through the list of clients (tcpclient connection, send data, close) and send the data

In both cases I use TCPClient & NetworkStream to perform the actual transfer (so create a TCPClient to the Client with the corresponding IP and PORT and then use the Network Stream to send the data itself).

 

As mentioned this seems to work a little slow so I was trying to look at ways of improving the code (as there is a LOT of information passed between the server and the 1-100 clients depending)...

So I did some reading and found the concepts of "BROADCAST" and "MULTICAST" - but I have no clue if these can apply to my situation (tcp) ...?

 

Therefore I am here asking for advice or confirmation - if either option (1) or (2) (mentioned above) are the CORRECT way of hanlding the situaton then I know I am on the right path.

But I thought there must be a type of concept where I can just BROADCAST or MULTICAST the data to a single TcpClient (or socket, or something) that would handle sending the information to all clients automatically.

Wouldn't that be the CORRECT approach? How is this typically resolved?

 

I am looking for any kind of advice on how to proceed...

Any ideas, hints, and help would be greatly appreciated, thanks

[PlausiblyDamp]

If you wish to communicate with multiple clients and can live with the possibility of delivery failure then using Udp is a definite possibility.

 

The UdpClient supports the use of Multicasting via it's .JoinMulticastGroup and .DropMulticastGroup methods.

 

The sending application could use code similar to the following to send data. When dealing with multicasting you need to define an IP address within a specific range (this has nothing to do with the actual address assigned to the network card itself) http://www.tcpipguide.com/free/t_IPMulticastAddressing.htm gives a quick idea of the ranges you should choose from.

 

IPAddress groupAddress = IPAddress.Parse("239.1.2.3");
int remotePort = 1234;
int localPort = 1234;
IPEndPoint remoteEP = new IPEndPoint(groupAddress, remotePort);
UdpClient server = new UdpClient(localPort);
server.Send(data, data.Length, remoteEP);

 

clients would then need to register with the same group address like so...

IPAddress groupAddress = IPAddress.Parse("239.1.2.3");
UdpClient udpClient = new UdpClient();
udpClient.JoinMulticastGroup(groupAddress, 10);

 

the first parameter defines the address of the multicast group as used by the sending app while the second is how many routers will pass the information along before it is dropped from the network.

[Shaitan00]

I assume this CANNOT be done with TCP due to its connection-nature with the client? I cannot use UDP as I need to ensure the data makes it across correctly (this is for a game, can't miss a beat) - so I assume creating a thread per client (my option #1) would be the best bet correct?

[PlausiblyDamp]

Afraid not - udp doesn't guarantee delivery, there is nothing to stop you using your own mechanism to check / resend as appropriate and still use udp but it will increase the complexity / work for your game.

 

Out of interest what kind of game / number of users are you talking about as any game that needs to support a lot of network clients is going to struggle. Is there anyway you could reduce the information being transmitted or handle multiple sockets on a single thread?

[Shaitan00]

PlausiblyDamp: Then I guess I'll stick with TCP as-is.

It is a 2D Bomberman (old Nintendo) style game - SERVER<->Client based and there can be up to 30 players/clients at a time...

 

Ya - I am looking into alternatives to make it go faster (such as reducing the data sent, the refresh time, etc...) I just thought this was a good place to try and start looking ....

 

Would using a single thread with multiple sockets really help?