I am new to .Net, but familiar with VB 6 winsock, and I am trying to figure out the networking in .net beast.
First, what I am trying to do:
I need a server that can handle a small amount of simultaneous client connections (maybe 10-20). The server will be sending/receiving work to/from the clients. I want to avoid using multi threading because the threads would be accessing data structures while talking to the clients, and I don't want to mess with thread locking (a little bit over my head right now), but I also need the server to be able to do background processing when not actively serving clients, so I don't want to block and wait for connections. I have looked at the possibility of using remoting but I think it is way too complicated for my application. I would prefer to use the tcpclient and tcplistener objects if possible and not muck around directly with sockets.
My plan:
My understanding is that I can use a tcplistener to queue connections, whilst periodically checking for any pending connections. I would accept any connections and assign them to a new tcpclient object, which then gets put into a generic collection that the server will loop through to process them. Essentially, I would have one thread but be emulating multi threading.
So...are there any obvious problems with this approach? Am I misunderstanding the objects and how they are used? Is this going to be entirely too unstable using one thread?
I have looked at the possibility of using backgroundworker, but I don't really understand it enough to know if that would be a better option.
Any thoughts?
First, what I am trying to do:
I need a server that can handle a small amount of simultaneous client connections (maybe 10-20). The server will be sending/receiving work to/from the clients. I want to avoid using multi threading because the threads would be accessing data structures while talking to the clients, and I don't want to mess with thread locking (a little bit over my head right now), but I also need the server to be able to do background processing when not actively serving clients, so I don't want to block and wait for connections. I have looked at the possibility of using remoting but I think it is way too complicated for my application. I would prefer to use the tcpclient and tcplistener objects if possible and not muck around directly with sockets.
My plan:
My understanding is that I can use a tcplistener to queue connections, whilst periodically checking for any pending connections. I would accept any connections and assign them to a new tcpclient object, which then gets put into a generic collection that the server will loop through to process them. Essentially, I would have one thread but be emulating multi threading.
So...are there any obvious problems with this approach? Am I misunderstanding the objects and how they are used? Is this going to be entirely too unstable using one thread?
I have looked at the possibility of using backgroundworker, but I don't really understand it enough to know if that would be a better option.
Any thoughts?
