From: "Bill Brehm" <<don't want any on
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
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
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
Bill Brehm < wrote:
> What does OnReceive() do if it is not overridden?
>

Nothing.

--
Scott McPhillips [VC++ MVP]

From: Michael K. O'Neill on

"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