Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1450
  • Last Modified:

MFC CSocket doesn't call OnAccept

I have written a little test app for a CSocket project, but I cannot get it to call my OnAccept method

My CSocket based class is defined as follows:
class MySock : public CSocket
{
public:
   MySock(){};
   virtual ~MySock(){};

   virtual void OnAccept( int nErrorCode )
   {
      std::ofstream ofs( "c:\\zzzzz_socky.out", std::ios::app );
      ofs << nErrorCode << std::endl;
      ofs.close();
   }
};

I am using it as follows:
AfxSocketInit();
MySock * pSocket = new MySock;
BOOL bOK = pSocket->Create( 12345, SOCK_STREAM );
char szBuff[1024];
pSocket->Listen();
MySock AccSock;
pSocket->Accept( AccSock );
AccSock.Receive( szBuff, sizeof( szBuff) );
delete pSocket;

I send it a packet, which is received fine, but MySock::OnAccept is never called and I don't understand why, I assume I have missunderstood how this is supposed to work.
0
duncanlatimer
Asked:
duncanlatimer
  • 6
  • 5
1 Solution
 
itsmeandnobodyelseCommented:
Because of that MSDN doc - see below - i would assume that you have to omit the call of Accept() and wait to be called from the framework after listening. So move the code

MySock AccSock;
pSocket->Accept( AccSock );
AccSock.Receive( szBuff, sizeof( szBuff) );
delete pSocket;

to the OnAccept function.

------------------------------- FROM MSDN  -------------------------------------------------------------------
CAsyncSocket::OnAccept
virtual void OnAccept( int nErrorCode );

Parameters

nErrorCode

The most recent error on a socket. The following error codes applies to the OnAccept member function:

0   The function executed successfully.


WSAENETDOWN   The Windows Sockets implementation detected that the network subsystem failed.
Remarks

Called by the framework to notify a listening socket that it can accept pending connection requests by calling the Accept member function. For more information, see the articleWindows Sockets: Socket Notifications in Visual C++ Programmer's Guide.

---------------------------------------------------- END MSDN ----------------------------------------------------------------------------------------

Regards, Alex

(Sorry don't know much about CSockets as i use the  native socket interface. Tell me if you want to know to use this instead of MFC sockets).

0
 
duncanlatimerAuthor Commented:
Thanks, I also would normally have used winsock, but I thought I'd give CSocket a blast this time round, what I was expecting was for OnAccept to be called prior to Accept getting executed, I am only calling Accept in my code snippet to get the socket to block, once I have the basic principle working I will be creating a new thread in OnAccept to Accept the incoming connection. I think I have made a fundamental error in my understanding of how CSocket works, if someone can point out my error I'll be away.
0
 
duncanlatimerAuthor Commented:
I wasn't really expecting to have to call Accept to make the socket block, but if I didn't call it it didn't block.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
itsmeandnobodyelseCommented:
>> but if I didn't call it it didn't block.

Actually the default is a blocking socket. So if you make a recv() or accept() to socket you will wait infinetly. You could make the socket non-blocking by calling ioctl(...FIONBIO). There is an analogue function with CAsyncSocket i know. Then on every read or accept you - normally - will return with error WSAEWOULDBLOCK, indicating there is nothing to accept or read. you could do that in a OnTimer() function within message loop until you get some client to accept or some data to read. With CSocket - as i unterstand it - you have a synchronous access to a blocking socket. That would mean to listen() and then - trusting the framework - wait until the callback OnAccept() or OnReceive() is called to signal you can accept/receive from socket without having to fear to block.

Regards, Alex
0
 
duncanlatimerAuthor Commented:
I've sort of sussed it out, I put the code in a single document interface application and just called listen, then when I sent a packet OnAccept was called just fine, I basically had it in the wrong framework I think.

I would like to know how to use CSocket in a console type application, if anyone knows.
0
 
itsmeandnobodyelseCommented:
>> I will be creating a new thread in OnAccept()

If OnAccept() is called by the framework you don't have to create a thread. You could wait on the accepted new socket using the callback OnReceive()  similar to OnAccept. Then, your read socket is checked wile the message loop is running - i suppose in CWinThread::OnIdle() - for incoming messages and if some exist OnReceive() get called.

With threads, you normally have an own thread for any new connection - accepting as  a server or sending/receiving as a client. Then you set the socket to non-blocking and run an infinite loop where you always check three things: (1) the non-blocking socket if there is any to accept/read, (2) an exit flag maybe set from the GUI thread, (3) if there are any messages to send.

For all this, you may use CAsyncSocket. However, then all threads need an own message loop.

Regards, Alex
0
 
duncanlatimerAuthor Commented:
Surely if I don't create a new thead to accept each connection attempt I won't be able to deal with concurrent connections?
My basic idea is as follows:
Create listening socket and wait for connection attempts.
When someone tries to connect OnAccept will be called and I will create a thread to handle the connection, i.e. call Accept et al.
0
 
itsmeandnobodyelseCommented:
>> When someone tries to connect OnAccept will be called and I will create a thread to handle the connection,

Yes, that's a good practice. You'll get a new socket when accepting a client connection and the thread should handle sending messages and receiving messages. The main thread is still in listening mode and will get called again if there is another client to accept.

>>  i.e. call Accept et al

The thread shouldn't handle a further accept. That's the job of the first thread (main thread) that received OnAccept() callback.

Regards, Alex

0
 
duncanlatimerAuthor Commented:
Cheers
0
 
duncanlatimerAuthor Commented:
As itsmeandnobodyelse didn't actually answer the question (I answered it myself) why should they get the points? For 50 points I'm not going to argue too strongly!!
0
 
itsmeandnobodyelseCommented:
If duncanlatimer wants his points back there isn't any objection from me.

Regards, Alex
0
 
GhostModCommented:
PAQed, with points refunded (50)

GhostMod
Community Support Moderator
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now