Synapse abort timeout

[Jake012345]

Sorry... 

[rvk]

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

I can think of only two things why the transfers would fail.
Here, the transfer-rate is about 2 failed on 15 good transfers.

You still have a TTimer in the main thread which accesses FileThread.MainStream.
It's the same way around... a thread may not access unsafe variables from the main thread... but at the same time, the main thread may not access unsafe variables from any other thread. So the access in GetTimerTimer() is a problem.

(You can access FileThread.infile_size etc before the thread is really started. But not FileThread.MainStream, while that stream is used in the thread !!!)

Another potential problem is that you use the Connection variable (Socket) in the thread. This Socket is created in the main thread (and used for string-messages). So using this thread-unsafe variable also in a thread can lead to problems. That's why in the beginning suggested you create a separate file-transfer socket.

For this you could add a parameter to your >StartSendFile for the port the server is listening on.
>StartSendFile,filename.txt,1234,4324243,3246
(where 3246 would be the port the server is listening on for connection of a new socket)

In that case you can also eliminate the two Sleep(2000) and the transfer will start much prompter.

I have one question. This program is only used on an internal network? Or do you need to forward ports later on to make it accessible to the internet???
If it's local you can choose a random free port for filetransfer on the server and pass that on to the client.
In that case, multiple files can be transferred at the same time from multiple clients.

If it's an internet access program, you might want to choose a static port. You now have 3245 for string-socket... you could use 3246 for file transfer. That will limit your potential for multiple transfers at the same time though. But for this case you wouldn't need to pass the port to the client because it's always fixed at 3246.

[Jake012345]

It created for use on LAN and online too.

[Jake012345]

But how can I Show stat?

With the synchronize(@showstat) I can run the commands in the main thread, so it's safe?

[Jake012345]

The stat must shown every (1 sec or more often).
And the thread is 'frozen' when do the ~stream() so I don't know

[Jake012345]

for some reason I can't send more files, in one run of program (I have to restart the whole program to send other file).

And I can't figure out what is the problem.
But I made the additional socket for FileThread.

[rvk]

But how can I Show stat?
With the synchronize(@showstat) I can run the commands in the main thread, so it's safe?

Yes, that is safe.
But the Synchronize(@ShowStat) is only executed after the Send/RecvStream. And not during.

You also have Form1.ProgressBar.Position:=FileThread.MainStream.Size; in the GetTimerTimer(). And that is a big no-no because FileThread.MainStream.Size is constantly updated in the thread.

If you strip out the progress for a moment, do you transfers all succeed after that ??

[Jake012345]

I solved it.

But If I use the ShowProgrees procedure with loop, in synchronize, the main thread wont be frozen?

[rvk]

But If I use the ShowProgrees procedure with loop, in synchronize, the main thread wont be frozen?

How and when are you doing this?
You only called Synchronize in the thread itself AFTER the RecvStream.
And that should be too late to show the progress.

[Jake012345]

I put it before that, but now the program freezing and doesn't go to the next command because the synchronize(@ShowProgress) don't stop until the transfer done, what now can't be

[Jake012345]

Like 'Kill myself in the past with time travelling'

[rvk]

I put it before that, but now the program freezing and doesn't go to the next command because the synchronize(@ShowProgress) don't stop until the transfer done, what now can't be

Hihi. Yes, that's what I thought. When using RecvStream and SendStream you can't show a progress within the thread itself because it's in the ~stream() function.

The only solution would be to chop up ~stream and do the loop for sendbuffer etc. yourself, or use the callback in the socket.

Look at the OnStatus event for the TTCPBlockSocket.

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

1. FileConnection := TTCPBlockSocket.Create;
2. FileConnection.OnStatus := MyStatusHook; // this is a local procedure in the thread which does synchronize(@ShowProgress);

[TRon]

@rvk
I am far from knowledgeable on synapse but i just had a look at the OnMonitor hook.

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

1.  {:This procedural type is used for monitoring of communication.}
2.   THookMonitor = procedure(Sender: TObject; Writing: Boolean;
3.     const Buffer: TMemory; Len: Integer) of object;
4.  

Could that perhaps be used to keep an eye on progress ?

I have no idea when HR_ReadCount / HR_WriteCount starts counting :-) (i assume it is global just as OnMonitor parameters?)

[rvk]

I am far from knowledgeable on synapse but i just had a look at the OnMonitor hook.

I think the TTCPBlockSocket.OnStatus (like I mentioned in my last post) is easier for this.

Edit: O, you are correct. OnMonitor will work simular.
OnStatus will give you also the status and connection messages besides the receive and send bytes.
OnMonitor will only give you the byte-transfers (for SendBuffer and RecvBuffer).

For Jake012345: You can just use the MainStream.Position still for your progress. You don't need the parameters of the OnMonitor() itself.

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

1. FileConnection := TTCPBlockSocket.Create;
2. FileConnection.OnMonitor := MyMonitorHook; // this is a local procedure in the thread which does synchronize(@ShowProgress);

[Jake012345]

And how can I create hook?