Synapse TFTP file transfer

[PascalDragon]

That is why there exists ready made (communication) protocols such as FTP, TFTP, HTML etc. These protocols where once made up and the RFC's determine how these clients and servers need to "talk" (communicate) to each other. That "talking" between client and servers is also known as (communication)-protocol.

You would have to invent your own communication protocol in order to make things work exactly the way how you want it to work, just as any other existing protocols (FTP/TFPT/HTML/etc) do. There is not an example in the world that is able to teach that for you. You can always have a look at already existing protocols (RFC's/code) and read how they implemented their communications, but i doubt they would be helpful for your specific situation (as you stated earlier that the extra's in the code seem to confuse you).

I take it you mean HTTP, not HTML 

[TRon]

I take it you mean HTTP, not HTML 

drats 

Indeed, i meant http. I'll correct that in my post. Thanks for noticing   

[Jake012345]

You think I can do it easier with Lnet?

[TRon]

You think I can do it easier with Lnet?

I have no experience with either synapse or lnet (i just read their documentation/examples) so your mileage may vary.

However, the same rules as explained in my previous post apply for whatever network-library you are going to use. There is no shortcut, in case you might be inclined to believe as such. There is some difference when it comes to implementation between using blocking vs non-blocking sockets.

My advise would be to just pick one network library that you are (most) comfortable with using and stick by it for a while. In the end you really should use multiple of them, implementing the same stuff, to be able to see/understand their differences and.or if you favour one in particular.

Seeing that there are multiple people who already posted examples using synapse (also for you) i would stick to synapse but that is just a personal observation.

[Jake012345]

Thats good but I'm stupid for networking and the synapse is very detailed and hard

[balazsszekely]

@Jake012345

Thats good but I'm stupid for networking and the synapse is very detailed and hard

First of all you're not stupid, just a beginner which is perfectly fine, we all were in the same shoes once. What you fail to understand is that network programming is not a trivial task, I'm not saying it's particularly hard either, but it takes time to learn it. You have two choices:
1. Start slowly, learn how to program first
2. Use an already coded example and don't worry about the details

[TRon]

Thats good but I'm stupid for networking and the synapse is very detailed and hard

You're not stupid at all, i just think you are trying to do too much to quickly and perhaps more or less expect(ed) a ready-to-go solution (which doesn't exist as it depends on how _you_ want your communication to work for you)

The language barrier doesn't particularly help there either 

Let's resume (from the other threads as well):
You are basically looking at
- the following documentation: http://synapse.ararat.cz/doc/help/
- leading to the following class hierarchy: http://synapse.ararat.cz/doc/help/ClassHierarchy.html
- to use one class in particular: TTCPBlockSocket (http://synapse.ararat.cz/doc/help/blcksock.TTCPBlockSocket.html)

that particular class (and it's ancestory) have (at least) 4 methods that qualify for usage to address your 'problem':
- SendString (http://synapse.ararat.cz/doc/help/blcksock.TBlockSocket.html#SendString)
- RecvString (http://synapse.ararat.cz/doc/help/blcksock.TBlockSocket.html#RecvString)
- RecvStreamRaw (http://synapse.ararat.cz/doc/help/blcksock.TBlockSocket.html#RecvStreamRaw)
- SendStreamRAW (http://synapse.ararat.cz/doc/help/blcksock.TBlockSocket.html#SendStreamRaw)

Most of those functions/methods are part of the ancestor of TTCPBlockSocket named TBlockSocket http://synapse.ararat.cz/doc/help/blcksock.TBlockSocket.html and thus are available (as well) for TTCPBlockSocket

User GetMem already helped you out with your starting code (https://forum.lazarus.freepascal.org/index.php/topic,49853.msg363139.html#msg363139), but you never folowed up on his efforts.

I pointed to a question someone had about SendStream (and you are more than welcome to use that instead of SendStreamRaw or others) , to which the reply was use SendStreamRaw and it had a nice example. https://stackoverflow.com/questions/30778703/lazarus-freepascal-synapse-send-file-to-tcpblocksocket

You would need to put that all together, and come up with an idea how the server and client should communicate with each other, e.g. invent your own words (strings) that can be send (sendstring) and received (recvstring) and be interpreted by the client and server and the code acting on what meaning you gave to those words.

something like a (very crude and wrong because it was based on sending byte by byte -> use a stream instead) conversation that i posted here (https://forum.lazarus.freepascal.org/index.php/topic,49853.msg363000.html#msg363000)

(*) snippet of a imaginative communication between client and server
1) client: hello server, are you ready to accept a byte that belong to the file i am sending ?
2) server: uhm, lemme think about that.... uhm yeah, i think i am able to manage to accept a byte, which file was that again ?
3) client: allrighty then,let me pick up that byte and send it to you.... hold on there it comes, i need to retrieve it first.
4) server: oh dear, i have accepted a byte from this client, now where do i store it ? was it this buffer ? That one is full, i need to flush that buffer first.
5) client: did i already send all bytes of this file ? If so th inform the server that we did so (so it can wait for or start the next instruction/conversation) and if not then return to the top of this communication-protocol-list else continue doing something else.

The best would be to have a (solid) starting position (code-wise) where you can send strings from client to server and back again.

Then you can start implementing your (actual) "conversation"-protocol between client and server.

As user GetMem already suggested, take small steps at a time.

edit: and in case you wish to have a look at a (more or less complete) starting position with sending strings back and forth between client and server then you could perhaps have take a look at this example from user rvk:

you should be able to click the link to get to the correct post.

[Jake012345]

So...

Server:                                   Client:
1.
Create and open socket            Connect
2.
listening.....                             Send Sting(can I start to send the file?)
3.
show savedialog                       waiting.....
4.
send string (ok I'm ready)         send streams
5.
recv and write streams to file     send string (Ok I'm done)
6.
recv string and close the file+    recv sring and show message (transfer successful)
send string(ok I got it )

[TRon]

So...

Something like that, yes indeed 

If you do implement it as you just wrote then i'm sure you are going to be confronted with some hurdles, but those can be taken one step at a time. For instance, i never expected/imagined/anticipated on a user interaction such as a save-dialog (which takes an undetermined amount of time).

In case you get stuck on some part during the conversation then post the offending code, describing what conversation you expected/implemented and what /where it failed for you. Debugging such "conversations" can be daunting. Make sure to write out lot's of information during the conversation so that you are able to see where things get stuck (writing text to the console will do, but writing to a LCL memo is ok as well). Do not rely on your interpretation(s), let code speak for itself 

[rvk]

So...

Do you have your messaging part (strings) working?

Simplest is that you send this from one side.
@PUT,filename.raw,1234,54354456 CR+LF
1234 would be filesize and 54354456 would be a checksum for the file.
If the client receives this it will switch to a mode to put all the next received bytes into a file named filename.raw (or whatever is provided in the string).
When 1234 bytes are received the client does the checksum to check if the file is correct.

Another alternative would be that there is a separate socket opened on a different port to receive the file. In that case, communication of stringmessages could continue on the string-socket. I don't think you need to put strings on that separate socket. Just only the complete file. With tcp you don't need to ask if you can send or that the send is successful. You could do that on the string-socket afterwards.

[Jake012345]

You said

i never expected/imagined/anticipated on a user interaction such as a save-dialog (which takes an undetermined amount of time).

But how can you set the download folder?
automatically the Downloads, or pre set it before receive the file?

[rvk]

You said

i never expected/imagined/anticipated on a user interaction such as a save-dialog (which takes an undetermined amount of time).

But how can you set the download folder?
automatically the Downloads, or pre set it before receive the file?

I would just put the file in either Downloads or your own preset downloads folder for you app. You could add a button for "downloaded files" which opens the explorer directly in that folder.

Do downloads get initiated from the client (pull a file) or from the other side (push a file)?
Or both?

[TRon]

@rvk
If going for the first option from your post, what is the best/correct way to (keep) sync with synapse ?

Despite having (what i thought to be) a pretty solid conversation I sometimes ran into the situation that during receiving (on server side) the client went out of sync on occasion (switching back from raw byte stream mode to string-mode). In that situation the server had a much smaller buffer than client had (for testing purpose). Once out of sync .... 

Are CanWite and CanRead helpful there when situated at the correct locations, or ..  ?

[Jake012345]

Sorry I can't understand

Do downloads get initiated from the client (pull a file) or from the other side (push a file)?
Or both?

You asked that the client send or receive files?

[TRon]

You said

i never expected/imagined/anticipated on a user interaction such as a save-dialog (which takes an undetermined amount of time).

But how can you set the download folder?
automatically the Downloads, or pre set it before receive the file?

In the test that i wrote i simply used the executable's directory. So i added ".copy" to the received filename, in order to circumvent overwriting 

But... if i look at your bigger picture (game, server, multiple clients) then i would not bother users with such details during game-startup or gameplay. Depending on what file is actually send i place it the correct directory and set the location for that directory beforehand. That way you can f.e. have multiple locations for multiple types of files, e.g. pictures go to one directory, audio to another,updates somewhere else. Users can interact with such setting either crude by a .ini file or before the game actually starts.

But... you are free to do as you like, that is why we can't tell you how you implement things. It is completely your idea/invention