Socket receives the data incomplete from a particular request

Posted on 2002-07-19
Last Modified: 2012-08-13
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).

int i = mySocket.Receive(bReceive,bReceive.Length,0) ;
Question by:denz_1
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 2

Expert Comment

ID: 7165430
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

Author Comment

ID: 7165810
hi ShaunWilde,

this is the code i wrote:

byte[] ab = new byte[1024];
int ind = 0;
while(ind< aSock.Available)
  ind+= aSock.Receive
  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.

Expert Comment

ID: 7166302
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.
Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.


Expert Comment

ID: 7166308
however I would change your loop to be

while(ind< bytesToReceive)

this is assuming that you know bytesToReceive

Author Comment

ID: 7169327
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.

Expert Comment

ID: 7170362
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
LVL 27

Accepted Solution

BigRat earned 75 total points
ID: 7171779
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.


Featured Post

SharePoint Admin?

Enable Your Employees To Focus On The Core With Intuitive Onscreen Guidance That is With You At The Moment of Need.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Article by: Najam
Having new technologies does not mean they will completely replace old components.  Recently I had to create WCF that will be called by VB6 component.  Here I will describe what steps one should follow while doing so, please feel free to post any qu…
Real-time is more about the business, not the technology. In day-to-day life, to make real-time decisions like buying or investing, business needs the latest information(e.g. Gold Rate/Stock Rate). Unlike traditional days, you need not wait for a fe…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question