Hi,

I am converting an existing TCP server application that uses the winsock control from VB6 to vb.net. The application runs as a service and communicates with approximately 500 clients. Each client is connected for long periods and has occasional conversations with the server.

I have been reading about the socket, tcplistener and tcpclient classes in .net. I was dissappointed to see there do not appear to be any events in these classes and that it seems the closest equivalent to the DataArrival event is to do an asynchronous read, processing the received data in a separate thread - although I would prefer to be asynchronously notified of data arrival as I don't want to poll 500 clients repeatedly.

Having a separate thread for each client connection seems excessive and would add unnecessary complexity to the application, which currently runs quite happily as a single thread. The server maintains complex data structures for each client and does other work while it is operating and I don't want to have to make all of this code thread-safe.

One idea I had was to read the data in a separate thread and somehow fire an event in the main thread to let it know that data is available, but I don't know whether this is considered an acceptable thing to do in a multi-threaded application, or whether there is a another way to do this. I should add that I'd like to avoid excessive change to the application - I can't afford the time to completely re-engineer it unless absolutely necessary.

I also considered trying to use the existing winsock dll/control via interop but I would like to go fully to .net if possible.

I'd appreciate any suggestions about the best way to approach this in .net.

Thanks

In case anyone has interested I have confirmed that my intended approach was reasonable. Here are some brief comments that might help others:

Reading from sockets:- It appears an async read (BeginRead) is the way to do this, although the Microsoft documentation for EndRead has a horribly misleading example (discussed elsewhere). The call back allows you to do the same thing as a DataArrival event.

Events:- Event handlers run in the same thread as they are raised (unless your main thread is a windows form in which case you can use Invoke but this is no good if you are writing a service application).

Timers:- For windows NT service applications you can't use the windows timer component. It will let you create one and everything appears ok but it won't fire. Use System.Timers.Timer instead.

Threads:- It also appears that I need to deal with multiple threads whether I want to or not, because both the asynchronous reads and the VB.NET timer class run their call back functions on separate threads. I use the Monitor class to synchronise DataArrival activities with the main thread activities and other timer activities.