From: Vinoj on
I've broken up my program into pieces that now fit an async model. However,
I still have the same problem. I send two files in a row and the data format
is as follows:

'f' //signals first file is incoming
<filename> //256 chars - defined on both sides
<file_size> //int - defined on both sides
<file_data> //based on length

'f' //signals second file is incoming
<filename> //256 chars - defined on both sides
<file_size> //int - defined on both sides
<file_data> //based on length

Now if I step through both programs (meaning do a single send and receive it
immediately), the correct amount of data is received and no errors occur.
However, if I let the programs run normally, there will be extra data after
the first <file_data> has been sent - before the next 'f.' This then messes
up the process. Any ideas? Thanks.


"Vinoj" wrote:

> Hello,
>
> I have two programs that use async sockets. Occasionally, there is garbage
> (extra bytes) being sent after data, thus confusing my finite state machine.
> Is there a way to track everytime the send() is called? Any ideas on why
> this could be happening?
>
> I don't know if it matters, but the sending side of the program is written
> in C and the receiving side is MFC. Thanks.
>
> Vinoj
From: Scott McPhillips [MVP] on
Vinoj wrote:
> I've broken up my program into pieces that now fit an async model. However,
> I still have the same problem. I send two files in a row and the data format
> is as follows:
>
> 'f' //signals first file is incoming
> <filename> //256 chars - defined on both sides
> <file_size> //int - defined on both sides
> <file_data> //based on length
>
> 'f' //signals second file is incoming
> <filename> //256 chars - defined on both sides
> <file_size> //int - defined on both sides
> <file_data> //based on length
>
> Now if I step through both programs (meaning do a single send and receive it
> immediately), the correct amount of data is received and no errors occur.
> However, if I let the programs run normally, there will be extra data after
> the first <file_data> has been sent - before the next 'f.' This then messes
> up the process. Any ideas? Thanks.

The "extra data" is probably the beginning of the next file, starting
with the 'f'. Does your code assume that Receive() will somehow stop at
the end of the first file data? You can't assume that :(

--
Scott McPhillips [VC++ MVP]

From: Vinoj on
The data is not the 'f' and the next file. When I look at the buffer, there
is binary data, and then I can see the 'f' and the beginning of the next file
name (which gets truncated since I'm only receiving 256 for the file name).
My Receive() call receives in only the amount of the file left to receive.
If it matters, these files are around 15k in size. Thanks.

Vinoj

void CTCPSocket::ReceiveFileData()
{
int bytesRecv = 0, iiGet = 0;
memset(buff, 0, sizeof(buff));

iiGet = (cbLeftToReceive<BUFFER_SIZE)?cbLeftToReceive:BUFFER_SIZE;
bytesRecv = Receive(buff, iiGet);
if(bytesRecv != SOCKET_ERROR){
((CIRSSSOperatorView *)m_pWnd)->WriteFileData((BYTE*)buff, bytesRecv);
cbLeftToReceive -= bytesRecv;
if(cbLeftToReceive == 0){
//files closes in OnReceiveTCP();
((CIRSSSOperatorView *)m_pWnd)->m_strReceiveBuffer += 'j';
}
}
}

"Scott McPhillips [MVP]" wrote:

> Vinoj wrote:
> > I've broken up my program into pieces that now fit an async model. However,
> > I still have the same problem. I send two files in a row and the data format
> > is as follows:
> >
> > 'f' //signals first file is incoming
> > <filename> //256 chars - defined on both sides
> > <file_size> //int - defined on both sides
> > <file_data> //based on length
> >
> > 'f' //signals second file is incoming
> > <filename> //256 chars - defined on both sides
> > <file_size> //int - defined on both sides
> > <file_data> //based on length
> >
> > Now if I step through both programs (meaning do a single send and receive it
> > immediately), the correct amount of data is received and no errors occur.
> > However, if I let the programs run normally, there will be extra data after
> > the first <file_data> has been sent - before the next 'f.' This then messes
> > up the process. Any ideas? Thanks.
>
> The "extra data" is probably the beginning of the next file, starting
> with the 'f'. Does your code assume that Receive() will somehow stop at
> the end of the first file data? You can't assume that :(
>
> --
> Scott McPhillips [VC++ MVP]
>
>
From: Vinoj on
Got it figured out. Thanks.

"Vinoj" wrote:

> Hello,
>
> I have two programs that use async sockets. Occasionally, there is garbage
> (extra bytes) being sent after data, thus confusing my finite state machine.
> Is there a way to track everytime the send() is called? Any ideas on why
> this could be happening?
>
> I don't know if it matters, but the sending side of the program is written
> in C and the receiving side is MFC. Thanks.
>
> Vinoj
From: r norman on
On Thu, 26 Jan 2006 15:46:02 -0800, "Vinoj"
<Vinoj(a)discussions.microsoft.com> wrote:

>Got it figured out. Thanks.
>

Could you please share the solution with us lurkers so that we can
avoid it, too?

Of course, you might have been doing something silly that was obvious
once you saw it and would be too embarrassed to let on. But that has
happened to all of us often enough.