On 1/08/2016 7:19 am, Sannyasin Brahmanathaswami wrote:
Charles, first… let me congratulate you for getting this into LiveCode
As it turns out, I was experiencing the infamous silent network API blocking
when there is a failed network call… I think there is an error reporting bug
somewhere as I believe in earlier versions a script error would be trigger with
some expression like
"last connection incomplete…." I don't remember the exact wording, I know I did
see it the other day..but as long as this state persists, no further libURL commands will
work.
I must have run one test in the msg box with a bad password, I had a password
with !! in it and I believe those need to be urlEncoded first before passing to
the url string.
I am surprised that trying a call with a bad password is causing the API
to block for you while using tsNet. I have tried that here with several
different bad password combinations and every time the command sets the
result to "tsneterr: (67) Authentication failure". Are you able to
confirm if the lock up is reproducible for you?
If this is happening, it would be a bug within the external. tsNet
should successfully timeout connections.
So, after that silent failure, (socket still open but broken?) the network API was
"stuck" and subsequent tests all failed… after rebooting this morning,
everything is working.
I swear I saw that old error message the other day… but today looking through
all 893 lines of the scriptExecutionErrors I can' find it.
While a silent failure shouldn't occur (please let me know if it is!),
if a "blocking" network request is still being processed with libUrl the
standard behaviour of it is to prevent any other "blocking" network
requests from being executed and return an error.
Within the Indy version of DP3, tsNet with libUrl is designed to
replicate this behaviour. This restriction is removed within the
Business edition and multiple handlers can make blocking requests (put
url x into y, post x to url y, etc.. ) without waiting for the other
requests to complete.
I think the old method to clean up was to issue a close all sockets command or
something, but it's vague… I haven't played with this for years since we turned
off FTP on our servers.
Using standard libUrl, (though it isn't documented) you can call
libUrlResetAll to reset all network connections. While this does still
work when using tsNet, it shouldn't be necessary.
If a connection does get stuck however, you can close that individual
connection by calling the tsNetCloseConn command. When using libUrl
syntax with tsNet, the parameter to this call "pConnectionID" is the URL
itself.
Thanks for your examples. When I get time to wrap my head around it… I will see
if I can contribute to the dictionary. Still not sure how to go about that.
The tsNet commands are not in the Livecode github, but please feel free
to send me an e-mail if you have any suggestions for changes to the
documentation.
Regards,
Charles
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
