Read NMEA from Server

[TWELVE]

So much thanks to you, TWELVE and AGRAHAM, for your efforts.

Because of at least one posting from you and your name i assume, you're a german or at least a member of a german speaking nation...) As this is also true for me, i could do some translation if this makes things easier for you..?

Regarding your problem here..i will get into this later on.I could use the net sniffer to check out what's going on there.

So as per agraham, you appear to have the issue that the client.DataAvailable thingy does indicate data, while reading it will block the program - under certain conditions as it looks.For me it is the opposite, the thingy does not indicate data, while i'm still able to read the data from the stream.

Cheers

TWELVE

 

[TWELVE]

I have not experienced any DataAvailable problems myself so I do not know whether this technique will sidestep any problems or not.

I really appreciate your work...but..To be honest...i would prefer to get hold of a fixed / improved network lib instead of using workarounds all the time.

IMHO the read from stream should never wait/sit/block there for ever, but return after a time out value.Especially than, if there's only one thread.

Anyway..it looks he fixed it or he is not interested in anymore...;-)


regards

TWELVE

 

[schimanski]

I'm german

Hello TWELVE!

I saw, that your location is Düsseldorf. The Server, which I take the data from is also in Düsseldorf and i'am working here. Are you german too?

Of course, I have many problems to translate your threads and it is very difficult to discribe my problems in english. If you speak german, it' much easier for me...


Thanks for answer....

 

[schimanski]

An old problem

Hello together!

It's an old problem, but I have to annoy you again with this: The problem is, that my application locks up in the line

GPS_Server.GPSStream(filestream.ReadString)

when the server sends no data. I have watched the server and client TCP-protocolls with the 'wireshark' and noticed, that by a sudden stop of sending data from the server, the 'finish-bit' from the server dont' arrives from the server to the client. So, the basic4ppc-application locks up in the line filestream.readstring, beause the line is waiting on the finish-bit (LAST_ACK).

Transmission Control Protocol – Wikipedia

What I need is a timeout-function for my client to stop reading from the stream, when time is over. Is there an way to program such a timeout?

Thanks and :sign0013:for the old problem

 

[agraham]

What I need is a timeout-function for my client

The default timeout for a synchronous read on a NetworkStream is infinite. You could try changing it with the Door library - note that I haven't tried this myself so I don't know if it will work.

Client.New1
Obj1.New1(False)
  ...
Client.Connect(....)
  ...
Obj1.Value = Client.GetStream
Obj1.SetProperty("ReadTimeout", 3000) ' timeout in mS

This will throw an exception if it times out so you will need to put yout read in a small Sub with an ErrorLabel statement to catch the exception and return a fail/succeed flag.

 

[schimanski]

Yes, that's it...

Hello agraham!

Thanks for your post. I have tested your advice in a small testapplication:

Client.New1
Obj1.New1(False)
  ...
Client.Connect(....)
  ...
Obj1.Value = Client.GetStream
Obj1.SetProperty("ReadTimeout", 3000) ' timeout in mS

:sign0060: It works very fine with our server. That's what I'm looking for!!!

Thanks and :sign0188:

 

[schimanski]

Problem with SetProperty on the device

Hello!

Only two smal questions to your last post, agraham:


1. Your code runs very fine on my desktop. But on the device, I get an errorexception in this line:

Obj1.SetProperty("ReadTimeout", 3000) ' timeout in mS

2. When the timeout creates an errorexception, the application will disconnect the serverconnection, so that I have to connect again after the error with client.connect. Is there a way to avoid this?

Thanks for your efforts..

greetings.....

 

[agraham]

But on the device, I get an errorexception in this line:

What error message do you get?
Does this only happen when it times out? If so that is what it is documented to do.
Don't you get an exception on the desktop if it times out?

Are you trapping the error with ErrorLabel and if so does it still drop the connection? If you are trapping it and it does disconnect then there is not much else you can do other than try to reconnect.

 

[schimanski]

Hello agraham!

Are you trapping the error with ErrorLabel and if so does it still drop
the connection? If you are trapping it and it does disconnect then there is
not much else you can do other than try to reconnect.

I trapped the error correct with errorlabel, so I think, that there is no other way than reconnect.....but is not a big problem, it operates...

What error message do you get?
Does this only happen when it times out? If so that is what it is 
documented to do. 
Don't you get an exception on the desktop if it times out?

It doesn't happens, when it times out. It happens after I have connected with the server:

client.connect(...)
.....
oj1.value=client.getstream
obj1.setproperty("readtimeout",3000)     'here is the error

On the desktop, there is no error. It seems, that the device doesn't know this command.....

 

[Erel]

The property name is case sensitive.
Try:

obj1.setproperty("ReadTimeout",3000)

 

[agraham]

The property name is case sensitive.

Well spotted Erel! :sign0188: I missed that. I hope that's all the problem is.

 

[schimanski]

Hello erel, hello agraham!

I have respects the case-sensitive. Sorry i have write the post in haste, my mistake. :signOops: That's not the problem.

My door-lib is the verison 1.0.3187.17864.

I'm going to write a short test application and message again...

 

[schimanski]

Hello again!

I have written a small test-application with a simple connection to a server, that sends NMEA-protocolls. The same problem as befor: It runs perfect on my desktop but not on the device.

Sub App_Start
   Form1.Show
   client.New1
   object1.New1(False)
   
   Client.Connect ("217.91.....",.....)
   
   filestream.New1(client.GetStream,False)
   object1.Value=client.GetStream             
   object1.SetProperty("ReadTimeout",3000)   <- error device   
   
   Label1.Text="Server connected!"
   timer1.Enabled=True
End Sub

Sub Timer1_Tick   
   If client.DataAvailable=True Then
      gps.GPSStream(filestream.ReadString)
   Else
      label2.Text="no data"
   End If
End Sub

Sub GPS_GPSDecoded
   ....
             ....
End Sub

:sign0085:

 

[agraham]

You still haven't told us what the error message is!

 

[schimanski]

Sorry, but I don't get a reasonalbe error description:

An error occurred on sub main.app_start.

Line number:17

object1.SetProperty("ReadTimeout",3000)

Error description:

Es kann keine Fehlermeldung angezeigt werdem, da die optionale Assembly,
die die Fehlermeldung enthält, nicht gefunden wurde. 

Continue?

I think, that it is in english: unknown command????

 

[Erel]

Apparently the ReadTimeout is not supported by .Net CF.
On my local msdn documentation it says:

Windows Mobile for Pocket PC, Windows Mobile for Smartphone, Windows CE Platform Note:
In .NET Compact Framework applications, the ReadTimeout property is supported, but reserved for future use. Using this property will raise an [T:System.InvalidOperationException,] until it is available in a future release of the .NET Compact Framework.

The documentation is not 100% clear as the online version doesn't say this.

 

[agraham]

Well that explains it

The documentation is not 100% clear as the online version doesn't say this.

The documentation with VS2005 for a NetworkStream positively states ReadTimeout is available for the Compact Framework version 2.0.

Stream.ReadTimeout Property
...
.NET Compact Framework
Supported in: 2.0

Out of interest under which section is it in your MSDN and which MSDN is it Erel?

 

[Erel]

This comment is taken from Visual Studio 2008 msdn (under NetworkStream).

 

[agraham]

Visual Studio 2008

One up already I see Erel :sign0188: Got your 214 yet?

 

[Erel]

Got your 214 yet?

Yes. Looks like a great new (and pretty large) toy