Synapse TFTP file transfer

[Jake012345]

How big the buffer can be?

[TRon]

How big the buffer can be?

Can be anything you want it to be, as long as the computer running the code has enough memory 

But... although perhaps a little risky, you could use a (buffered) filestream to directly write to disk.

[Jake012345]

So if I have a NASA computer I can read my real computer's all datas in the puffer?

[rvk]

If going for the first option from your post, what is the best/correct way to (keep) sync with synapse ?
...
Are CanWite and CanRead helpful there when situated at the correct locations, or ..  ?

A smaller buffer on client side wouldn't matter in case of tcp. The communication will wait until the buffer is processed. So mixing raw data and strings shouldn't matter if everything goes well. Of course, when there is packetloss it can become quite chaotic then 

In that case opening a second socket for raw file transfer would be the better option. On sending side opening the socket for listening and waiting for connection and on the receiving side connecting to that. After that the sending side can just stuff the complete file on the wire. On the receiving side it will end up in the file specified earlier by the string-socket communication (like the @PUT,filename,1234,5678).

In that case the raw data socket is only used for the actual filedata transfer and stays 'clean'. And there is no raw data on the string-socket. Also, the string-socket can continue sending and receiving data during file transport.

Further communications (like @CONFIRM,filename,1234,5678) from the receiving end that the file is received correctly etc is indeed up to the yet to be defined protocol.

Edit:
I would use 1kb local buffer and write that to a tfilestream.

[Jake012345]

And how works the buffer?
evey package contains the size and name of the file?

EDIT:
And other question:

How can I set an Integer/byte/Word interval?
for examle a variable 'state' can be 1-4?

[rvk]

And how works the buffer?

You read into the buffer, just like you would read into a string.

evey package contains the size and name of the file?

You haven't really defined what exactly you want.
If you have a messaging system where you send strings back and forth, you can use special characters for special commands. This is also the case in irc clients (with /).

In my example I used @. And PUT as a command to send a file. After the command you could specify a filename, a size and a checksum to make sure the file was send correctly.

This of course, is all up to what you want.

All message without @ in front are just messages. And when you receive a string with @ in front, you have a command which you need to handle different (and not display on screen).

[TRon]

And how works the buffer?
evey package contains the size and name of the file?

Again, you can implement it any which way you wish to. You make up the rules for your own protocol 

Personally, i would opt for something like suggested by user rvk (assuming client is sending/pushing to server, non linear order):

Code: [Select]

Server: RecvString...
Client: SendString("SENDFILE Filename.txt 1234 $BADFACE);
Server - detects command SENDFILE from client and "goes into" sendfile mode (receiving end)
Server - sendfile mode extracts from the received string: filename.txt (filename) 1234 (filesize) and $BADFACE (checksum), make other necessary preparations and ...
Server: SendString("SENDFILE ACK");
Server: RecvStreamRaw... (loop recv until buffer full, when buffer full then write/append to filestream, if filesize matches then stop loop and close filestream). At same time update checksum and check with checksum from client, act depending on outcome
Client: RecvString, must match "SENDFILE ACK" then ...
Client: SendStreamRaw (see example stackoverflow, do not close/free socket)
Server: See also previous server actions, only when all ok then SendString(SENDFILE OK) else SendString("SENDFILE FAIL");
Client: RecvString ... wait for server to send back the ok signal that file was received in good health, else act on FAIL from server

It is all up to you....

[Jake012345]

I thought so too, but what is the checksum how can I make it?
There is any command for that or I have to use external program?
and

EDIT:
And other question:

How can I set an Integer/byte/Word interval?
for examle a variable 'state' can be 1-4?

[TRon]

I thought so too, but what is the checksum?

hzm.. in case you have to ask that question, then it is probably best to not bother with it for now.

A checksum is like a verification number to see if all bytes where received correctly.

There are many different checksum implementations available, CRC being on of them.

The client calculates the checksum on the client side, the server calculates the checksum on the server side.

If the checksum from client and server are the same (they match) then you are more sure that all bytes where send correctly over from client to server. There are less and more precise checksum implementations, as a general rule: the more accurate the more time it takes to "calculate" the checksum. But as said, there are many implementations.


and

EDIT:
And other question:

How can I set an Integer/byte/Word interval?
for examle a variable 'state' can be 1-4?

Sorry, i seem currently too dumbfounded to actually understand what you are asking.

You mean like a set-type ? https://freepascal.org/docs-html/ref/refsu16.html

[Jake012345]

orry, i seem currently too dumbfounded to actually understand what you are asking.

You mean like a set-type ? https://freepascal.org/docs-html/ref/refsu16.html

Yes.
I want to make a procedure whit 'case'
like this:

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

1. Procedure ListeningForIncomingConnections(Server:TTCPBlockSocket; Connection:TTCPBlockSocket; State:word //>>0-4);
2. begin
3.  case State of
4.     0:begin
5.        if server listening shutdown it
6.       end;
7.     1:begin
8.        if server run then accept all connections
9.     2:begin
10.        -||- after 1 connection close the server
11.        end;
12. .....
13.  
14. end;
15.  

But I don't want to give a chance to use this procedure with a state key that it can't understand.

It's not too important but I'm curious.

[TRon]

I think you mean something like this:

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

1. type
2.   TState = (stOne, stTwo, stThree, stFour);
3.  
4. Procedure ListeningForIncomingConnections(State: TState);
5. begin
6.   case State of
7.     stOne: { do something };
8.     stTwo: { do something };
9.     stThree: { do something };
10.     else { do something that did not match any of the above,e.g. stFour};
11.   end;
12. end;
13.  

Only those four 'values' are allowed to assign to variable State (or any variable that is defined as type TState).

[Jake012345]

thanks!

[TRon]

I thought so too, but what is the checksum how can I make it?
There is any command for that or I have to use external program?

It's quite annoying that someone rewrite original questions 

for answer see: https://github.com/graemeg/freepascal/tree/master/packages/hash/examples 

[Jake012345]

It's quite annoying that someone rewrite original questions 

Got it!   

[TRon]

Thank you very much for your answer rvk

If going for the first option from your post, what is the best/correct way to (keep) sync with synapse ?
...
Are CanWite and CanRead helpful there when situated at the correct locations, or ..  ?

A smaller buffer on client side wouldn't matter in case of tcp. The communication will wait until the buffer is processed. So mixing raw data and strings shouldn't matter if everything goes well. Of course, when there is packetloss it can become quite chaotic then 

To (further) clarify, my issue is with pushing from client to server where the server has the smaller buffer..... but you seem to suggest that, in case everything goes well, there shouldn't be a problem. That is reason for me to believe i do still have something erroneously code lurking around  I was/am not certain about how synapse would approach such situation internally (I'll take a closer look to its implementation details later).

In that case opening a second socket for raw file transfer would be the better option.
...

Dearly noted and thank you for the comprehensive explanation on that part.