Solved

Socket receives the data incomplete from a particular request

Posted on 2002-07-19
7
365 Views
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).

CODE:
int i = mySocket.Receive(bReceive,bReceive.Length,0) ;
0
Comment
Question by:denz_1
  • 4
  • 2
7 Comments
 
LVL 9

Expert Comment

by:ShaunWilde
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
0
 

Author Comment

by:denz_1
ID: 7165810
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
 
LVL 9

Expert Comment

by:ShaunWilde
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.
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 9

Expert Comment

by:ShaunWilde
ID: 7166308
however I would change your loop to be

while(ind< bytesToReceive)
{
 ...
}


this is assuming that you know bytesToReceive
0
 

Author Comment

by:denz_1
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.
0
 
LVL 9

Expert Comment

by:ShaunWilde
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
0
 
LVL 27

Accepted Solution

by:
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.

HTH
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Introduction                                                 Was the var keyword really only brought out to shorten your syntax? Or have the VB language guys got their way in C#? What type of variable is it? All will be revealed.   Also called…
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

743 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now