TCP_WINDOW_UPDATE received by FTP listener

[martinh]

Hi Mark,

we are using uTasker's ftp-server to update the embedded application. Together with TotalCommander this does a good and reliable job.
Now we intend to integrate TotalCommander's part into the application that runs under Windows using the Indy ftp-client from C++ Builder XE4.
That does not work.
I compared the events received by fnFTPListener() and found that our Windows application (created by C++ Builder, i.e.the Indy ftp-client) sends
event 0x0B (TCP_WINDOW_UPDATE), which TotalCommander does not do.
This happens at a very early stage:
   events received
   08   TCP_EVENT_CONREQ
   02   TCP_EVENT_ACK
   04   TCP_EVENT_DATA
   0b   TCP_WINDOW_UPDATE
   ...
Indy's documentation offers several settings for the ftp-client but it is very unprecise about which one to chose.

Ignoring this event on uTasker's side by adding 'case TCP_WINDOW_UPDATE: break;' to the event listener did not help.

I understand that this event is used for flow control between the peers, but the question remains how uTasker should react.
Or - as 0x0B obviously is not required - perhaps somebody knows (or could give some hints) what settings are required for creating the ftp-client.

Regards,
Martin H.

[mark]

Hi Martin

The FTP server uses a simple TCP socket (not a buffered one) and so is not interested in the TCP_WINDOW_UPDATE event.
The event will be received when the peer sends an ACK which informs of a change in the peer's input window size (although it may also be an ACK with the same size or with data).
This event may or may not be received, depending on the FTP client/TCP-socket being used but whether it does or not won't change behaviour and the FTP server's response to it (return value) is also not of importance.

I don't expect that this will explain any behavioural differences between FTP clients.

Note that there are some clients which can't work with the FTP server as it is; usually because they want to use multiple data connections (whereas only one data connection is supported). The reason is probably visible from a WireShark recording [please post one - maybe a comparison between the two clients].

Regards

Mark

[martinh]

Hi Mark,

thanks a lot for your reply.

We meanwhile received the latest update of C++ Builder. Your remark regarding multiple data connections caused us to modify some options. Finally, disabling the option 'UseHost' for the compilation of the ftp client most likely solved the problem.
I say 'most likely' because the job has not yet been finished. But at least the client can connect to the server and receives a response, I was told.
We will still have to do some further investigation.

Regards,
Martin