[quoted text, click to view] > 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.
[quoted text, click to view] > 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.
[quoted text, click to view] > 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.
