File Transfer using Winsock2

[sch...@comcast.net]

I'm trying to transfer a large file between two processes (client/
server) with a proxy process (basically used as a router) in the
middle. I can set up the winsock connection. I send a user request
message to transfer a file from client (through proxy) to server. The
server then repeatedly calls "send" to transfer blocks of the file.
The issue is that the receiver (client) gets the first block of data
(via the proxy), and that's all.

The proxy process has a non-blocking select() loop that looks for the
read-ready port on which the file messages should be appearing, then
when the message appears, recv()s it and re-send()s it to the
appropriate client connection. The client process is also in a tight
select() loop looking at the incoming port. It does see and recv()
the first block of data, then nothing else.

I've tried a bunch of implementations...trying to send() all the file
blocks then calling shutdown() on the SENDer side to get a read()
return of 0 on the proxy and client indicating the connection is being
shut down...no avail.

Here's the proxy code:

// Look for incoming messages on the spacecraft
controller
fd_set ReplySet;
FD_ZERO(&ReplySet);
FD_SET(pGSc_SScSocket->Fd(), &ReplySet);
unsigned short int Done = 0;
TimeVal.tv_sec = 20; // Time for the space-to-ground
controller to wait for a reply from a member of the constellation for
a ground-initiated request
while (!Done)
{
int Ret = select(pGSc_SScSocket->Fd() + 1,
&ReplySet, NULL, NULL, &TimeVal);
if (Ret > 0)
{
if (FD_ISSET(pGSc_SScSocket->Fd(), &ReplySet))
{
// Receive the reply message and resend to the
original requester
m_pCnPacket->Clear();
RcvLen = pGSc_SScSocket->RecvFromRaw
(m_pCnPacket, &DestAddress);
printf("RcvLen = %d\n", RcvLen);
if( RcvLen > 0 )
{
SndLen = pAcceptSocket->SendRaw
(m_pCnPacket);
printf("SendLen = %d\n", SndLen);
}
else if (RcvLen <= 0)
Done = 1;
}
}
else if (Ret == 0)
{
printf("GSc_SSc select timed out!\n");
Done = 1;
}
else
{
printf("GSc_SSc select Error: %d\n",
WSAGetLastError());
Done = 1;
}
}
}
// CSocket::Close(pAcceptSocket);
printf("Closed connection\n");

Any help?

Thanks in advance.

[Alun Jones]

<sch...@comcast.net> wrote in message
news:23c04b52-5a43-4c7e...@d20g2000yqh.googlegroups.com...

> I'm trying to transfer a large file between two processes (client/
> server) with a proxy process (basically used as a router) in the
> middle. I can set up the winsock connection. I send a user request
> message to transfer a file from client (through proxy) to server. The
> server then repeatedly calls "send" to transfer blocks of the file.
> The issue is that the receiver (client) gets the first block of data
> (via the proxy), and that's all.
>
> The proxy process has a non-blocking select() loop that looks for the
> read-ready port on which the file messages should be appearing, then
> when the message appears, recv()s it and re-send()s it to the
> appropriate client connection. The client process is also in a tight
> select() loop looking at the incoming port. It does see and recv()
> the first block of data, then nothing else.

I only read the rest of your post to confirm what I already guessed from the
above description.

You are neglecting the fact that select() will clear (some of) the contents
of the fd_set structure "ReplySet" - you should recreate the contents of
that structure prior to _each_ call to select().

Alun.
~~~~

[David Schwartz]

On Dec 17, 7:40 am, sch...@comcast.net wrote:

>                         if( RcvLen > 0 )
>                         {
>                            SndLen = pAcceptSocket->SendRaw
> (m_pCnPacket);
>                            printf("SendLen = %d\n", SndLen);
>                         }

You don't post the code of 'SendRaw', but if this really is non-
blocking, as you claim, what happens if 'SendRaw' can't send *all* of
the data? And if your code lives in some shadow world sort of blocking
and sort of non-blocking, it will be awfully hard to get it to work
right.

Also, does no data ever need to go in the other direction. And take
note of the bug Alun Jones pointed out.

DS