Workaround found for bug in CCeSocket class!
Stephen Agate
No matter how I tried, I could not get a server implementation to work on
the Windows CE platform using the CCeSocket class.
Problem Identification:
It turns out that I had two problems (you mileage may vary depending upon
the SDK version you use, as the code within WCESOCK.CPP varies quite a lot
between versions. I get the feeling that Microsoft are hacking in the
changes!).
First of all, I could not get a listening socket to correctly start a new
data-thread during the OnAccept() call. Looking at the MFC source code and
the file "WCESOCK.CPP", the DataThread() function must be started by calling
BeginThread() in order to allows the reception of incoming data. However,
the BeginThread() function only gets called from within the Create()
function. I cannot call the Create() function on a socket to be accepted, as
this causes assertions within the SOCKCORE.CPP file.
Secondly, even if you are successful in starting a new data thread, a bug
exists when creating a socket via Accept() [as in a server] instead of
Create() and Connect() [as in a client]. The actual problem is that the
CCeSocket DataThread() thread function does not check for incoming data if
the private m_bConnectedCalled member variable is not set.
Workaround #1:
[You should only need to add this workaround if you are using Windows CE
2.00]
Modify your source code to start the data-thread by creating a temporary
data socket. For example add the following highlighted lines within
OnAccept():
CCeSocket* pSocket=new CCeSocket;
!! static bool bFirstTimeThrough=true;
!! if (bFirstTimeThrough)
!! {
!! CCeSocket* pSocket2=new CCeSocket;
!! pSocket2->Create();
!! delete pSocket2;
!! bFirstTimeThrough=false;
!! }
pListeningSocket->Accept(pSocket);
etc...
Luckily the code does not call EndThread() when deleting the dummy socket,
so you only have to start the thread once.
#Workaround #2:
This is where the fun starts. To work around the m_bConnectedCalled problem
you can set the m_bConnectedCalled member variable of the CCeSocket object
to TRUE after it is returned by Accept() . The problem with that is that
m_bConnectedCalled is declared as private and you do not have access to it
in your code. To get the required access you have to modify the WCESOCK.H
SDK header file so that m_bConnectedCalled is declared as public before
compiling your application. :-)
Please make a backup copy of WCESOCK.H before you modify it and take care
that you do not change anything else within the header file. Just changing
the declaration does not change the memory layout of the class and therefore
your application will work properly with the MFC runtime DLL.
Change From:
private:
fd_set m_ReadFds;
fd_set m_WriteFds;
static CWinThread* m_pListenThread;
static CWinThread* m_pDataThread;
static int m_iSocketCount;
PURPOSE_E m_iPurpose;
BOOL m_bQuit;
BOOL m_bConnectCalled;
BOOL m_bIsConnected;
To:
private:
fd_set m_ReadFds;
fd_set m_WriteFds;
static CWinThread* m_pListenThread;
static CWinThread* m_pDataThread;
static int m_iSocketCount;
PURPOSE_E m_iPurpose;
BOOL m_bQuit;
// Hack in public access!!!!!!!!
public:
BOOL m_bConnectCalled;
BOOL m_bIsConnected;
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your code within the OnAccept() should look something like:
CServerSocket* pSocket=new CServerSocket;
// MFC Bug Fix - Must amend WCESOCK.CPP to allow access!
pSocket->m_bConnectCalled=TRUE;
if (m_pListeningSocket->Accept(*pSocket))
{
etc...
Whinges and Thanks
All the usual whinges apply when trying to get hold of someone "in the know"
at Microsoft. I was fobbed off twice by VERY lame excuses about the problem
being due to CCeSocket not supporting asynchronous socket notifications. I
mean, what do they think the threads are for?
To Microsoft's credit, I received valuable help from a Microsoft Support
Engineer called Manfred in the EMEA Regional Support Center, Munich (well,
we paid for it as a MSDN developer). He promised that a fix would be in
future versions of Windows CE MFC...
I hope this helps a few of you out there. Have fun!
Stephen Agate.