Synapse abort timeout

[Jake012345]

Here's the code.
I tested and the infile_name is not empty.
(I put a ShowMwssage(infile_name) before the stream creation in execute procedure)

[Jake012345]

I figured out, probably the program trys 2 times to create the file

[Jake012345]

when I cleared the .Execure command form timer, It works fine. !?!?
But the sender isn't good

[Jake012345]

I deleted it form everywhere and it works!!!!!
My program is good!
So I Don't need this command?
Just if I want to call it after start again?

[Jake012345]

I'm very grateful to you rvk!
Thanks!
and sure thansk for all guys who helped me!

[Jake012345]

I can't believe...
A new failure.
The accepted file size is not equal with the source.
And the acceping side is can't finish, because of that.
But the sender is write 'I'm done' and don't send any data.

[rvk]

A few remarks about you last posted synctransfer.zip

*) In TCustomThread.Execute you have a loop around Connection.SendStream() and Connection.RecvStream().
Remove both loops.
SendStream and RecvStream shouldn't be used in a loop.
If you do... the same file gets transferred multiple times.
SendStream and RecvStream itself already have loops internally to SEND THE ENTIRE STREAM.
So there shouldn't be any loop around them

*) Because you now have a separate socket for filetransfer you can remove the Sleep(2000) from the FileSendButtonClick(). The sender can directly go into the thread and wait there for an incoming connection.

*) In the Thread.Execute you access Form1.OpenFileDialog.FileName directly. But form1 isn't thread safe and you may not access it directly from other threads. You could use synchronize to get the value but it's easier to populate an outfile_name thread-variable (the same way you did with the infile_name).

*) The Application.ProcessMessages; in TCustomThread.ShowStat probably isn't necessary because the main-thread is always running. So ProcessMessages is done there anyway. (If it does give you trouble you can put it in again).

Your latest failure about the size not being equal is probably because of those loops around Send and RecvStream. Because the streams are send and received multiple times. So if you fix point 1, that will go away too.


EDIT... Woops... still one big problem. You're still using the global variable Connection for filetransfer. But TTCPBlockSocket is also not thread safe. So you shouldn't use it mixed in the main and your transfer thread.

I thought you had a version where you had a separate filesocket? That one creates a separate socket for the filetransfer. You can only remove the Sleep(2000) when you have separate sockets for filetransfer.

 

[Jake012345]

I think you wrong.
The simple send/recv stream do not have loop.
But now I can use the ~streamRaw() because it not block the all program.

And now it works fine!
I'll do the progress with a timer.

And I have 2 questions:
1. Can I use more threads?>I't require 1 core/thread>Can I run a multhreaded app. on a 1 core PC?
2.Can I declare a TTimer in other class? and use it like the visual timer?

[rvk]

I think you wrong.
The simple send/recv stream do not have loop.

No, I'm right.
Put your cursor on SendStream( and press Alt+up arrow. Then press Ctrl+Shift+Down arrow
You see it says InternalSendStream()
Again Alt+Up arrow and Ctrl+Shift+Down arrow and you are in the InternalSendStream.
You see a loop there so that EVERYTHING in the stream is send.
The WithSize of the function call is true (so size of stream is send first).
After that you have a repeat loop with until yr <= 0 and yr is the result of Stream.read() which will be 0 if the complete stream is read.

SO NEVER EVER put a loop around SendStream because then you might have the problem that the file is transferred multiple times.
(especially if the data isn't written to disk yet)
The loop is absolutely not needed and can cause serious trouble if not everything is directly written to the disk.

But now I can use the ~streamRaw() because it not block the all program.

No, don't use ~streamRar(). ~stream() is exactly the same.
The upside of ~stream is that the size of the stream is send first.
In that case the client knows how much data to receive (and doesn't have to wait timeout seconds for the last data).
Your problem with ~streamRar was that it always waits the given timeout to see if the stream is stopped.

~stream() is the better alternative (without the loop around it).

1. Can I use more threads?>I't require 1 core/thread>Can I run a multhreaded app. on a 1 core PC?

If you make sure you don't use global variables you can use multiple threads.
It does not require 1 core/thread. If there are less cores, the threads are divided over the available cores. You then don't have the speed gain of more cores but you do have the flexibility.

2.Can I declare a TTimer in other class? and use it like the visual timer?

That depends how you declare and use it.

You also had a version with a FileSocket. I think that is a better choice than sending the file over the string/message-socket. But ultimately that's your own choice.

[Jake012345]

Okay, but If I don't need the timeout in ~stream(), why there is here?
Or It has a condition like

if timeout>presetted_timeout OR wholeFileReceived then
stop_the_listening;

[rvk]

Okay, but If I don't need the timeout in ~stream(), why there is here?

For SendStream the internal Timeout is used for checking if every packet is send correctly.

For RecvStream the given Timeout is used for every packet that get received.
So don't set that Timeout too small.
(You can see this if you follow RecvStream with the keystrokes I mentioned earlier. You end up in RecvStreamSize and you can see it there)

In that RecvStreamSize routine you also see "for n := 1 to (Size div FSendMaxChunk) do"
That is the loop for Size (divided by the buffer size). That's the number of buffer reads the client does.
That's also why you shouldn't put RecvStream into a loop.

So a Timeout for RecvStream of 10ms might be a bit small. Because every read should easily be faster but one packet might accidentally be delayed. In that case you don't want a Timeout of 10ms. Make the Timeout 1000ms for example. Normal packages are read a lot faster so the Timeout isn't really needed, but if there is some hickup then the 1000ms should be enough.

That's also the reason why I suggested using the FileSocket and not doing the transfer over the String-socket. Because if you directly run RecvStream() after receiving the sting for filetransfer, the sender might not be ready yet. And if you then have a Timeout of 10ms on the client, it directly times out.

When doing a separate FileSocket... the client needs to connect to the sender. And that gives both the time to set up a correct connection (over which only the stream is send).

Alternative, like you have it now, you should give the RecvStream a Timeout of at least 2000ms maybe 4000ms, because the sender needs to start the SendStream(). The 4000ms doesn't matter much for after the transfer because the receiver knows the size of the stream so doesn't need to wait after the filetransfer to see if there is more.

[Jake012345]

Ok I'm done!
Now I want to add the reconnect, continue procedure.
How Can I do it?
And how can I test it? I did something, but I can't test because I can't disturb the connection...

[Jake012345]

Okay I installed VBox and I can turn off the net
But what is the best method to reconnect and stop the thread until reconnect and continue after that?

[rvk]

But what is the best method to reconnect and stop the thread until reconnect and continue after that?

You can't pause and resume a thread.
You could simulate it with a critical section like shown here https://forum.lazarus.freepascal.org/index.php?topic=25362.0
But because SendStream is one call, you can't interrupt it in the loop and you would need to build your own SendStream and RecvStream where you take into account that the thread is paused. And even then... when the connection is lost, you can't just continue afterwards without reconnecting.

So, building in a pause and continue (like with torrents) is really really hard. Even when you can continue the download, you would need to take into account that the last block of bytes aren't send correctly (and maybe written as 0,0,0,0,0 to the file). And the sender should know how much the client has received, and how much data was correctly received (so you can't use filesize on the clientside).

[Jake012345]

and the thread.sleep?