[ ANN ] Release 8.1.0 DP-3

[Charles Warwick]

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