Synapse abort timeout

[Jake012345]

timer interval=10

if canread(10)=false then begin
  thread.Sleep(10);
 socket.connect(ip,port);
end;

[rvk]

You could try but it won't fix the problem that the sender doesn't know how much of the data is really arrived correctly at the receiver. Especially when the connection was cut.

[Jake012345]

Yeah...

Than how can I send large files in a bad environment?

[rvk]

Than how can I send large files in a bad environment?

Divide the transfer by blocks and send each block individually with a checksum. At the end put them together and do a final checksum. Something like how torrents work.


You didn't specify this when you started all this.
Not making specifications before programming makes it all a lot harder.

[Jake012345]

 

[Jake012345]

Now I got a fault.
The last stream didn't sended.

Can you help me?

[Jake012345]

Oh no!
I solved it. The Thread.execute>filesend>

I changed the

Code: Pascal  [Select][+][-]

1. if MainStream.size>=FileUtil.FileSize(Form1.OpenFileDialog.FileName) then...
2.  

to

Code: Pascal  [Select][+][-]

1.       if MainStream.position>=FileUtil.FileSize(Form1.OpenFileDialog.FileName) then
2.  

[rvk]

You can remove the lines 117 and 135

if MainStream.Position>=FileUtil.FileSize(Form1.OpenFileDialog.FileName)
and
if MainStream.Size>=StrToInt(infile_size)

At the moment they don't do anything. They even prevent MainStream.Free which will result in leaks when the filetransfer is interrupted. You would only need those lines when you want to try to resume, but that's not (yet) build in. Or are you planning to build in a loop in case of connection interruption? (and then resending the entire file?)

You can remove one of the Sleep(2000) in the program (but one should remain because you still use the string-socket). But it's not needed to have them both.

[Jake012345]

On the receiving I need it because without it the last stream appears on Log and ins't in file

[rvk]

On the receiving I need it because without it the last stream appears on Log and ins't in file

That shouldn't happen.
Look at the code.
Thread.Execute is always executed only once (and you don't have a loop in there).

So:

Code: Pascal  [Select][+][-]

1.       MainStream:=TFileStream.Create(infile_name,fmCreate);
2.  
3.       Connection.RecvStream(MainStream,60000);
4.  
5.       if MainStream.Size>=StrToInt(infile_size) then begin
6.         MainStream.free;
7.         StatString:='>:Transfer Done!';
8.         Synchronize(@ShowStat);
9.         mode:='none';
10.         Form1.ProgressLabelPercent.Caption:='100%';
11.         Form1.ProgressBar.Position:=Form1.ProgressBar.Max;
12.         Form1.ProgressLabelByte.Caption:=(infile_size+'/'+infile_size);
13.       end;
14.  

In case of an interrupt the MainStream.Free isn't executed and you get a leak.
In case of a successful RecvStream(), then MainStream.Size should ALWAYS equal infile_size so the if should always be true.

If you really want to take connection interruption into account, then do this:

Code: Pascal  [Select][+][-]

1.       if MainStream.Size = StrToInt(infile_size) then begin // EXACTLY THE SAME SIZE
2.         StatString:='>:Transfer Done!';
3.         Synchronize(@ShowStat);
4.         mode:='none';
5.         Form1.ProgressLabelPercent.Caption:='100%';
6.         Form1.ProgressBar.Position:=Form1.ProgressBar.Max;
7.         Form1.ProgressLabelByte.Caption:=(infile_size+'/'+infile_size);
8.       end
9.       else begin
10.         StatString:='>:TRANSFER FAILED!';
11.         Synchronize(@ShowStat);
12.         mode:='none';
13.       end;
14.       MainStream.free;

That way at least the MainStream is freed in both cases (and you get a neat message about the failure).

(also notice that the received size needs to be the exact size of infile_size. And not smaller or bigger.)

[rvk]

In addition to my previous post...

You could set mode to "request_resend" when the filetransfer fails on the receiving side.
The receiving side can then request a resend from the sender via the normal messages.

Also... you access the string mode and the Form1 directly in the thread.
This is normally really dangerous and can lead to unexplained freezing of your program.
You should only access those via syncronise.

But because you only access them once... (during start and after end), maybe you can get away with it.
But keep it in mind.

But you can move those Form1.ProgressLabelPercent etc. to the ShowStat anyway. In that case they are executed in Synchronize and thus in the main thread. Then the only dangerous thing is the access to the mode string. But that is minimal.

[Jake012345]

wait!

Wich is the main thread?
What is start on program start.
But now the second thread can run commands in main thread?

And an other 'question':

I created the thread and started it with .start and the .execute procedure auto started.
Why? Because it is in the 'protected' section? Or the .execute is a default procedure?

[rvk]

Wich is the main thread?

Main thread is the thread in which your main program itself runs.

What is start on program start.

All processes, even the main program, run in threads. So the main thread is the one where you have your form1 etc.

But now the second thread can run commands in main thread?

Yes, but you must never access anything that's thread-unsafe without using synchronize. And about the whole LCL (VCL on Delphi) is thread-unsafe. Even simple strings are thread-unsafe. So directly accessing them could lead to problems if multiple thread access that memory space at the same time.

I created the thread and started it with .start and the .execute procedure auto started.
Why? Because it is in the 'protected' section? Or the .execute is a default procedure?

Execute is the default 'run' procedure of a thread.
You can read about it here https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#The_TThread_Class

[Jake012345]

But there is still some problem.

The failed transfers has 1/3 rate is on same computer.
I think that't not too normal.

[rvk]

The failed transfers has 1/3 rate is on same computer.
I think that't not too normal.

On the same computer you should have no failed transfers.

Code?