Go Premium for a chance to win a PS4. Enter to Win

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

Receive only give me part of my data...

I have this Java server app that is sending data to my MFC (VC++6.0) app. The data is just over 3100 bytes long but for some reason i'm only getting 3000+ bytes and then I get another "OnReceive" message after i process this one.

Should I assume that this means that my data was split up into parts and WINSOCK is only giving me bits of it at a time?

Is there an easy way to make sure all the data is sent all at once in one BIG part instead of in chunks?

If it isn't possible to receive all of it at once, is there a way to read beyond the CSocket::Receive buffer? In other words, fake out an "OnReceive"?

-- Bubba
0
bganoush
Asked:
bganoush
  • 4
  • 4
1 Solution
 
r2farCommented:
not sure about reading all the data at once.  But would it be possible to have the Java server append a termination pattern to it's packet data.  Then have MFC read a packet, find no termination so it sets the data aside so it can be appended to by the data from the next packet until the end of the collected data reads out as the termination pattern...

Hope someone can find a simpler solution =)
0
 
bganoushAuthor Commented:
That's what I thought but the problem is that it allows the user to fiddle with stuff and send other requests in the mean time... Things could probably get very hairy.

My recent try just stored the incoming data (which is prepended with a length word) until all the data arrives but it's very messy and I gave up on the solution.

-- Bubba
0
 
r2farCommented:
If you can't read the data all at once, you will have to specify a division somehow.  Packets are not pretty, just be glad the COM handles as much as it does :s

It is always easier if the the packet divsions are put in place by the programmer and not forced upon by translation.  So another method would be to split the server packet to portions below 128 bytes as this would alow for nearly all MTU (Maximum transfer Unit) sizes.  Can the 3100bytes be broken into any logical portions? (ie. is the packet 1 massive clump or is it a series of smallerintegers and characters).

Massive Clump:
Create a smaller packet that includes an integer packet identifier, and integer index and a portion of the data.  The identifier will remain the same until the entire clump of data has been sent,  then the identifier increments.  The index will start at 0 for any given identifier and will increment with each new packet, then reset to zero when the identifier is increased.  The client code can then use the identifier and index to piece the clump back together... Yes this is 'hairy'

Logical Portions:
Easiest way is to split the data into smaller packets of related data.  You would end up having several different packets, but all will have an identifier at the begging to tell the client what type of packet it is handling.  Then when data is changes, you send only the packet required to modify that data.   This is the most popular method as it limits network traffic.


Hope this helps :0
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
bganoushAuthor Commented:

Well that's what I ended up doing but now there's something totally different happening. I now have the packets coming in a little at a time but it seems that the code is "going too fast"... and i'm losing some packets somewhere.

When I added some debugging statements that append data to the end of a log file just before my read, ALL the packets arrived with no loss. go figure!

Is it possible that I'm getting some receive notifications before the data is actually written to the socket stream?

-- Bubba
0
 
r2farCommented:
I would have to brush up on CSocket...  There is almost no way that the packets are lost in transite between the server and client because if the network drops a packet, the NIC and network layer of the computer will makie sure it is re-transmited.  So the computer almost guarantees that the non-streaming packets will get there.  This narrows the problem to the client.

So if your log file says that all the packets where recieved... Then what is telling you that packets are missing?

TEST:  try the following to see if this might be a multi-threading issue (new call to Recieve before current call is finished processing).  Place a TRACE or log file output at the start AND end of the packet recieving function.  Have the TRACe include a counter that increments each time the Recieve function is called.  What we are looking for is an output similar to the one below, if the numbers are out of order, then there is a Multi-thread problem.

OUTPUT:
Start 1
End 1
Start 2
End 2
Start 3
End 3


CODE for the traces:

// global integer
int iCount=0;

// function header
{
    // make a copy of the count for this instance of the function call
    int iNum = ++iCount;
    TRACE("Start %d",iNum);

/*** Do Processing Here ***/

    TRACE("End %d",iNum);
}


Sorry that this isn't a solution to the problem, but it should help gain some insight into the problem

Keep on Codin' =)
0
 
bganoushAuthor Commented:

Well... I do have a trace on the server which is spitting out 18 lines of data being sent... I also numbered the data to see which lines I receive and which I don't.

So far the client only seems to receive all the data when I log the received packets as they come in.  Now without this logging (which slows the client on receive), the window that displays the received packets sometimes shows 18 packets, 12 packets 7 packets, 5 packets, 10 packets......
0
 
r2farCommented:
Is this continous update, or a button triggered one-shot event?  I can't explain why you would not be recieving all the packets, the app should recieve all the sent packets from the network layer (which demands re-send on packet loss), the question is what happens after this.  Unless you are using a streaming socket... Streaming sockets sacrifice the re-send of lost packets in exchange for extra sending speed, this is to incorporate streaming media files which require high transfer rates which are not possible with datagram sockets.

Just for testing purposes, try slowing the packet sending from the server to a packet every half a second or so (if possible).  If you manage to get all the packets, then Recieve() may be being called repeatidle before it has a chance to complete it's operations.
0
 
bganoushAuthor Commented:

I pondered your questions and realized that the problem was not even in this code, it was in the server code.

-- Thanks
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

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