CSocket
in [MFC]
|
From: "Bill Brehm" <<don't want any on 14 Dec 2005 04:32 I am trying to understand CSocket. I don't think I like the idea of using a CSocketFile and a CArchive. Can CSocket be used without them like I would use CAsyncSocket, but still giving the benefits CSocket offers? I looked in the sample files Chatsrvr and Chatter. Both use a derived version of CSocket so they can override OnReceive() or OnAccept(). Is this required to be able to use CSocket without CSocketFile and CArchive? Thanks.
From: Mark Randall on 14 Dec 2005 06:38 WARNING: CSocket is broken. Do not use CSocket More than your lifes worth, it. -- - Mark Randall http://www.temporal-solutions.co.uk http://zetech.swehli.com "Those people that think they know everything are a great annoyance to those of us who do" Isaac Asimov "Bill Brehm >" <<don't want any spam> wrote in message news:%23XtyMFJAGHA.1288(a)TK2MSFTNGP09.phx.gbl... >I am trying to understand CSocket. I don't think I like the idea of using a >CSocketFile and a CArchive. Can CSocket be used without them like I would >use CAsyncSocket, but still giving the benefits CSocket offers? I looked in >the sample files Chatsrvr and Chatter. Both use a derived version of >CSocket so they can override OnReceive() or OnAccept(). Is this required to >be able to use CSocket without CSocketFile and CArchive? Thanks. >
From: Scott McPhillips [MVP] on 14 Dec 2005 08:12 Bill Brehm < wrote: > I am trying to understand CSocket. I don't think I like the idea of using a > CSocketFile and a CArchive. Can CSocket be used without them like I would > use CAsyncSocket, but still giving the benefits CSocket offers? I looked in > the sample files Chatsrvr and Chatter. Both use a derived version of CSocket > so they can override OnReceive() or OnAccept(). Is this required to be able > to use CSocket without CSocketFile and CArchive? Thanks. > > If you use CSocket without CSocketFile and a CArchive I can't imagine what benefits you think it offers. CSocket simulates a blocking socket, which is a poor fit in a GUI app. Your app will stop responding to the user while CSocket is blocked inside a Send or Receive call, and it could be blocked forever if something goes wrong with the net or other end. CAsyncSocket is preferred because it is nonblocking. You must derive from it so you can receive its asynchronous notifications like OnReceive, OnSend, OnConnect, OnClose. After making a socket call your app should return to the MFC message pump. Then it will process user input and painting normally until the next asynchronous notification call comes in. For example, for each OnReceive call you get, call Receive one time, then return. -- Scott McPhillips [VC++ MVP]
From: Michael K. O'Neill on 14 Dec 2005 14:33 "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:eLyQQALAGHA.3436(a)TK2MSFTNGP10.phx.gbl... > > If you use CSocket without CSocketFile and a CArchive I can't imagine > what benefits you think it offers. CSocket simulates a blocking socket, > which is a poor fit in a GUI app. Your app will stop responding to the > user while CSocket is blocked inside a Send or Receive call, and it > could be blocked forever if something goes wrong with the net or other > end. > I'm not certain if this is a completely correct characterization. As you correctly point out, CSocket is not actually a blocking socket; it actually is a completely non-blocking socket that only *simulates* a blocking socket. It simulates a blocking socket by pumping messages and not returning until a Send or a Receive is completed. For example, in a call to CSocket::Send(), CSocket calls the underlying winsock send() function, which returns immediately since the socket is non-blocking. If all data was sent successfully, CSocket::Send() returns, whereas if all data was not yet sent, then CSocket::Send() pumps messages (i.e., it calls AfxPumpMessages()) and then tries the winsock send() function again, until all data is sent successfully or an error on the socket is detected. So I don't fully understand what you meant when you said that the "app will stop responding to the user while CSocket is blocked inside a Send or Receive call..." As far as I can see, the app will continue to respond to the user since the underlying socket is completely non-blocking and CSocket::Send() (or Receive()) pumps messages. It is true, however, that the call to CSocket::Send() might never return if an error on the socket is never detected, so the application might become stuck in one place. But even while it's stuck, it's still responsive to the user since messages are being pumped. In apparent recognition of this problem, MSDN has posted code for a CTimeoutSocket that overrides the virtual CSocket::OnMessagePending function. See "How To Configure a Time-Out on a CSocket Operation" at http://support.microsoft.com/default.aspx?scid=kb;en-us;138692 > CAsyncSocket is preferred because it is nonblocking. You must derive > from it so you can receive its asynchronous notifications like > OnReceive, OnSend, OnConnect, OnClose. After making a socket call your > app should return to the MFC message pump. Then it will process user > input and painting normally until the next asynchronous notification > call comes in. For example, for each OnReceive call you get, call > Receive one time, then return. > I totally agree that CAsyncSocket is preferred. > -- > Scott McPhillips [VC++ MVP] > Mike
From: Scott McPhillips [MVP] on 14 Dec 2005 21:24 Michael K. O'Neill wrote: > ...CSocket calls the underlying winsock send() function, which returns > immediately since the socket is non-blocking. If all data was sent > successfully, CSocket::Send() returns, whereas if all data was not yet sent, > then CSocket::Send() pumps messages (i.e., it calls AfxPumpMessages()) and > then tries the winsock send() function again, until all data is sent > successfully or an error on the socket is detected. > > So I don't fully understand what you meant when you said that the "app will > stop responding to the user while CSocket is blocked inside a Send or > Receive call..." As far as I can see, the app will continue to respond to > the user since the underlying socket is completely non-blocking and > CSocket::Send() (or Receive()) pumps messages. Hi Michael, Thanks. First, it's been a long time since I used CSocket. Once was enough! I later changed that app to CAsyncSocket and I've been using CAsyncSocket ever since. I'm looking at the source code for the version of CSocket in VC6, and it doesn't agree with your description. For example, there is no call to AfxPumpMessages() in this version. It doesn't pump application messages, only messages sent to the invisible socket window. So perhaps your comments are correct for the more modern versions. -- Scott McPhillips [VC++ MVP]
|
Next
|
Last
Pages: 1 2 3 Prev: draw text on a cimage Next: error LINK2019: unresolved external symbol |