Indy10, as supplied with Delphi 2006 (sorry, can't recall whether I've updated it).
Using IdFTPServer to receive files from a third-party hardware device.
Device sends files in batches of 200 or more of small 30k-ish files.
Device establishes a new FTP connection - login etc - for every file and disconnects after each, then immediately logs in for the next file.
Device uses passive PASV data transfer.
(Bulk of data transfer removed for brevity between lines 25 & 68)
The problem is the delay between lines 74 & 75 - might only be 300ms, but that adds up over 200+ files.
(Using Filezilla for the FTP server is about 3 times faster than using Indy.)
I initially noticed that after the final data packet (line 70 above) Indy wasn't responding with the expected 226 'Closing data connection.' , so I thought (I'm a FTP novice) that perhaps the device wasn't closing the data connection. So I hacked the ReadFromStream procedure in TIdFTPServer.DoDataChannelOperation() to exit if the packet size was under 1k. That resulted in Indy providing the 226 response:
(Captures were taken on different dates so don't correspond exactly.)
But there's still a delay before the 226 response (line 81).
After a quick Google of 'FIN ACK' it seems that the device is to blame, as it shouldn't ?? be including the ACK as it has nothing to acknowledge.
So I'm thinking the unexpected ACK is throwing Indy off.
Went hunting for Indy's FIN (and ACK) handling and came up empty (except for IdRawHeaders.pas and IdRawFunctions.pas which appear to not be referenced). Bit more Googling seems to show they are handled at a lower level than Indy. (But if that's the case how come Filezilla works???)
I welcome any and all suggestions as to how to resolve this, including any solutions that should have been blazingly obvious!
(But excluding 'Just use Filezilla' as we're currently doing precisely that, but it'd be nicer to use Indy integrated with our code.)
Just noticed that with the latest IW versions, in the spot in my code where I need to bump up session timeout mid-flight, it no longer works:
"SessionOptions.SessionTimeout is locked. Suggestion: Set in ServerController OnConfig event instead."
This suggestion does not work for me, because I typically set the timeout small up-front, in ServerController OnConfig event, but then later in this case I need to prompt the user and so I need to increase it. Or I could do it the other way around: make it long up-front and then shorten it later in all other cases.
Can it be restored back to how it was before, please?
procedure TIWForm1.btnTestAsyncClick(Sender: TObject; EventParams: TStringList);
begin
var B := TIWButton.Create(Self);
B.Parent := Self;
end;
this can be used to create control at runtime, however, when refresh page, the html element of button is lost and not redrawn.
This issue only occur when using template processor. if possible I did like to create the control at runtime, and not add extra thing to the template.html.
this is a more general architectural question than a specific Intraweb one...:
I have a fully functional Intraweb application which manage some classes and data modules.
I would like to leverage on these classes and data modules in a new VCL application.
For the classes is enough to share files but for the datamodules (which leverage on FireDAC) I would like to know which is the best way to manage the connection to DB.
In my Intraweb application all the datamodules refer to a connection component in the Usersession object.
When I try to use them in the VCL application I relized I cannot use the Usersession unit (or at least I think is not the best solution) and I don't know how to manage the connection to the DB in the datamodules.
I thinking about define a parameter to pass the connection in the datamodules constructor but perhaps there is a better solution.
Which is the best way to share datamodules and address the FDConnection between IW and VCL projects?
I am using C++ Builder 10.2.3 with Intraweb 15.5.5
I am trying to make a Twilio automatic phone call using TwilioClient
Below is a summary of the code:
twilio.xml is saved in wwwroot directory and it contains the text which is supposed to be spoken during the automatic call. Unfortunately this is how Twilio works for automatic outbound calls.
The call is performed on the destination number. But an error message is spoken by instead of the text in the xml file.
When I contacted Twilio support, this is what they responded (see attached PDF file).
The application is returning code 6 instead of text/xml or application/xml. I have an Apache server where the xml file is stored. But the Intraweb application I am running is not behind an Apache server!
And code 6 does not correspond to any Apache server response.
So, I think it is Intraweb application which is sending the wrong response.
When I check in IWMimeTypes.hpp, I see this:
enum DECLSPEC_DENUM TMimeType : unsigned char { mtUnknown, mtBinary, mtJPG, mtGIF, mtPNG, mtRSS, mtXML, mtTXT, mtICO, mtHTML, mtJavaScript, mtPDF, mtZIP, mtCSS, mtMP3, mtOGG, mtWAV, mtEXE, mtFlash, mtWMV, mtMOV, mtAVI, mtMPEG, mtXSL, mtGZIP, mtWOFF, mtTTF, mtOTF, mtSVG, mtJSON, mtDOCX, mtXLSX, mtPPTX, mtMP4 };
Code 6 corresponds to mtXML in the enum declaration.
So, is it Intraweb which is sending the wrong response as it seems?