PC Review


Reply
Thread Tools Rate Thread

RE: this code failed ( tcpclient )

 
 
Paul G. Tobey [eMVP]
Guest
Posts: n/a
 
      26th Feb 2010
I don't understand why this is a problem. It's up to the network driver,
NDIS, and WinSock to decide how much data comes back. You've asked for a MB,
but if there's some, but not all, of that amount of data available, it's
perfectly reasonable for the stream to return the currently-available data.
Maybe the server took a little longer to send all the data. It certainly
would not all have fit into one packet. You have to accumulate the data
until you've received the amount that you want. There are always delays...

Paul T.

"Dani" wrote:

> Hello, the following code fails to receive more than 32767 bytes. Does
> not return any error and the connection is closed properly. The platform
> is Windows Mobile 6 standard on iPaq 214 (also tried other iPaq) VS2005
> and CF2.0. Does anyone know help me?
> //I ask for the file to the server
> writer.Write("file\r\n");
> writer.Flush();
>
> //I read what the server responded to my attempt to
> authenticate
> //The following does not receive more than 32767 bytes
> in spite of having given 1mb buffer??
> byte[] myReadBuffer = new byte[1024000];
> int offsetbyte = 0;
> StringBuilder myCompleteMessage = new StringBuilder();
> int numberOfBytesRead = 0;
> int ammontarebyteRead = 0;
> //System.IFormatProvider formatstr;
> // ???? Incoming message may be larger than the buffer
> size. ??? this code is taken by sample on msdn
>
> do
> {
> numberOfBytesRead = strm.Read(myReadBuffer, 0,
> myReadBuffer.Length);
> //offsetbyte += numberOfBytesRead;//for test
> ammontarebyteRead += numberOfBytesRead;//for test
>
> myCompleteMessage.Append(Encoding.ASCII.GetString(myReadBuffer, 0,
> numberOfBytesRead));
> Application.DoEvents();
> }
> while (!strm.DataAvailable);
>
> Ok,i do not know what to do.
> Help.
>
> Dani.
> .
>

 
Reply With Quote
 
 
 
 
Paul G. Tobey [eMVP]
Guest
Posts: n/a
 
      26th Feb 2010
You never receive any more data? That sounds like, at some point, your code
is getting confused and asking for zero bytes. I'd step through and, each
time strm.Read() is about to be called, check the values of each of the
parameters, before and after. There's certainly no reason why the framework
would enforce any limit of that sort and I know that it doesn't. Unless the
server is doing this to you, I don't see any other source for the problem.

Paul T.

"Dani" wrote:

> Hello Paul,
> I've specified a MB beacause the ammount of data ask is much higer than
> 32767 byte received, but tcpclient receives only first 32767 byte. I
> can not tell more ... A correct procedure, sample etc ? a state machine ?
>
>
> > I don't understand why this is a problem. It's up to the network driver,
> > NDIS, and WinSock to decide how much data comes back. You've asked for a MB,
> > but if there's some, but not all, of that amount of data available, it's
> > perfectly reasonable for the stream to return the currently-available data.
> > Maybe the server took a little longer to send all the data. It certainly
> > would not all have fit into one packet. You have to accumulate the data
> > until you've received the amount that you want. There are always delays...
> >
> > Paul T.
> >
> > "Dani" wrote:

> .
>

 
Reply With Quote
 
 
 
 
Paul G. Tobey [eMVP]
Guest
Posts: n/a
 
      2nd Mar 2010
My last suggestion involved *debugging the code* and watching the values you
are passing as parameters to the client calls. Have you done that? What
were the results? Did you find *any* strange values being passed by your
code, anything at all unexpected?

Switching operating systems and languages doesn't prove anything except that
the server works, which is pretty much irrelevant to this investigation.
Remember that the .NET Compact Framework is not the framework you use on your
desktop or server machines. The interfaces are similar, but it's different
code, for the most part.

If you can't figure it out from the debugging process, forget about
TcpClient and use sockets themselves to do the data transfer or even switch
to C/C++. That will allow you to eliminate one or more possible sources of
the problem (TcpClient class, .NET Compact Framework). Sockets themselves
don't suffer from many problems of this type at all, so, if your code doesn't
work there, it's definitely your code that's broken.

Paul T.

"Dani" wrote:

> Thank's Paul,I tested the server with a Windows client written in Delphi
> without
> finding any limit of sending or receiving. I do not know what to do.
>
> TCPServer Indy Delphi 2007 does not have any parameter to remove the
> limit found.
>
> > You never receive any more data? That sounds like, at some point, your code
> > is getting confused and asking for zero bytes. I'd step through and, each
> > time strm.Read() is about to be called, check the values of each of the
> > parameters, before and after. There's certainly no reason why the framework
> > would enforce any limit of that sort and I know that it doesn't. Unless the
> > server is doing this to you, I don't see any other source for the problem.
> >

> .
>

 
Reply With Quote
 
Paul G. Tobey [eMVP]
Guest
Posts: n/a
 
      3rd Mar 2010
Well, I think you're giving up too easily, but, if the result isn't very
valuable to you, I understand. I generally start with sockets, rather than
TcpClient and the like so that I have complete control over what's going on...

Paul T.

"Dani" wrote:

> Paul G. Tobey [eMVP] ha scritto:
> > My last suggestion involved *debugging the code* and watching the values you
> > are passing as parameters to the client calls. Have you done that? What
> > were the results? Did you find *any* strange values being passed by your
> > code, anything at all unexpected?

> Sorry but i have not found any information in debug mode to resolve this
> problem. I confess to not being good enough to debug the code behind the
> interfaces and what I saw does not report errors.
>
> >
> > Switching operating systems and languages doesn't prove anything except that
> > the server works, which is pretty much irrelevant to this investigation.
> > Remember that the .NET Compact Framework is not the framework you use on your
> > desktop or server machines. The interfaces are similar, but it's different
> > code, for the most part.

>
> Yes i know.
>
> >
> > If you can't figure it out from the debugging process, forget about
> > TcpClient and use sockets themselves to do the data transfer or even switch
> > to C/C++. That will allow you to eliminate one or more possible sources of
> > the problem (TcpClient class, .NET Compact Framework). Sockets themselves
> > don't suffer from many problems of this type at all, so, if your code doesn't
> > work there, it's definitely your code that's broken.
> >

>
> Huff. This is much more difficult for me. I surrender.
> .
>

 
Reply With Quote
 
Jamal Samedov
Guest
Posts: n/a
 
      31st Mar 2010
Here is not a problem of from which component to start either from socket or
TcpClient.
It is just problem with wrong problem in using of a component. I had
implemented from TCPClient, then used some functionality and behavour of
socket.
Now it can receive any amount of bytes without problem. It works in Windows
XP and the same way in Windows mobile.
Recommendation:
1) There are two parts: receiving part and parsing part
a) receiving part is responsible only for receiving raw bytes
as it mentioned by Paul loop to read data from stream (or
socket) till data is available
Store data in temporary storage (Stack, collection or whatever)
Start listening incoming data: BeginRead or infinite loop
b) parsing part continiously in temporary storage either there is
data
a) if there is data then try parse the data. If there is
recognizable package then read, parse and do your functionality according to
program logic and remove the package from temporary storage. All data
received before the recognized package remove too (probably it is garbage)

b) if the data is not recognizable wait till new data comes
and then try parse again
2) Use three threads:
a) for receiving raw data
b) for parsing trial
c) the last thread is responsible for providing your program logic
after a package was recognized

This is simple, transparent and proper logic. Only you should define own
package that you can recognize where the package starts and where is end of
the package and accordinly implement parser for your definition
With which component your are working it is up to your implementation and
experience.
By the way I had implemented both secured with ssl and unsecured connection.
It is just optional. Security works with both server- and client side
certificates. But this is another story

--

Dr. J.N. Samedov,

Software Manager
COINMASTERS B.V.
Adrianalaan 101a
3053 MA Rotterdam
The Netherlands

T: 00 31 (0)104186405
F: 00 31 (0)104222549
www.coin-masters.com
"Paul G. Tobey [eMVP]" <paultobey _at_ earthlink _dot_ net> wrote in message
news:(E-Mail Removed)...
> Well, I think you're giving up too easily, but, if the result isn't very
> valuable to you, I understand. I generally start with sockets, rather
> than
> TcpClient and the like so that I have complete control over what's going
> on...
>
> Paul T.
>
> "Dani" wrote:
>
>> Paul G. Tobey [eMVP] ha scritto:
>> > My last suggestion involved *debugging the code* and watching the
>> > values you
>> > are passing as parameters to the client calls. Have you done that?
>> > What
>> > were the results? Did you find *any* strange values being passed by
>> > your
>> > code, anything at all unexpected?

>> Sorry but i have not found any information in debug mode to resolve this
>> problem. I confess to not being good enough to debug the code behind the
>> interfaces and what I saw does not report errors.
>>
>> >
>> > Switching operating systems and languages doesn't prove anything except
>> > that
>> > the server works, which is pretty much irrelevant to this
>> > investigation.
>> > Remember that the .NET Compact Framework is not the framework you use
>> > on your
>> > desktop or server machines. The interfaces are similar, but it's
>> > different
>> > code, for the most part.

>>
>> Yes i know.
>>
>> >
>> > If you can't figure it out from the debugging process, forget about
>> > TcpClient and use sockets themselves to do the data transfer or even
>> > switch
>> > to C/C++. That will allow you to eliminate one or more possible
>> > sources of
>> > the problem (TcpClient class, .NET Compact Framework). Sockets
>> > themselves
>> > don't suffer from many problems of this type at all, so, if your code
>> > doesn't
>> > work there, it's definitely your code that's broken.
>> >

>>
>> Huff. This is much more difficult for me. I surrender.
>> .
>>



 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Http Post Error: A connection attempt failed because the connectedparty did not properly respond after a period of time, or establishedconnection failed because connected host has failed to respond. Deepu Microsoft Dot NET Framework 1 9th Jul 2009 05:09 PM
C# Applet, TcpClient class. Why does this one line of code take so long to execute? C# Man Microsoft Dot NET Framework 3 28th Oct 2004 08:54 PM
TcpClient.LingerState not working (still in TIME_WAIT) Amil Microsoft Dot NET Framework 0 5th Sep 2003 05:25 PM
Problem in listening on TcpClient ............... Kuldeep Microsoft Dot NET Framework 0 29th Aug 2003 08:20 AM
TCPListener and TCPClient same port issue. Erik Microsoft Dot NET Framework 0 4th Aug 2003 09:47 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 06:35 PM.