[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

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

Socket receives the data incomplete from a particular request

Hi I am using this code to receive data from a client, but sometimes it does not receive all the data it is supposed to. However when I use the debugger and set the breakpoint to the particular code it actually works fine. Has anyone get any ideas on what I can do to get around this, cause I assume that before the client finishes sending all the data it already executes this code therefore missing some pieces of data. If my assumption is right what actually can I do to prevent this from happening since the code is fine (proven when using the debugger).

CODE:
int i = mySocket.Receive(bReceive,bReceive.Length,0) ;
0
denz_1
Asked:
denz_1
  • 4
  • 2
1 Solution
 
ShaunWildeCommented:
did you check that you had enough data there to read? via the Available property - you may have to loop until you receive all your data?


the placing of breakpoints probably allows all the data to arrive and so you manage to read it in one go
0
 
denz_1Author Commented:
hi ShaunWilde,

this is the code i wrote:

byte[] ab = new byte[1024];
int ind = 0;
Console.WriteLine(aSock.Available);
while(ind< aSock.Available)
{
  ind+= aSock.Receive
             (ab,ind,aSock.Available,SocketFlags.None);
  Console.WriteLine("D " + ind);
}

the strange thing is that when I print out the aSock.Available it actually returns a 0 meaning no data was received. But when I use the debugger it works fine. It actually receives the data that i sent. I have no idea what is going on. Sometimes it does the same thing with send. Can u please help me I have stuck at this for a few days. Thanks in advance.
0
 
ShaunWildeCommented:
I know this is strange question but why are you using the socket class directly?

I normally use the TcpClient/TcpListener/NetworkStream or UdpClient depending on what I was attempting to achieve.

the fact that when you use the debugger it works makes me feel that this classes have been based on Winsock and require an underlying message pump for them to work (not a concept that is relevent to c#)


If you want to continue working with Socket itself then you may want to look at receiving the message asynchronously using BeginReceive etc.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ShaunWildeCommented:
however I would change your loop to be

while(ind< bytesToReceive)
{
 ...
}


this is assuming that you know bytesToReceive
0
 
denz_1Author Commented:
Hi ShaunWilde

I am actually working with TCPListener. I did use the BeginReceive and EndReceive but it did exactly the same thing so I tried and changed it to use the normal synchrnous way which is this way, and still the same result.
Thanks in advance.
0
 
ShaunWildeCommented:
do you have your source that you could send to me - I can't personaly replicate the problem so maybe it could be something else
0
 
BigRatCommented:
The real problem with using raw sockets is knowing when the receive has finished. Writing is no problem, you just keep stuffing bytes into the thing until you have finished sending all the data. But reading is another matter. The Available flag just means that some data has turned up.

If you imagine a real network situation and you are writing lots of data. The underlying network software splits up your data into little packets and sends them one by one over the network. When one packet arrives the Available flag get set and you can read the data of that packet. How big are the packets? Well sometimes big and sometimes quite small. You can't really rely on that. How often do they arrive? Well sometime all at once, and sometimes with long pauses between.

So, when writing/reading one uses some convention to say where the "end-of-data" is. http uses a blank line to end the header, and a "content-length:" to specify the length of the reply. Some systems use a four byte integer which specifies the length of the remainder behind it. That's called a protocol, and that's what you need.

HTH
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

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