Aysnchronous Vs. Multithreaded Client-Server application

Aysnchronous Vs. Multithreaded Client-Server application

• hypo

  Thanks Peter,

  In MSDN there is an example of Asynchrnous socket , in that ManualResetEvent() is used for letting know other Async calls to when other call is finished and when you can begin ur own call , is it all , or is there any other implicit purpose too of using ManualResetEvent()

  I mean to say I dont want to use ManualResetEvent() as my server would be having multiple clients connected and I dont want any dellays in function calls , if I decide not to use it , would there be any problems

  Once again thanks alot for your support and help .

  Regards,

  ZINK
  
  
  
  
  

  
  

• Fekih Mehdi

  ZINK_C wrote:

  Thanks Peter for your valuable advise. one more thing , like in usual Client-Server architecture it is pre-decided that (in most examples) that client will send some data and server will respond back some data or vice versa ... what if i dont want this scheme.. I don t want to predefind that who will send first and who will respond.. once conection is established client or server ..who ever wants to send any data .. it could. how to achieve this scheme I'll appreciate you advise. Thanks ZINK_C

  It's completely up to you what data, and its order, that your server and client communicate with. The socket server has to be sitting there waiting for connection requests--forcing the client to make the first move. Once that connection is made you can do whatever you want. The server can send the first data, or the client.
  
  You'll have to establish a protocol and probably a state engine, if you want to deal with more than one state at a time. So, with regard to "who ever wants to send any data", they'll have to send data that the other end can understand and within a context for it to understand the data.

  I don't have a problem with http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx

  
  
  

• Erik Bertrand

  The threadpool has a default limit of 20 threads per processor. If you plan on supporting more than 20 connections (and keep in mind the framework is free to also use some of those 20 threads) then you'll quickly hit a limit of concurrent connections.

  Using a thread per connection is not very scalable. More than 50 or so and you'll probably start to seem some sever performance problems.
  
  Asynchronous IO is the way to go if you want to write a scalable server (I.e can handle "infinite" connections and is limited only by hardware).
  
  Chris Mullins wrote a good article on a scalable socket server and his experiences starting with the multi-threaded route: http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx

  
  
  

• @nt

  I got that link , thanks for it.

  Peter Asynchronous IO uses threads from ThreadPool , right and is there any limit for threads runing from that threadpoll and how efficent are they

  And one more thing , Exception handling ... In what about if exception ocures between BeginXXX and EndXXX method call how good Asynchronous methods are when we talk about exceptions

  Thanks in advance for your valuable help and support.

  ZINK

  
  

• DBRICHARD

  Peter that link you mentioned is not opening ...

  http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx

  its not working ........

  
  

• skipinator

  ZINK_C wrote:

  I got that link , thanks for it. Peter Asynchronous IO uses threads from ThreadPool , right and is there any limit for threads runing from that threadpoll and how efficent are they And one more thing , Exception handling ... In what about if exception ocures between BeginXXX and EndXXX method call how good Asynchronous methods are when we talk about exceptions Thanks in advance for your valuable help and support. ZINK

  Asynchronous IO uses completion ports and not .NET thread pool threads on NT and greater systems. It's true that Windows will use threads from a pool to service IO read/write completion events; but those don't come from the .NET thread pool. They are designed to be highly scalable. I terms of being able to handle dozens, if not hundreds, of simultaneous socket connections they're extremely efficient. (that's relative, as it's really the only way to handle that many simultaneous connections).
  
  Depending on the exception, the EndXXX call would "re-throw" the exception. I most cases, if an exception is raised on a background thread it is simply lost.
  
  

• edwaldo

  Thanks Peter for your valuable advise.

  one more thing , like in usual Client-Server architecture it is pre-decided that (in most examples) that client will send some data and server will respond back some data or vice versa ... what if i dont want this scheme.. I don t want to predefind that who will send first and who will respond.. once conection is established client or server ..who ever wants to send any data .. it could.

  how to achieve this scheme

  I'll appreciate you advise.

  Thanks

  ZINK_C

  
  

• Martinp23

  ManualResetEvent is only one way of implementing that example. In a socket server you wouldn't normally have a main thread performing the logic--for the very reason of many clients.
  
  You'll notice in the Asynchronous Client Socket Example the ManualResetEvent's are signaled (via the Set method) in ConnectCallback, ReceiveCallback, and SendCallback. There's no reason why those callback methods can't just call another method to perform logic required. In the case of ConnectCallback, it would just perform Send(client,"This is a test<EOF>"); after EndConnect. That would be chaining each asynchronous call together.
  
  
• Aysnchronous Vs. Multithreaded Client-Server application