RE: this code failed ( tcpclient )

Discussion in 'Microsoft Dot NET Compact Framework' started by Paul G. Tobey [eMVP], Feb 26, 2010.

  1. 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.
    > .
    >
     
    Paul G. Tobey [eMVP], Feb 26, 2010
    #1
    1. Advertisements

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

    > .
    >
     
    Paul G. Tobey [eMVP], Feb 26, 2010
    #2
    1. Advertisements

  3. 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.
    > >

    > .
    >
     
    Paul G. Tobey [eMVP], Mar 2, 2010
    #3
  4. 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.
    > .
    >
     
    Paul G. Tobey [eMVP], Mar 3, 2010
    #4
  5. 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:...
    > 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.
    >> .
    >>
     
    Jamal Samedov, Mar 31, 2010
    #5
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rich Hanbidge [MSFT]

    RE: TCPClient & ActiveSync

    Rich Hanbidge [MSFT], Jul 11, 2003, in forum: Microsoft Dot NET Compact Framework
    Replies:
    0
    Views:
    652
    Rich Hanbidge [MSFT]
    Jul 11, 2003
  2. Bob Trabucco

    TcpClient works in Emulator but not with a device in the cradle

    Bob Trabucco, Aug 14, 2003, in forum: Microsoft Dot NET Compact Framework
    Replies:
    1
    Views:
    236
    Bob Trabucco
    Aug 14, 2003
  3. Iain Simpson

    Re: TCPClient and "Could not find resource assembly"

    Iain Simpson, Aug 26, 2003, in forum: Microsoft Dot NET Compact Framework
    Replies:
    4
    Views:
    1,317
    tapeshag
    Dec 8, 2006
  4. Shine choi

    How can i implement the timeout in TCPClient?

    Shine choi, Sep 4, 2003, in forum: Microsoft Dot NET Compact Framework
    Replies:
    1
    Views:
    1,395
    Alex Feinman [MVP]
    Sep 4, 2003
  5. Richard K

    TcpClient.Connect takes 60 seconds

    Richard K, Nov 23, 2003, in forum: Microsoft Dot NET Compact Framework
    Replies:
    3
    Views:
    875
    Richard K
    Nov 26, 2003
Loading...

Share This Page