Timing over socket connection

[trevix]

Here again...
Since I read somewhere that the "Write to socket" happens all at once, I modified your stack so that I can use it not only for sending files, but eventually to send text and arrays (not implemented yet).
It looks like it is working but the received file is slightly corrupted (jpg around 100k).
I think the problem is in the base64Encode-decode.
I tried several variations, like textEncode(base64Encode(tFileContent),"UTF-8") and the corresponding decode, but nothing seems to work.

If you wonder why I have chosen 59976 as kChunkSize, it is because is a multiple of 72 (num of chars in each line of base64Encode). Just an experiment trying solving the corrupted received file.

Any idea?
Thanks

[trevix]

Forgot to add the stack

[FourthWorld]

Browsers reliably deliver images over TCP. Images are binary. How do they do that?

[trevix]

I ain't no google

[FourthWorld]

It wasn't a request. It was a solutions prompt.

[trevix]

Sorry: I am not sure to understand...
I know that it is possible and that it is me that I am missing some...
I compared data in the send and in the receive, but my multi socket reading apparently doesn't do a good job.

[FourthWorld]

I compared data in the send and in the receive, but my multi socket reading apparently doesn't do a good job.

Do you need multiple sockets?

How do others accomplish this?

What is the largest data size you expect to send?

[trevix]

- yes, more then one user can connect to the server and send data. When I said "multi socket reading" I meant that the reading happens in several chunks. Sorry.
In fact I wonder if every reiteration of socket receiving the data and placing in local vars, is a separate instance. Do I have to take in account what happens with 2 users sending data in the same time, and have each one with its own set of vars?

- I had it working using "read socket until <SomeChar>" but it was too slow. Now I am trying to do 1 send and multiple reading. That is I send a header specifying how many time to read 59976 chars (of a base64Encoded) and the leftOver.

- around 300k is the max file size

I actually SOLVED my problem, just now:
For every chunk of data received I was doing a

Code: Select all

put base64Decode(pData) into tdata
put tdata after url ("binfile:" & sFileName)

I guess it is a no,no...
Putting the decoded data after a local var and, only at the end, saving to file, seems to have resolved.
I will post a working example (I guess it must be used with two computers, but I am not sure)
Thanks

[trevix]

Here is a working example, very fast

[FourthWorld]

Here is a working example, very fast

Well done. Glad you have that working.

[Cairoo]

Yes Trevix, my example stack's variables was only for one client connection at a time. I hoped to just show some basic steps for sending a file over a socket. To scale it for multiple connections, one would have to use arrays for storing the values associated with each connection. Maybe use the socket ID for the array keys.
The default socket timeout is usually several hours. You can set your own timeout if you want to and then perhaps add some code to handle a timeout.

[trevix]

Yes thanks, I provided about that...

Now I have bi-directional communication between the client and the server and it is quite fast thanks to you.
Sometime, though, it gets stuck on the Write to socket, for many seconds.
Can you confirm me that, in the script, each "write to socket" must be followed by a "read from socket"?
And, having bi-directionality, it must be done both on the client and in the server?
Or the first "read from socket" after establishing the connection is enough?

Thanks for any help

[Cairoo]

AFAIK, any data written to the socket waits in a buffer on the receiving end until it's read or the socket is closed.

[trevix]

And having content in the buffer is an obstacle to writing to socket?
More read then necessary is a problem? even if the buffer is empty?
Is there a buffer out and a buffer in?

[Cairoo]

Not until the buffer is full on the receiving end. If the buffer is full, no more data can be written until some data is read. I don't know the size of the buffer, though.
There's two buffers, one in each direction, so both ends can receive data. Each end clears data from its own receiving buffer by reading from it.
If you try to read an empty buffer you'll just get an empty value unless you told it how much to read or to read until it encounters a specified chunk, in which case it will wait until the specified amount of data is received or until the chunk is encountered.