Sockets - A few Questions

[mwieder]

the data in tdataline is echoed on the client in the "it" variable of the post command.

Yay!

Am I correct in thinking that I am unable to use UDP from an Android platform ?

Yes, sorry. Some day.

I'll take a look at the code when I get a chance.

[sturgis]

I have a stack that seems to be working (hard coded to my laptop IP) and I cheated and used Andres http server for the back end (chock full of code-ey goodness)

If you want I'll bundle it all up and send it your way, but it sounds like you're on the verge of getting it all handled.

[Simon Knight]

Hi,

Yay!

So the echo is a positive step forward - yes ?

If you want I'll bundle it all up and send it your way, but it sounds like you're on the verge of getting it all handled.

- yes please; are you running an Android client ?

My client stalls at some point and reports a timeout error. I'm not sure which side is causing the time out. I assume that the amount of data I am transmitting (69 characters) is trivial.

Simon

[BvG]

Your client expects http. you have to follow that protocol on the server to get a proper, error free connection going:

http://www.w3.org/Protocols/rfc2616/rfc2616.html

[sturgis]

Ok, this was done use Andre's httpd stack for expediency as mentioned, it is a great stack to study as you build a more minimal implementation (its actually rev on rockets)

There is a stack in the folder named gpstrack, this is the android stack. All it does is send data (using load) to port 8082 on the backend computer which is running the httpd stack. (its hard coded, you'll need to change the IP number in the card script, 1 spot)

It sends in the format of "http://192.168.254.101:8082/libcgidemo. ... lliseconds"
You can see where the actual values are merged in in the card script.

On start of a load a "position changed" message is logged to the android log field, then when load is complete the response from the server is also logged to the field. Each position change clears the log and shows the new info. The server returns: the URL that was loaded, the status (hopefully "cached") then a string like "Latitude: ####### Longitude: ###### Altitude: ##### The Milliseconds: #######"

To adjust the part of the script that handles the sent data, go into the stacks folder of the files that were sent, open libcgidemo.rev and edit the stackscript.
That is where all the valid commands are (cmd=gpsResponse from the sent url.) Andre breaks down get and post data and shoves it into an array so that it is easy to get to. gRequestA["lat"] will contain the latitude etc.

The very simple handler that sends the response back looks like this:

Code: Select all

command gpsResponse
   -- echo what was sent to the message box
   put gRequestA["lat"] && gRequestA["lon"] && gRequestA["alt"] && gRequestA["ttime"]
   
   -- libCGI_Response is an andre defined command that sends whatever back to the requesting agent
   -- the last parameter sets the content-type in this case I used "text/plain" but it could be "text/html" or whatever. 
   libCGI_Response ("Latitude: " & gRequestA["lat"] && "Longitude: " & gRequestA["lon"] && "Altitude: " & gRequestA["alt"] && "The Milliseconds: " &gRequestA["ttime"]), "text/plain"         
   
end gpsResponse

Pretty much all credit for this goes to AG.
https://dl.dropbox.com/u/11957935/androidhttpd.zip

Oh, last thing, in the gpstrack stack I have things set to only update every second, this can be adjusted easily (look for the sTimer variable)

Currently the server doesn't do anything real with the data other than log the requests and echo back, but it should be easy enough to do whatever you need with the gps stuff.

Oh, last last thing. The button on the android stack just send random data to the server, this way you can test things on the desktop too.

[Simon Knight]

I have been edging closer to a working Client Server Pair and thanks for the link to the documentation. I have done some reading but it is not obvious to me quite what I should be implementing especially to match the Android Post command which is different to the desktop version.

sturgis - thanks for the stacks which I look forward to looking at.

I have been reviewing and modifying my own code having had a good look at RevOnRockets; Andre reads the socket data in three chunks and then creates a response. I decided to try reading the socket in two chunks i.e. method and header followed by the data. This however did not improve the stagnation of the client.

Next I looked at the response and then to the headers that the client was sending. Two changes to the header used by the client seem to have made a difference :

Code: Select all

set the httpHeaders to "Content-Type: text/plain" & crlf & "Connection : close"

These are the values that the server responds with as well.

At present I am playing with the socket time out value on the server coupled with wait time set on the clients transmission routine.

The result is that where the stacks I posted earlier struggled to exchange 50 or 60 messages the pair posted here have not stopped yet. There is the occasional pause but I guess that this may be a feature of HTTP and multi purpose computers.


Simon

[sturgis]

Very nicely done, much nicer looking than my quick hack. Got your client and server talking as I type this and its humming right along.

[Simon Knight]

Thanks to your stack a large penny has dropped re the Load command. I think I will have a play tomorrow as its the non-blocking nature is attractive. My plan is to use a time stamp in each command and use it to determine if newer data has been received, it should also give me better control over the timing of the messages.

So much to learn!

thanks again for the help and support

Simon

[sturgis]

Well, now that I've got you started thinking about "load"... Don't use it. Apparently unload is not yet implemented on IOS and Android. (the result contains 'not implemented'). I made the mistake of thinking that if load was supported, unload must be supported also. *sigh* so this means that each load will increase the cache used by your app until there is no more to be had.

My apologies for this. (and yes its nuts to have load implemented, and unload NOT.)

[shaosean]

Unless there are two different versions of libURL for desktop and mobile, unload just removes the cached data from an array..

[Simon Knight]

Well, now that I've got you started thinking about "load"... Don't use it.

I was hoping that it was a documentation error - so I'll have to stick with post for the time being.

[sturgis]

Trying to figure out how to tweak things so that I can get unload working on android, but so far no luck. More for me to learn!

Thx for the pointer, if I get extremely lucky maybe I'll find a way. (Need to get cachedurls working too so that I can see if the unload is working)

Unless there are two different versions of libURL for desktop and mobile, unload just removes the cached data from an array..

[shaosean]

The desktop engine throws the messages "loadUrl" and "unloadUrl" that you can catch in a library (like how libURL is doing it).. You can test to see if this is the case in the mobile engine as well by creating a library stack with the following code:

Code: Select all

on loadUrl
  answer param(0)
end loadUrl

on unloadUrl
  answer param(0)
end unloadUrl

[sturgis]

ah HAH. When the callback fires on desktop the status is "cached" when the callback fires on mobile the status is "downloaded" so taking a random shot here (and since unload doesn't work, and returns "not implemented" on mobile) things aren't being cached? Just downloaded then passed to the callback handler is my guess.

I did try getting some useful information from loadurl and unloadurl (as well as getcachedurl) on mobile, unload and getcachedurl just don't work.

Going to test with larger amounts of data on load and see if my device eventually crashes and burns due to lack of memory, but since the status is downloaded, I think we're good to go using load.

Thanks Shaosean! And I learned another valuable lesson today. When logging things for debugging purposes it always pays to.. er.. Read the screen.

EDIT: Ok, it looks like what happens is that whatever is returned from the server is sent as a 3rd parameter to the callback. So first param is the url, second is the status "downloaded" on mobile, 3rd is the contents. Using 'url theurl' as you would on desktop just loads the data a second time. And yes I relearned yet another valuable lesson today. This information is in the android release notes. (doh) So, Simon, feel free to use load, it will NOT fill up memory, don't bother to unload, just access the 3rd parameter in your callback handler and you're set. Release Notes = my new best friend.

[shaosean]

You could easily build your own caching system with this knowledge