Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
I’m in process of familiarizing with Chilkat Socket writing my first multiclient server.
For now it seems to me that Socket is more oriented on client side than on server side.
For example, there is no event ‘on connect’ or I can’t find it in documentation. Client can easily survive without this event, but listening socket (server side) needs it. This is my opinion.
How can I know that I have new client connected?
The solution is to write a separate C# background thread that is a simple loop where the listener socket accepts connections and hands the connected socket to something else -- it all depends on what you design.
For example, it may be that a shared Chilkat.Socket object (i.e. shared by both foreground and background thread) is used as a container for connected sockets, and the accepted connection is added to it. After adding the socket, the background thread might signal the foreground thread, or perhaps nothing is necessary since the newly added socket will be included in the next call to SelectForReading.
This workaround can be used also with other missing events like ‘on accept’, ‘on receive’, ‘on disconnect’, ‘on error’.
For one application this should be acceptable, doing the same in all future applications is not very comfortable way to handle client connections.
For us is more easier to have events, do you plan to implement them?
Think more deeply about the events, threads, paths of execution, etc.
What is an "event". In this sense, it is simply a callback. What is making the callback? Is it your UI thread? If so, then how does the UI thread know about sockets?
Is the "event" simply a callback into your application from a synchronous API method call? This is usually the case.
Your app calls method ABC, which executes instructions, makes a call back into an application-provided callback
function, that function then returns, returning control back to method ABC, then ABC eventually returns
and the path of execution continues with your app code.
How does some extraneous "event" just occur? What is calling it? You just can't expect magic to happen. A computer program runs one instruction after the other. Each thread has a path of execution. A magical "event" coming from some magical non-existent path of execution cannot just appear.