Prev: problem tcpclient -> other server HELP
Next: looking for a test connection pda software
From: Paul G. Tobey [eMVP] paultobey _at_ earthlink _dot_ on 2 Mar 2010 11:39
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.
> >
> .
>
From: Dani on 3 Mar 2010 02:40
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.
From: Paul G. Tobey [eMVP] paultobey _at_ earthlink _dot_ on 3 Mar 2010 10:06
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.
> .
>
From: Dani on 4 Mar 2010 10:00
Yes, I wanted to solve the problem easily but I realize that is not so
easy. I should consider studying the socket.

Paul G. Tobey [eMVP] ha scritto:
> 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...
From: Jamal Samedov on 31 Mar 2010 03:59
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:9BD19831-2A78-4C35-BC72-18079E81563C(a)microsoft.com...
> 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.
>> .
>>


First  |  Prev  | 
Pages: 1 2
Prev: problem tcpclient -> other server HELP
Next: looking for a test connection pda software