libURL and New TsNet Commands/Failures

[Sannyasin Brahmanathaswami]

I'm starting a new thread on this. I copied Charles response below…

Discussion is about using the new libURL and TS Net and usage and dealing with failures


jacque at hyperactivesw.com> wrote:

    It's "Previous request not completed" and my project hits that all the 
    time. I've tried all kinds of workarounds with only some success. I'm very 
    much hoping the new external will help eliminate those. We see it routinely 
    on slow or unstable connections.
    
    I do hope the external throws the same error so it will show up in the log. 
    BTW I'm not surprised you didn't see the error in the LC error list, it 
    isn't an engine error but rather is sent directly from libURL.

AHA.. Yes, "Previous request not complete"  

how do we get to these results?  "show up in the log " what log?

looking thru the dictionary, we would expect to see this in libURLErrordata(url)

OK I think it is coming back… 

Disclaimer: there's usually a better way than anything I know how to do!

perhaps if you need to reset the API we can issue something like

command resetNetworkInterface
put the openSockets() into tCurrentconnections
repeat for each line x in tCurrentConnections
  close socket x
end repeat
end resetNetworkInterface

maybe better practice would be to close the socket after every transfer operation. 

dictionary says : "Description
Use the close socket command to release the connection when you're finished getting and sending data over it."

So unless you had some complex multi-connection operation going you could just close all sockets at the end of  every libURL operation. Assuming one or another failed, your next operation will not be blocked.

======

Charles Warwick wrote:

On 31/07/2016 11:02 am, Sannyasin Brahmanathaswami wrote:
TS NET:

> No, you don’t need to do anything unless you are explicitly selecting inclusions during the standalone build. Then if you don’t have the internet library (libURL) included you need to include it as an extra inclusion. tsNet is resolved as a dependency of libURL

More examples would help..

Some more examples will be along soon :-)

a simple "naïve" test for starters (assumes all works under the hood) was

put url "sftp://tUser:tPwd@mydomainIP/home/mydomain/public_html/"

returns no error for syntax in the script editor… result is empty and "it" is empty.
hmmm... that should work and does here.

I have uploaded a very simple "debug" stack that you can run along side
any stack in the IDE which will capture all header data sent and
received using libUrl (just makes a simple call to libUrlSetLogField).

https://downloads.techstrategies.com.au/tsnet/debug_liburl.livecode

If you download that, click "start debug", and then try your "put"
command again, it would good to see the output.


1) neither libURL nor TSNet has any command that explicitly contains "SFTP"  if the URL we issue is (I assume this is the required form)

   "sftp://tUSER:tPWD@www.Mydomain.com/public_html/cool_pix"

is SFTP automatically implemented? transparently handled?

Yes, SFTP is automatically implemented.  Using libUrl, simply using a
URL in the format you mentioned should work.

All of the tsNet commands/functions determine which protocol to use from
the URL as well.

2) does TSnet get fired transparently whenever libURL does it's job?

OR

3) do we use one or the other?

tsNet gets fired transparently whenever libUrl does its job unless you
choose to disable it.

4)  what command do we issue which returns the pConnectionID that we see for all subsequent requests to the server.  We see lots of cmds that require pConnectionID, but none that opens a connection are returns that value for subsequent use.

one expects to see a function call like

tsNetOpen  # returns connection ID

My apologies here.  There are some documentation updates that I have
been working on that unfortunately didn't make it into DP3.  This will
be clearer in the next release.

The value of the pConnectionID parameter is specified by the user
whenever an asynchronous request is made (e.g. as the first parameter to
the tsNetUpload function).  The idea here was to make it easier to
identify the individual connection by using a label that makes sense for
the particular application and transfer, rather than some arbitrary
value returned by the external.

This is only relevant if you are using the tsNet handlers directly. An
example of using asynchronous requests can be downloaded here:

https://downloads.techstrategies.com.au/tsnet/sample_async_post.livecode

This example uses HTTP POST requests, however the same concepts apply
for all transfer types.

Maybe someone can post here a simple session example of script that does:

-- open a remote directory by SFTP
-- returns  a directory listing
-- upload/upload a file to that directory

If you are using standard libUrl commands, you would do:

local tData, tDirectoryListing, tInputFile, tData, tPath
put URL "sftp://user:pass@host.domain.com/directory/path/" into
tDirectoryListing
put specialFolderPath("documents") into tPath
put tPath & "/file.dat" into tInputFile
put URL ("binfile:///" & tInputFile) into tData
put tData into URL
"sftp://user:pass@host.domain.com/directory/path/file.dat"

If you want to use the tsNet functions which provide direct access to
more specific transfer details (number of bytes transferred, headers
received from server, etc...) , this would be:

local tEmptyHeaderVar, tData, tResultHeaders, tResult, tBytes,
tDirectoryListing, tInputFile, tPath
put tsNetGetSync("sftp://user:pass@host.domain.com/directory/path/",
tEmptyHeaderVar, tResultHeaders, tResult, tBytes) into tDirectoryListing
put specialFolderPath("documents") into tPath
put tPath & "/file.dat" into tInputFile
put tsNetUploadFileSync(tInputFile,
"sftp://user:pass@host.domain.com/directory/path/file.dat",
tEmptyHeaderVar, tResultHeaders, tBytes) into tResult

In both cases, the tsNet external will use a single connection for the
whole script.  It will not close and re-open the SFTP session for each
request unless the server closes the session due to an inactivity
timeout (or you force it to).

Hope that helps,

Regards,

Charles