sockets : Writing and reading on the same thread with events ?

[Alessandro De Simone]

Hello,

I have to exchange data on a socket within a unique thread in dotnet.

My idea is to use a queue for writing requests and a ManualResetEvent to
detect in the socket thread when one (or more) elements are added (from
the main thread) to the queue (look at my pseudo code bellow).

But is it possible to obtain a WaitHandle to detect when there is data
available for reading in the socket ? I know I can use the
"System.IAsyncResult.AsyncWaitHandle" from a "BeginRead", but this
method use an another thread.

In Win32, you could use "WSACreateEvent" and "WSAEventSelect" to get a
HANDLE used in "WaitForMultipleObjects".

Am I missing something ? Thanks

Alessandro


---
WaitHandle[] ReadWrite = new WaitHandle[]{SocketReadEvent, QueueEvent};

while( 1 )
{
int index = WaitHandle.WaitAny(ReadWrite);

if( index == 0 )
{
// read an information (size is known) from the socket
}
else
{
// write the queue content on the socket
}
}

 

[Alessandro De Simone]

Thanks for the answer.

You have to provide a callback, but there's no rule that says you have
to do anything in the callback. You could just pass an empty anonymous
method, and wait on the handle you get from the IAsyncResult.

Correct me if I'm wrong, but the BeginReceive method use another thread
even when you don't specify a callback. The callback is just a delegate
called at the end of the thread (potentially in another different
thread!). Because you have to call EndReceive, most of the time the
callback is very useful.

I guess for me the real question is why is it so important that you read
and write on the same thread? The Socket class itself is thread-safe,
so you can write from one thread and read from another. Or you can just
use the callback for BeginReceive(). There's nothing in your post that
suggests a need for the requirement you've stipulated, so it seems to me
that meeting that requirement is putting the cart before the horse.

I want to have a minimum overhead in my application. I don't need to
send and read data at the same precise time. I make the assumption that,
most of the time (but not every time), a client send a message and wait
for an answer before sending another.

So, if a second thread isn't necessary, why should I use it ? I don't
want to use a second thread (for every read operations) only to obtain a
handle with which I can wait the event "Data Available". The synchronous
"Receive" already wait for this kind of event when the protocol stack
buffer is empty.

I my opinion, my solution is pretty simple (and feasible on Win32).

Now if you are sure that's impossible to have a simple event "Data
available on socket" with DotNet, I will use BeginReceive unwillingly...

Thanks