CSocket
in [MFC]
|
From: "Bill Brehm" <<don't want any on 15 Dec 2005 02:16 From the help on CAsyncSocket: This class is based on the assumption that you understand network communications. You are responsible for handling blocking, byte-order differences, and conversions between Unicode and multibyte character set (MBCS) strings. If you want a more convenient interface that manages these issues for you, see class CSocket. When I read that, I was thinking from "byte order" that they meant CAsyncSocket was more UDP and CSocket is more TCP. I thought I would have to worry about packet order and missing packets and double packets. Now I guess they just mean little vs big endian. Is my current understanding correct? "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:eLyQQALAGHA.3436(a)TK2MSFTNGP10.phx.gbl... > 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: "Bill Brehm" <<don't want any on 15 Dec 2005 02:48 What does OnReceive() do if it is not overridden? "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:eLyQQALAGHA.3436(a)TK2MSFTNGP10.phx.gbl... > 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: Scott McPhillips [MVP] on 15 Dec 2005 08:31 Bill Brehm < wrote: > When I read that, I was thinking from "byte order" that they meant > CAsyncSocket was more UDP and CSocket is more TCP. I thought I would have to > worry about packet order and missing packets and double packets. Now I guess > they just mean little vs big endian. > > Is my current understanding correct? yes, byte order is about endian-ness. -- Scott McPhillips [VC++ MVP]
From: Scott McPhillips [MVP] on 15 Dec 2005 08:32 Bill Brehm < wrote: > What does OnReceive() do if it is not overridden? > Nothing. -- Scott McPhillips [VC++ MVP]
From: Michael K. O'Neill on 15 Dec 2005 15:36 "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:OnYvs6RAGHA.1408(a)TK2MSFTNGP15.phx.gbl... > 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] > Hi Scott, We are talking about the same version of CSocket (i.e., VC6), and upon further study of the source code, I think that your view is more correct than mine. I was typing from memory, and it's clear that I had some details wrong. For example, CSocket has a member function CSocket::PumpMessages(), and I confused that with the AfxPumpMessages() function. Anyway, looking at the source for CSocket::PumpMessages(), you're correct that it mainly is looking for FD_xxx notifications to the hidden socket window. In addition, it looks for a timer message so as to perform idle processing (i.e., CWinThread::OnIdle() ) every two seconds. Finally, it also calls the virtual function CSocket::OnMessagePending(). I thought that this function might pump messages, but in fact it only looks for (and dispatches) WM_PAINT messages. So, there you have it. During its pseudo-blocking operations, besides looking for FD_xxx messages to the CSocket's hidden window, CSocket performs idle processing every two seconds and dispatches WM_PAINT messages. That's about it. CAsyncSocket is still the way to go. Mike
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: draw text on a cimage Next: error LINK2019: unresolved external symbol |