1

Out of curiosity, what events in TServerSocket/TClientSocket are fired if it is a ThreadBlocking type?

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I'm not even remotely an expert, but I wouldn't expect any events to fire for synchronous sockets. – David Heffernan Feb 19 '13 at 14:44
  • @David, neither me, but events like for instance [`OnClientRead`](http://docwiki.embarcadero.com/Libraries/XE2/en/System.Win.ScktComp.TCustomServerSocket.OnClientRead) must be fired, otherwise the server side wouldn't even be able to read anything from the client. – TLama Feb 19 '13 at 14:50
  • @TLama Not the way I read the documentation. As I read it, blocking sockets don't use those events to read and instead use `TWinSocketStream`. – David Heffernan Feb 19 '13 at 14:54
  • i am using TWinSocketStream, but for example the OnGetThread event is firing... (including OnListen, OnThreadStart/End), what others ? also where could i find the documentation ? –  Feb 19 '13 at 14:59
  • @David, from the note; *"If ServerType is stThreadBlocking, make sure that all code in an OnClientRead event handler is thread-safe."*, so it is fired, you just need to use a different reader to get data when this event occurs. – TLama Feb 19 '13 at 14:59
  • 3
    @user, documentation [TServerSocket Events](http://docwiki.embarcadero.com/Libraries/XE2/en/System.Win.ScktComp.TServerSocket_Events) and [TClientSocket Events](http://docwiki.embarcadero.com/Libraries/XE2/en/System.Win.ScktComp.TClientSocket_Events). – TLama Feb 19 '13 at 15:01
  • Event driven synchronous programming? Weird indeed. Is Indy the same? – David Heffernan Feb 19 '13 at 16:26
  • @DavidHeffernanת Indy is the same. I don't see anything odd about it. – kobik Feb 19 '13 at 20:38
  • @DavidHeffernan: TServerSocket in blocking mode does fire `OnClientRead` and `OnClientWrite` events by default, just within the context of an internal thread, to preserve the event-driven model in both modes. – Remy Lebeau Feb 19 '13 at 22:56

1 Answers1

5

TClientSocket in blocking mode fires all of its events except for OnRead and OnWrite. Also, the OnDisconnect event is not triggered on a remote disconnect, only when the client closes its own end of the socket. It is the responsibility of code that is reading/writing data to detect these socket states. Readibility is detected via TWinSocketStream.WaitForRead() or the WinSock select() function. Writibility is detected via the WinSock select() function only. Remote disconnect is detected by first detecting readablity and then TCustomWinSocket.ReceiveBuf() or TWinSocketStream.Read() returning 0.

TServerSocket in blocking mode fires all of its events by default. However, if you derive a class from TServerClientThread that overrides the virtual ClientExecute() method, and then return an instance of that class from the OnGetThread event, then you lose the OnRead and OnWrite events and have to use similar logic to TClientSocket in blocking mode to detect those socket states.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Last question, inside the ClientExecute, i handle ONLY Read/Write, correct ? –  Feb 20 '13 at 16:50
  • If you override `ClientExecute()`, then you become responsible for managing the connection. You need to exit from `ClientExecute()` if either `Terminated` is true or the socket is disconnected (the default implementation checks if `ClientSocket.Connected` is false, but there are other ways to detect a disconnect as well). Anything else you do inside of `ClientExecute()` is your own business. – Remy Lebeau Feb 20 '13 at 17:30
  • I thought I did answer your question - if you override `ClientExecute()` then you become responsible for pretty muh EVERYTHING related to that connection, which includes reading and writing. – Remy Lebeau Feb 20 '13 at 17:49