Communications Breakdown with CSocket

[Brendan Grant]

The following describes a problem I have been having for the better
part of 3 months, for approximately the last month however I have been
focused solely on solving it and seem to be no nearer now than a month
ago. Any thoughts or suggestions that might lead to a fix would be
greatly appreciated.

I have to VB based applications on two different PC's, a client and a
server which use a pair of OCX's to provide a communication method
between the two and which use an overloaded version of the CSocket
class.

A problem has arisen where communication between the two OCX's will be
interrupted. The socket will appear to remain open as the
Disconnection event on either side has not been fired, however neither
side is able to hear the other (even when sending on the other side is
occurring).

While not 100% predictable, the only times the communication breaks
down is when the method SendPlayList or one of a couple other Server
side OCX methods fire which send a string. Note: These functions to
not cause a break down each time they are called, but seem to
ultimately be responsible for the break down.

In trying to track down this issue, I have implemented critical
sections on both the client and server side (sending and receiving
both) to help to ensure that multiple sends or processing of received
data does not occur. I have also implemented basic checking (to be
removed later) to ensure that that the correct amount of data is being
sent and received each time.

Below is some of the code being worked with:

On the VB server side, we have the server OCX instantiated and named
Remote, we call the SendPlayList method of it, passing the string
sPlayList as such:
Remote.SendPlay List sPlayList
Within the server side OCX, the above line calls the following
function:

void CSRemoteCtrl::S endPlayList(LPC TSTR PlayList)
{
PACKET_HEADER hdr;
BYTE* pData;
int iBufSize;
SendCriticalSec tion.Lock();
if (lstrlen(PlayLi st) > 0)
{
if (m_pClientSocke t != NULL)
{
hdr.cmd = SERVER_PLAY_LIS T;
hdr.size = lstrlen(PlayLis t)+1; // +1 for NULL terminator

iBufSize = sizeof(PACKET_H EADER) + hdr.size;

pData = new BYTE[iBufSize];
memcpy( &pData[0], &hdr, sizeof( PACKET_HEADER ));
memcpy( &pData[sizeof(PACKET_H EADER)], PlayList, hdr.size);

int iRet = m_pClientSocket->Send(pData, iBufSize);
if(iRet != iBufSize)
AfxMessageBox(" Disconnected due to wrong count of bytes sent");

delete [] pData;
}
}
else
{
hdr.cmd = SERVER_PLAY_LIS T;
hdr.size = 0;

int iRet = m_pClientSocket->Send(&hdr, sizeof(PACKET_H EADER));
if(iRet != sizeof(PACKET_H EADER))
AfxMessageBox(" Disconnected due to wrong count of bytes sent");
}
}
On the receiving side within the client OCX, the OnReceive function
fires when new data arrives, inside of it there is a switch statement
which contains the following:

Receive( &packetComma nd, sizeof( packetCommand ), MSG_PEEK );

switch( packetCommand )
{

//... Other Case Statements

case SERVER_PLAY_LIS T:
{
PACKET_HEADER packet;

// Receive the packet structure
iRet = Receive( &packet, sizeof( packet ));
if(iRet != sizeof(packet))
AfxMessageBox(" Size Error 1 in: SERVER_PLAY_LIS T");
// Catch the file if it is attached
if( packet.size > 0)
{
char *filenames = new char[ packet.size ];
iRet = Receive( filenames, packet.size );
if((UINT32)iRet != packet.size)
AfxMessageBox(" Size Error 2 in: SERVER_PLAY_LIS T");
// Activate the event
pCRemoteCtrl->FirePLAYLIST ( handle, filenames );

delete filenames;
}
else
{
// Activate the event
pCRemoteCtrl->FirePLAYLIST ( handle, "" );
}
}
break;
//... Other Case Statements

}
A couple of conventions being used here is that the packets I am using
have a header sections which contain an enumerated value which
describes the kind of packet it is, based on that, a different type of
payload packet will be used to read the data and process it, similar
to how the sending side works.

Most of the time, the above code, along with similar blocks functions
flawlessly, but now and then, this or several others can and does
bring down the communication.

Also, this code is the 3rd version of code which has been used in the
same way (providing TCP/IP connectivity between VB apps) and is the
first to exhibit these problems, thus I require an easy to implement
solution which does not require rewriting or modifying large sections
of it.

[Pete C.]

Brendan Grant wrote:

The following describes a problem I have been having for the better
part of 3 months, for approximately the last month however I have been
focused solely on solving it and seem to be no nearer now than a month
ago. Any thoughts or suggestions that might lead to a fix would be
greatly appreciated.

I have to VB based applications on two different PC's, a client and a
server which use a pair of OCX's to provide a communication method
between the two and which use an overloaded version of the CSocket
class.

<snip MFC code>

Only the standard C++ language and its library are topical here. MFC
questions should be asked on microsoft.publi c.vc.mfc.

- Pete

[Brendan Grant]

> Only the standard C++ language and its library are topical here. MFC

questions should be asked on microsoft.publi c.vc.mfc.

I know, and have done so. Unfortunately being unable to find an answer
most anywhere I have looked, I have been forced to expand my search
for a solution to just outside of the normal area.

[Pete C.]

Brendan Grant wrote:

Only the standard C++ language and its library are topical here. MFC
questions should be asked on microsoft.publi c.vc.mfc.

I know, and have done so. Unfortunately being unable to find an answer
most anywhere I have looked, I have been forced to expand my search
for a solution to just outside of the normal area.

Well, that still does not make it topical here. :)
Would you ask your question, say, rec.gardens.cac ti? Your question has
nothing to do with the topic of that group, and not this one either.

- Pete

[Brendan Grant]

"Pete C." <x@x.x> wrote in message news:<fPkyc.181 5>

Well, that still does not make it topical here. :)
Would you ask your question, say, rec.gardens.cac ti? Your question has
nothing to do with the topic of that group, and not this one either.

- Pete

Your comparison is completely without merit.

Most MFC programming is done in and with C++, so it is not too long of
a shot to think that someone on a C++ group might have encountered
this problem in their time who does not read an MFC group.

It is far less likely that such a person would read rec.gardens.cac ti
and be a MFC or C++ programmer.

My question, being based in C++ does thus still have a place in a
group such as this.

[Prateek R Karandikar]

gr****@dahat.co m (Brendan Grant) wrote in message news:<d5******* *************** ****@posting.go ogle.com>...

"Pete C." <x@x.x> wrote in message news:<fPkyc.181 5>

Well, that still does not make it topical here. :)
Would you ask your question, say, rec.gardens.cac ti? Your question has
nothing to do with the topic of that group, and not this one either.

- Pete

Your comparison is completely without merit.

Most MFC programming is done in and with C++, so it is not too long of
a shot to think that someone on a C++ group might have encountered
this problem in their time who does not read an MFC group.

It is far less likely that such a person would read rec.gardens.cac ti
and be a MFC or C++ programmer.

My question, being based in C++ does thus still have a place in a
group such as this.

The topic of the group is *Standard* C++, and not MFC. In your code,
there are lots of identifiers which are neither part of the Standard
Library, nor have you declared them yourself.

!!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!