Click here to Skip to main content
15,566,160 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi, I am developing a multi-client/single-server project that communicates through sockets.

Server Go:

The main program listens to a new connection, when a client connects to the server it's handled by a goroutine. On the goroutine I have a switch case based on which services offer to the client based on string massage. Initially, all functions were goroutine but every time the handler should wait that the goroutine is finished cause all services use sockets so I can't have two goroutines running at the same time on the same connection, so I decided to leave just a function.

Client C#

The main problem is C# because there are many ways to implements socket, I have many forms on my C# application, Initially, I pass a reference of a socket connection through all forms but I didn't like this solution, so I define a static socket class and calls send/receive on all form that needs connection using a mutex to avoid concurrence.

Should I use asynchronous sockets or is even synchronous still ok? Should I use another way to create a socket instead of a static class?

What I have tried:

I have tried goroutine, lock, waitgroup on go side.
On C# I have tried to instantiate the class and static class
Posted
Updated 21-Jan-22 3:40am

You can find an example here: Asynchronous Client Socket Example - .NET Framework | Microsoft Docs[^]

If you have a lot of traffic you also might consider queueing.
 
Share this answer
 
A serious server will be implemented with synchronous (blocking) sockets. Each socket has a thread that waits for stuff to arrive on its socket. All this thread does is put messages on a work queue that an application thread will service.

The separation of I/O and application work keeps each thread focused on a single job and allows work to be prioritized with multiple work queues. If the server is overloaded, some work should be discarded.

To prioritize or discard work, the I/O layer must let the application layer peek at each message to determine the queue on which it should be placed, or whether it should just be discarded.

If the application performs blocking operations (e.g., disk I/O, database lookups when the database might be locked), a thread pool services the work queue. The size of the pool is large enough so that a thread should always be available when many of them are blocked.
 
Share this answer
 
Comments
Member 13489621 21-Jan-22 19:36pm    
And on the client-side, should I use only one socket with synchronous calling? A static class socket it's good if I have a lot of forms on my c# application?
Greg Utas 21-Jan-22 21:11pm    
I can't see the need for more than one socket unless you're communicating with different servers, when it might simplify things. Separating the socket (I/O) from the application is still a good idea because the I/O thread waits on the socket and the application thread waits for user actions like keyboard inputs or mouse events. When using more than one thread, watch out for critical sections! Part of the motivation for separating things is to keep each thread focused on a single job, without having to multiplex various responsibilities.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900