BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Indy 9 TrivialFTP Questions:          BorlandTalk.com Forum Index -> C++ Builder (Internet Socket) View previous topic :: View next topic   Author Message Paul at NCF Guest Posted: Sun Feb 11, 2007 3:50 pm    Post subject: Indy 9 TrivialFTP Questions: Hi, I'm trying to get Trivial FTP working and there are a few questions I have: 1) I presume the transfer only uses the standard UDP checksum to check the integrity of the payload? 2) It cannot continue (resume) from a previous transfer 3) This is a bit of a general question? What is the server bindings property for, and where can I find more info or examples on its use? 4) I've got a sample server and client working yesterday (local test 127.0.0.1), but I noticed that there seems to be a problem with file access on the server side when putting files - clicking button 1 twice too quickly. I figured it must be timing in that the server still has the file open when the next request comes in for the same file. So I put in a 'delay' by putting two files instead, and disabled the button whilst doing the puts. But I still get the exception if I press too quickly after its re-enabled. Any clues or guidence? Regards, Paul void __fastcall TForm1::Button1Click(TObject *Sender) { try { CopyFile( "CopyClientFile.Txt", "Client1File.Txt", false ); CopyFile( "CopyClientFile.Txt", "Client2File.Txt", false ); Button1->Enabled = false; IdTrivialFTP->Put("Client1File.Txt", "Server1File.Txt" ); IdTrivialFTP->Put("Client2File.Txt", "Server2File.Txt" ); Button1->Enabled = true; } catch (...) { } } void __fastcall TForm1::IdTrivialFTPServerWriteFile(TObject *Sender, AnsiString &FileName, const TPeerInfo &PeerInfo, bool &GrantAccess, TStream *&AStream, bool &FreeStreamOnComplete) { bool freeon = false; bool access = false; // [TBD] // check Peer in known list // check File access // etc access = true; // set up requirements if (access) { TFileStream * f = new TFileStream(FileName, fmCreate | fmShareExclusive); AStream = f; freeon = true; } FreeStreamOnComplete = freeon; GrantAccess = access; } Back to top Remy Lebeau (TeamB) Guest Posted: Mon Feb 12, 2007 3:57 am    Post subject: Re: Indy 9 TrivialFTP Questions: "Paul at NCF" <notplmacca (AT) clara (DOT) co.uk> wrote in message news:45cee6cb (AT) newsgroups (DOT) borland.com... Quote: I presume the transfer only uses the standard UDP checksum to check the integrity of the payload? TIdTrivialFTP does not perform any checksum validations. Quote: It cannot continue (resume) from a previous transfer There are no resume capabilities available in the TFTP protocol in the first place. When uploading a file, the transfer fails if the file already exists. When downloading a file, the transfer always begins at the beginning of the file. If you need resuming capabilities, then you need to use the TCP-based FTP protocol instead of the UDP-based TFTP protocol. TFTP is designed for simplicity, not features. Quote: What is the server bindings property for The same as in TIdTCPServer. Each Binding tells the server which local IP/Port to listen on. If there are multiple NIC adapters installed, the server can work with clients on multiple networks at a time. Gambit Back to top Remy Lebeau (TeamB) Guest Posted: Mon Feb 12, 2007 9:10 am    Post subject: Re: Indy 9 TrivialFTP Questions: "Paul at NCF" <notplmacca (AT) clara (DOT) co.uk> wrote in message news:45d02a9b (AT) newsgroups (DOT) borland.com... Quote: Any ideas on the last question as to why the 2nd iteration of the put operation fails? I cannot answer that. If I had any ideas, I would have mentioned them. Quote: In my tests so far I haven't added anything to bindings and it seems to work. Is it an optional field? Does it mean that it uses the default network adaptor if unspecified? If no bindings are provided, a default one is created when the server is activated. The default binding uses an empty IP, which means it listening on all available adapters. Gambit Back to top Paul at NCF Guest Posted: Mon Feb 12, 2007 9:10 am    Post subject: Re: Indy 9 TrivialFTP Questions: Thanks for the clarifications. Any ideas on the last question as to why the 2nd iteration of the put operation fails? In my tests so far I haven't added anything to bindings and it seems to work. Is it an optional field? Does it mean that it uses the default network adaptor if unspecified? Paul Quote: The same as in TIdTCPServer. Each Binding tells the server which local IP/Port to listen on. If there are multiple NIC adapters installed, the server can work with clients on multiple networks at a time. Back to top Paul at NCF Guest Posted: Tue Feb 13, 2007 4:11 am    Post subject: Re: Indy 9 TrivialFTP Questions: Thanks. Quote: If no bindings are provided, a default one is created when the server is activated. The default binding uses an empty IP, which means it listening on all available adapters. Gambit Back to top Paul at NCF Guest Posted: Tue Feb 13, 2007 9:10 am    Post subject: Re: Indy 9 TrivialFTP Questions: Hi Remy, Two further questions, hopefully quick for someone in the know: 1) Is the PUT client operation asyncronous? I've create a client app and server app, and in my example I have the client do two calls for Put, back to back. On the server, the logging shows two Write File events, followed by two transfer complete events? I have the server property set to threaded. 2) What type of thread safe access do I need to put in the server event handles for read, write, transfer complete (for multiple client connections)? ie, just for my handling of the component and other misc data, or to help the server component itself. Thanks Paul Back to top Remy Lebeau (TeamB) Guest Posted: Tue Feb 13, 2007 3:59 pm    Post subject: Re: Indy 9 TrivialFTP Questions: "Paul at NCF" <notplmacca (AT) clara (DOT) co.uk> wrote in message news:45d17236 (AT) newsgroups (DOT) borland.com... Quote: Is the PUT client operation asyncronous? No, just like most everything else in Indy. Put() does not exit until the transfer is fully completed, or an error occurs. Quote: I've create a client app and server app, and in my example I have the client do two calls for Put, back to back. On the server, the logging shows two Write File events, followed by two transfer complete events? And the problem is...? That is how it is supposed to work. When TIdTrivialFTPServer receives a request for a file, it triggers the OnReadFile or OnWriteFile event to obtain the appropriate TStream object for the file, and then reads/writes all of the file data until finished, at which time the OnTransferComplete event is triggered. Quote: What type of thread safe access do I need to put in the server event handles for read, write, transfer complete (for multiple client connections)? That depends on how you are accessing the local files to begin with. You have to make sure that you are providing your TStream objects in a thread-safe manner. If you have two clients accessing the same file at the same time, that would be bad. And in any case, the OnTransferComplete event handler is always synchronized with the main thread. Gambit Back to top Paul at NCF Guest Posted: Wed Feb 14, 2007 2:25 am    Post subject: Re: Indy 9 TrivialFTP Questions: Hi, If syncronous, and my client app has put("f1.tx") followed by put("f2.txt"), then I would expect the server log to show: "write", "transfer complete" "write", "transfer complete" but I get "write", "write", "transfer complete", "transfer complete" eg. 2007-02-13 08:01:24:0554 : IdTrivialFTPServerWriteFile 2007-02-13 08:01:24:0995 : IdTrivialFTPServerWriteFile 2007-02-13 08:01:26:0497 : IdTrivialFTPServerTransferComplete 2007-02-13 08:01:26:0968 : IdTrivialFTPServerTransferComplete Paul "Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote in message news:45d18c50$1 (AT) newsgroups (DOT) borland.com... Quote: And the problem is...? That is how it is supposed to work. When TIdTrivialFTPServer receives a request for a file, it triggers the OnReadFile or OnWriteFile event to obtain the appropriate TStream object for the file, and then reads/writes all of the file data until finished, at which time the OnTransferComplete event is triggered. Back to top Remy Lebeau (TeamB) Guest Posted: Wed Feb 14, 2007 3:05 am    Post subject: Re: Indy 9 TrivialFTP Questions: "Paul at NCF" <notplmacca (AT) clara (DOT) co.uk> wrote in message news:45d21eae (AT) newsgroups (DOT) borland.com... Quote: If syncronous, and my client app has put("f1.tx") followed by put("f2.txt"), then I would expect the server log to show: "write", "transfer complete" "write", "transfer complete" That is exactly what happens. It can't happen any other way, as the data for the second file is not transmitted until the first file finishes. Also, each UDP packet receives an acknowledgement packet in reply, so the packets for the two transfers cannot be transmitted out of order, either. Quote: but I get "write", "write", "transfer complete", "transfer complete" The only way that is possible is if you have two separate clients uploading at the same time. Gambit Back to top Paul at NCF Guest Posted: Wed Feb 14, 2007 9:10 am    Post subject: Re: Indy 9 TrivialFTP Questions: Hi Quote: That depends on how you are accessing the local files to begin with. You have to make sure that you are providing your TStream objects in a thread-safe manner. If you have two clients accessing the same file at the same time, that would be bad. Yes, I will put exclusive access on write and read, so client retries will be required if this happens. Quote: And in any case, the OnTransferComplete event handler is always synchronized with the main thread. From your other email, no there is only one (test) client I haven't got to running multiples yet, keeping it simple until I understand how it all works. Maybe the syncronize is why the sequence looks strange in the log. But see the overlapped the trace log from the two applications. The lines with "IdTrivialFTPServer" are the server app trace, the others from the client trace. The put completes, but the server end seems to respond with transfer complete some time after the write has finished (1.5s), which seems a long time, and this probably explains why my client repeat 'put' sequence fails if it happens too quickly after the last. 2007-02-14 08:12:36:0067 : Client1File Write 2007-02-14 08:12:36:0067 : Begin Event 2007-02-14 08:12:36:0077 : IdTrivialFTPServerWriteFile (Client1File) 2007-02-14 08:12:36:0077 : Work Event ..... 2007-02-14 08:12:37:0940 : Work Event 2007-02-14 08:12:37:0940 : End Event 2007-02-14 08:12:37:0940 : Client2File Write 2007-02-14 08:12:37:0940 : IdTrivialFTPServerWriteFile (Client2File) 2007-02-14 08:12:37:0940 : Begin Event 2007-02-14 08:12:37:0950 : Work Event ...... 2007-02-14 08:12:39:0432 : Work Event 2007-02-14 08:12:39:0442 : IdTrivialFTPServerTransferComplete (Client1File) 2007-02-14 08:12:39:0442 : Work Event ..... 2007-02-14 08:12:39:0822 : Work Event 2007-02-14 08:12:39:0822 : End Event 2007-02-14 08:12:41:0324 : IdTrivialFTPServerTransferComplete (Client2File) However, just looked at the code for TFTP server (keep forgetting I have it!). The transfer complete is done when the file write thread is destroyed. The file write thread has a default receive timeout of 1.5s. So it looks like the server is timing out on the write operation. Reading further, the rfc1350 says: The end of a transfer is marked by a DATA packet that contains between 0 and 511 bytes of data (i.e., Datagram length < 516). This packet is acknowledged by an ACK packet like all other DATA packets. The host acknowledging the final DATA packet may terminate its side of the connection on sending the final ACK. On the other hand, delaying is encouraged. This means that the host sending the final ACK will wait for a while before terminating in order to retransmit the final ACK if it has been lost. So looks like normal behaviour! So perhaps the client response to a write failure is to wait 1.5s (or so) before retrying the file again. Thanks. Regards, Paul Back to top Paul at NCF Guest Posted: Fri Feb 16, 2007 9:10 am    Post subject: Re: Indy 9 TrivialFTP Questions: Hi Remy, Quote: The transfer complete is done when the file write thread is destroyed. The file write thread has a default receive timeout of 1.5s. So it looks like the server is timing out on the write operation. Reading I've been looking through the code for the server and client for these components in Indy9. Do you think it would be better for the server to release the file handle when the last block has been read/written, and for the server to just keep re-transmitting the last block, or process the last ack? This way the file handle is released early for use, not sure if the transfer complete should also be called then too? Any impacts? I've determined the following behaviour from the code: Server: 1) The receive timeout is the same regardless of buffer size (1.5s). The server has a three retry receive timeout limit. 2) The server waits 4.5s in total if nothing is received (if not processing last block). Otherwise its 1.5s. 3) The server retransmits the previous DATA or ACK block if it receive timeouts. 4) If the client misbehaves when reading and sends an ACK with the wrong block, the server will continuously re-transmit the previous block. Or if the server and client get out of sync (eg. due to buggy implementations). 5) If the client misbehaves when writing and sends a block with an unexpected block number, the server will continuously re-transmit the previous ACK. Or if the server and client get out of sync (eg. due to buggy implementations). Client: 1) Any receive timeout terminates transfer. 2) Only the server checks the block sequences, the client assumes the server block numbers are always correct, and only checks that they increase. Regards, Paul Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (Internet Socket) All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.