TCP/IP app Desgin Question

[MR]

this is a question on how to design an TCP Listener application.
background:
There will be several threads that listen on several ports (one per port).
when another app requests to connect, the connection will be accepted. then
messages will be received and passed to the main thread via a delegate or
event for processing. Messages will also be sent in return to the other
application in an asynchronous manner.

Questions:
1) from what it seems to me, delegates are thread safe but events are not.
is this true? should i use delegates to call back to the main thread rather
than events?

2) what is a clean way to have the main thread pass a message to a listener
thread to write messages? (a reverse call back)

thanks for your help
m

 

[Warnat]

There will be several threads that listen on several ports (one per port).

when another app requests to connect, the connection will be accepted. then
messages will be received and passed to the main thread via a delegate or
event for processing. Messages will also be sent in return to the other
application in an asynchronous manner.

So, you have one/more listening socket.
In your accept-callback-method you get a new instance of the connected
socket ( ListeningSocket.EndAccept(...) ).
This new socket is your connection to your other apps.
Then I do always create a new class, the new connected socket is one of the
construction parameters, and let the connection-class do further processing.

1) from what it seems to me, delegates are thread safe but events are not.

is this true? should i use delegates to call back to the main thread rather
than events?

events are raised with the help of a delegate (only VB-programmers seem to
use
2 terms for the same thing) which is a thread safe operation.

2) what is a clean way to have the main thread pass a message to a listener
thread to write messages? (a reverse call back)

the connection-class can raise events (what means: call a delegate) to send
messages, information or state-changes to the main thread.

And if your main thread holds an ArrayList (or any other collection) of your
connected-class, your main thread can access them all in return
(e.g. for closing them all).

Your thread-troubles will start, when more than one connection-class sends
events
to the main thread and properties, variables etc. from the main thread are
not thread
safe. To prevent this you can use locking technics (e.g. the Monitor -
class).

hope that helps,

r.w.

p.s.: What did trouble myself was the fact, that the asynchronous methods of
a socket
are not really events/delegates at all.