Hi Chirs,
Thanks a lot for your reply and article.
First, a basic general question, when will the callback method be called?
Right after BeginReceive() or when the data is available? It shoulb be
called in the same thread which receives data and is called after data is
available, right?
Is that possible to show a few lines sample to demonstrate your idea?
For stage 3:
Is that(if not, what about)per Processing Queue per client/socket?
And where we put the IAsncResult in the queue? From stage 3 diagram, seems
this is done inside BeginReceiveCallBack method. What about we put it into
queue by code immediate follow socket.BeginReceive().
Between the EndRecevie BeginReceive, the socket is not receiving data (if
socket buffer is full) and could block client. Is this the same case for
stage 2 and 3? So the stage 3 does not solve one of the problem stage 2 has?
So is that better to take processing time out of time between EndReceive and
BeginReceive? That is call BeginReceive right after put IAsncResult in the
queue, instead call it at the end of process.
And clients send different kind of message and vary in size, when I call
BeginReceive, how can I specify the size? How can I make sure I won't get
into the middle of message, e.g. get 1.5 message in byte[]?
BeginReceive will use thread in thread pool. And for threads that processing
queue, are explicitly created by our code, right?
But if as I said, call BeginReceive right after put IAsncResult in the
queue, then we never explicitly create any threads and we seems call
BeginReceive more frequently and use more threads in thread pool. Is this
right statement?
Thanks a lot!
Ryan
"Chris Mullins" <cm******@yahoo.comдÈëÓʼþ
news:eU**************@TK2MSFTNGP03.phx.gbl...
"Ryan Liu" <ad********@online.sh.cnwrote:
Whew I use async I/O methods, is try to reduce thread I am using in a
C/S
application ( I use one thread per client).
But BeginXxx method will use a thread, then my reducing thread intention
will go vain?
The Begin/End methods don't use threads in the same sense that your "1
thread per client" uses threads. They instead leverage an IO Completion
Port
and give you an efficient thread scheduling mechanism.
For some analysis of building a (very) big socket server, see a blog entry
I
did a while back:
http://www.coversant.net/Default.asp...=88&EntryID=10
--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins