We have client-server application where all clients also talk to each other via TCP (TcpClient + TcpListener on each client)
So, when client A does something – it sends message to clients B, C and D and then waits for response. This get’s kind of slow with many clients (like 20 now) Especially when clien B dies – client A waits for until times out.
Is there any better way maybe broadcast package to everyone at the same time? I know everybody’s host names, etc.
I just need to send message and know if they did/didn’t receive it successfully.
What my options are?
I suggest to completely switch off the strategy and use some message bus that does this in a reliable and performance tuned way. I’m happy with ActiveMQ, that even if it is implemented in Java works in C# very easily. If you want something pure .NET take a look at NServiceBus or Rhino Service bus. I know that you probably feel the task of dispatching message between client is easy and you can do it yourself, if you want to do reliable in production is better if you leverage the someone else effort and relax yourself. It will be very frustrating trying to solve communications bugs when the app run at the customer site. Ignore this if you are writing a competitor message bus, of course 🙂
All these solutions allow you to have the Job done by just the effort of reading the documentation. Do some test app “in vitro” before going to replace the production code just to gain the necessary confidence, and then replace the hard TcpClient. I’m quite sure you can find a truncate point to insulate just the message datagrams where place the new strategy on.