Search the Community

I need to do some maintenance on an older project, which has been built using Delphi 10.3 32bit (some components just exist for this version). The Project is using TIdHTTPsServer to communicate and to transfer (upload) files. In CreatePostStream originally a TMemoryStream has been created, but it can't transfer more than approx. 500-600 MB. So I started to use a (modified) TFileStream instead (modified=extended to have LoadFromStream/SaveToStream and the like). The filestream creates a unique temp file where the data goes. Within ServerCommandOther the data is written to a second filestream with the final filename (the final name isn't yet known on CreatePostStream, so I need to copy later). As long as the data is within a 500-600 MB range, all works well. If the uploaded data is larger, then the client gets a network timeout after a few seconds. But the session thread is still active and the copy process is still running. Copying between PostStream and TargetStream is done via CopyFrom and so I placed some logging within its Read/Write loop. As soon as the copy process goes beyond the mentioned 500-600 MB, that loop seems to stop its process for several seconds, then it resumes copying, and this repeats randomly. Finally the file is copied with its full size, but the client's already gone. I just don't understand why THTTPsServer closed the connection while the thread's still working. Is there something I can do to the session or the server to avoid the network timeout at the client? Or is there a problem with TFileStream regarding threads? Indy's reporting 10.6.3.11, so this isn't very old. I tried setting all possible timeouts (ConnectTimeout, ReadTimeout, WriteTimeout on the session socket), enable/disable nagle, KeepAlive, ReuseSocket... all that, but to no success. Is there something I didn't see or are there some dont's I didn't realize? TIA Michael

I would like to ask for a tiny help, because I do not know ICS well enough yet to find a solution for this... 👼 I've switched from Indy to ISC a few weeks ago. It runs only on a few PCs yet so I can test it's durability. But it's not stable enough yet, because sometimes, when the server is temporary overloaded I experience a strange behaviour: (By "sometimes" I mean after a few days of run. So I can not debug it, only read the logs of clients on remote PCs.) 1. failing attempt: httpGET: Error #8 -- Request aborted on timeout 2. attempt: (after 20 sec) 0 byte answer, no error msg. 3., 4., 5., ... all the attempts after that: httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup ... forever ... and the only way I can fix it, by restarting the program. Here I've shared my code using TSslHttpCli before: I was told not to destroy and recreate ICS component every each time before using it, like I did with Indy. But in that case: Why ICS does not reset itself / the socket, after first (timeout) error ? Do I have to create: some kind of "onTimeout" function for it manually, and close the socket myself? (I'm guessing that the socket is still open, and that's why it's causing trouble to re-connect. Right?) Why does my function's Result is True after such error, while the "error" text is clearly showing there was a big problem with the request? (The only case this can happen, if Statuscode is 200 or 400. Not #8 or none or #404.) Do I have to set: SslHttpCli3.StatusCode := 0; each time myself before calling .GET ? (Otherwise I do not see, why I do get a "True" as result.) Thank you very much in forward for any insight / help / idea !🙂

I'm currently testing IcsTimeClient but I'm running into inexplicable timeouts when trying to get the time of ptbtime1.ptb.de. It looks like it's resolving the IP correctly (192.53.103.108) and when I try to get the time from the same server via the Indy-Component it works. Other servers, like the NIST-servers NIST Internet Time Service work with IcsTimeClient too. I tried both, with the OverbyteIcsTimeTst program and my own, reduced to the basics, one.