Tell me what components it is better to use to transfer files from the server to the client on the LAN in DElphi. tried through indie, tried through sockets. Sockets have a size limit, the file does not reach completely. In indie, I can't bind file transfers to a button, because flow required. Maybe I'm looking the wrong way.

  • Maybe large files for transfer need to be divided into smaller pieces? - kot-da-vinci
  • TcpServer, not? Here is an example. delphisources.ru/forum/showpost.php?p=64145&postcount=6 - K_NoW
  • @K_NoW unfortunately, the example is bad and does not take into account a lot of things that can happen with the data on the road. It is only suitable for exchange within the local machine. - kami

2 answers 2

Based on approval

Sockets volume limit

I assume that the transmission / reception of data is planned to be carried out using the TCP protocol. Accordingly, all further will be based on this statement.

Initially : The TCP protocol is a stream bidirectional protocol, it has no restrictions on the amount of data transmitted. There is a limit on the volume of socket buffers, they are set in the registry for example . You should not abuse this parameter (and generally touch it) - no matter what value you put up, anyway, sooner or later such a set will be found that does not fit into the allotted limit.

Therefore, the general principle of work on TCP was, is and will remain the following:

  1. send data to the buffer until it receives it.
  2. Remember the position at which you stopped
  3. Waiting for a signal from the socket that the buffer is free and return to step 1

As an example, you can see how the ScktComp module is arranged, and more specifically, the methods of the TCustomWinSocket class - SendStream -> Event -> SendStreamPiece (they work in exactly this sequence).

When using TStream heirs, the task is even simpler, since the position is remembered by TStream itself (you just need to remember that if there is less data sent than was read, transfer TStream.Position back to this difference).

It is also necessary to pay attention that all methods of sending data to the socket and receiving them from the socket are functions and they return the amount of actually read / written data. You can only focus on their results, the assumption "I sent 100 bytes to the buffer" does not mean at all that they all went to the socket.

Addition 1 By default, the Nagle algorithm is enabled for TCP sockets. In short, it means that the sent data does not fly away immediately, but after a certain timeout and thus the short parcels can stick together with each other. For example, if you send "123" and followed by "456", then the parcel will go to the network "123456". If the transmitter and receiver are located on the same local machine, then this effect will not appear.

Addition 2 Even if the parcels are left separately, they can stick together with the network throughput, network equipment and other factors at the receiving end. The example from "Supplement 1" is also relevant, only other options are possible - "1234" and followed by "56", "12" and after "3456" and the like.

The only thing you can be absolutely sure of is that the packages will never be confused. In what sequence was sent, in the same and will come.

Therefore, it is quite standard practice when working on TCP to prepend the actual data by some service header, which at least contains the length of the transmitted information in a field of fixed length (for example, Int64 - 8 bytes).

The concrete implementation, of course, may and will differ depending on the mode of interaction.

Addition 3 To avoid such problems, you can use the protocols where all of the above have already been implemented: HTTP, FTP ...

You need:

  1. Decide which protocol you will use (according to the initial question, it is not at all obvious that, in addition to the contents of the files, it will have to be transmitted over the network)
  2. Decide on a set of components (ScktComp, Indy, ICS ...)
  3. See examples of their use and try your own implementation.
  4. If there are questions / something does not work - ask a new question.
  • Transfer files only, but from server to clients - Maxim Kutenkov
  • @MaksimKutenkov In this case (IMHO), TCP really suits you best, since this protocol allows the initiation of an exchange (not to be confused with the initiation of a connection) by the server. As for the components, it's difficult for me to advise something, since all the time it worked only through standard TClient \ TServerSocket from ScktComp.pas in non-blocking mode. There is also a fairly simple implementation, but it will not work for your needs, because based on TMemoryStream, in which gigabyte movies are better not to push. - kami

  • Split large files into small pieces and transfer them, then collect them back.

  • Learn how to work with threads and use Indie.

  • Can you share a link or code where the division algorithm is described? - Maxim Kutenkov
  • @MaksimKutenkov This is most likely a separate question. As the question about working with threads. The algorithm is simple - we copy a piece, send it with a note about its sequence number. When receiving we get all the pieces and copy them back into a large file in order. - Kromster
  • one
    here it is definitely not necessary to "add a sequence number to the pieces". If tcp is used, the data will come in the order in which they were sent. If they come out of order, it will be a megabag and there will already be Microsoft, Linus, and Cook, and many others interested. - KoVadim
  • Why divide the data into pieces? Is that for parallel transfer of different data through a single connection. And so - as soon as the transmitting buffer of the socket is free - it is recorded there "how many will fit" from the TFileStream and that's it. About Indy - I do not agree. Yes, this is partly holivar, but there are many other sets of components that are not inferior in functionality and are much easier to implement. - kami
  • @kami about TCP is not said anywhere. Cut into pieces because at the author "In sockets restriction on volume, the file does not reach completely". In any case, the question is too vague to give accurate answers. - Kromster