Re: CAsyncSocket thread crashing on WM_SOCKET_NOTIFY message

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Michael K. O'Neill (mikeathon2000_at_nospam.hotmail.com)
Date: 11/03/04 

Date: Wed, 3 Nov 2004 07:49:47 -0800

Do this Google search in "Groups", and see if any of the threads there help
you:
http://groups.google.com/groups?q=sockcore.cpp%20%22line%20513%22&num=100&hl=en&lr=&sa=N&as_qdr=all&tab=wg

Also, this link at codeproject mentions someone who had your same (maybe)
problem and solved it:
http://codeproject.com/internet/ndk.asp?df=100&forumid=1156&exp=0&fr=76&select=691362#xx691362xx

That's all I have.

Mike

"greanie" <greanie@discussions.microsoft.com> wrote in message
news:70C50BED-195B-4172-89D0-B24367CABB85@microsoft.com...
> I don't think it is a problem of too many sockets opening and closing or
> getting a message after the socket has closed. I have been watching the
> packets using two packet monitors, one running locally and another running
on
> the same machine as the server. Incidentally, they both show the same
> packets for the connection/socket that ends in an exception. Below are
all
> the packets transmitted prior to exception. (I will shortened the seq
> numbers below for simplicity). The server is listening to port 33000.
The
> server I call Svr below and the client I call TCP-a
>
> start of connection - 3-way handshake:
> TCP-a to Svr SYN seq:9-9 ack:0 src: 1033
> dst: 33000
> Svr to TCP-a SYN|ACK seq: 0351-0351 ack: 10 src: 33000 dst: 1033
> TCP-a to Svr ACK seq: 10-10 ack: 0352 src: 1033
dst:
> 33000
> connection established
>
> Send data:
> TCP-a to Svr ACK seq: 10-63 ack:0352 src: 1033
dst:
> 33000
>
> Close Connection
> TCP-a to Svr ACK|FIN seq: 63-63 ack: 0352 src: 1033 dst:
> 33000
> Svr to TCP-a ACK seq: 0352-0352 ack: 64 src: 33000 dst:
1033
>
> Exception in sockcore line 513.
>
> On neither of packet monitors did I see the ACK|FIN from the server. I
> seems like the socket is being closed, then sends a ACK|FIN. But since
the
> socket is closed, nothing is there to handle the
WM_SOCKET_MESSAGE:FD_CLOSE
> message. I have seen this twice; it is repeatable and usually just a
> question of time.
>
> Again, I have implemented my AsyncSocket server nearly exactly like the
code
> in the AsyncServerClient sample application.
>
> Thanks for the ideas. Keep 'em coming.
>
>
> "Michael K. O'Neill" wrote:
>
> > In times past, there was a bug in MFC's sockets that manifested itself
> > exactly as you described, and was caused by sequential calls to close a
> > socket and then create a new one. The bug had something to do with the
> > so-called "map of dead sockets", as detailed here:
> >
http://groups.google.com/groups?hl=en&lr=&threadm=E4H1s3.B8y%40nonexistent.com&rnum=3 .
> > Search through the thread for WM_SOCKET_DEAD, which is the fix for the
> > problem.
> >
> > All this should have been fixed in later versions of MFC. But maybe
there
> > are some ideas in the thread, or in the three KB articles cited there...
> >
> >
> > "greanie" <greanie@discussions.microsoft.com> wrote in message
> > news:C17F98F1-160D-4F8E-9629-0703B676F063@microsoft.com...
> > > As to which Assert is firing, it is the second assert, after pSocket =
> > > DoCallBack( INVALID_SOCKET, FALSE), after the first two returns to
> > > DoCallBack( (SOCKET) wParam, TRUE/FALSE ), inside the if loop.
> > >
> > > As to whether the hand off is the problem, I don't think so because I
> > > usually receive and handle one message just fine. It is only on the
> > second
> > > message that I have a problem.
> > >
> > > As to which thread is causing the assertion, using the trace, I follow
to
> > > AfxCallWndProc, and the pWnd points to a CSocketWnd, so I assume it is
the
> > > socket UI thread.
> > >
> > > I traced the lParam of 0x20 to FD_CLOSE I believe, declared in the
winsock
> > > 2.0 header file, so I believe that I connect alright, but for some
reason,
> > I
> > > don't seem to close properly.
> > >
> > > thanks for the ideas. keep 'em coming.
> > >
> > > "Scott McPhillips [MVP]" wrote:
> > >
> > > > greanie wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > This is my second question about CAsyncSockets and threads. The
first
> > was
> > > > > successfully answered (thx2 Scott McPhillips) so I hope this one
will
> > be as
> > > > > well. I have written a server to accept regular updates over the
> > public
> > > > > internet from an ethernet-enabled embedded controller that sits in
the
> > field.
> > > > > I have a prototype of the embedded controller working and the
server
> > running
> > > > > in California. The server is crashing on an assert inside
> > DoCallBack() in
> > > > > SockCore.cpp. A call to LookupHandle() returns a null pointer
which
> > causes
> > > > > an assertion. I have traced it back to a WM_SOCKET_NOTIFY
message, I
> > > > > believe. The message is always 0x20 (lParam) and I can't find
which
> > message
> > > > > that is (FD_CLOSE, FD_OPEN, etc...). The socket id seems to
change
> > every
> > > > > time.
> > > > >
> > > > > I have implemented the code for starting an AsyncSocket thread as
> > suggested
> > > > > in several articles, using a listening port to accept the
connection
> > and
> > > > > passing that to a UI thread and custom implementation of the
> > CAsyncSocket
> > > > > class (my previous post has more details). I have tested my
server
> > and
> > > > > embedded application here for 2 weeks (on & off, not continuously)
and
> > the
> > > > > server has never had a problem. The machine here is running W2k
SP1
> > and the
> > > > > machine in California is running W2k sp3, although I don't expect
this
> > makes
> > > > > a difference.
> > > > >
> > > > > Thanks in adnance for ideas and suggestions.
> > > >
> > > > You didn't identify which ASSERT is firing, or which thread context
it
> > > > fires in. My best guess from your description is that the problem
> > > > happens during OnAccept. Transferring the accepted socket to
another
> > > > thread is tricky. There is a sample on the MSDN site named
MFCAsync.
> > > > You might want to compare its code to yours - especially in the
OnAccept
> > > > handler.
> > > >
> > > > --
> > > > Scott McPhillips [VC++ MVP]
> > > >
> > > >
> >
> >
> >

Relevant Pages

  • Re: Socket Exception
    ... In this case the server most likely rejected your ... connection. ... Each command is a new socket connection that is opened and closed ... /// Required designer variable. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Problem with writing fast UDP server
    ... UDP packets per second. ... socket and threads. ... I wrote a simple case test: client and server. ... The maximum theoretical limit is 14,880 frames per ...
    (comp.lang.python)
  • Re: ASP.NET 2.0 - a newbie question
    ... Is there some experienced ASP.NET 2.0 developer, ... server that comes bundled Microsoft VWDE. ... A connection attempt failed because the ... connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How to establish connections to the servers inside a DMZ?
    ... Each server is assigned one of those IPs. ... >> (inside the DMZ) is accessed. ... >Directing packets to the dmz is accomplished with route table entries. ... >packets) and use connection tracking and ESTABLIHED, ...
    (comp.os.linux.networking)
  • error when move web service from dev machine to test server
    ... I have a simple web service that I developed on my laptop that resides ... test server, & when I try to run it, I get the error "No connection could be ... No connection could be made because the target machine actively refused it ... Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState ...
    (microsoft.public.dotnet.framework.webservices)