I have a client trying to upload multiple files to FTP server in passive mode.
The client sends PASV command and the server responds with the relevant ip and port.
Is it possible to send multiple files on this one data connection? or the client need to send the PASV command and get a new port for each file?
Since the only indicator of the end of file is the close of the connection and because you cannot transfer any more data after the connection has closed, you will not be able to transfer more than one file using the same data connection.
But, maybe you tried to ask a different question, that is if is possible to have multiple data transfers (and thus multiple data connections) after a single PASV command? I can see nothing in RFC959 which directly would prevent this and reusing the same target port on the server. And because access would be done from different source ports on the client this should also not give problems with TCP connection states. But, in practice you will probably see problems because if you try to use this from the client side, because lots of servers create the listener only for a single data connection. So you better precede each data transfer with a new PASV command, like existing clients do.
Related
I have TCPListener server based on this source code https://gist.github.com/leandrosilva/656054#file-server-cs
I created a server on port 3340. Whenever a client connects to the server, then server waits for the new client connection. When I connect from my Chrome browser to the server, then it seems there are three clients connected (expected only one).
Why it is like that?
Most clients maintain multiple connections in parallel, including more than one connection per server endpoint.
And RFC7230 section-6.4 explains. Multiple connections are typically used to avoid the "head-of-line blocking" problem
I've scenario where ftp client and server are separe with a proxy server.
I want to insert ip source address into ftp client payload so that the ftp server can retrieve it.
The problem is that i don't know how to proceed.
Help me out please.
With regards.
FTP is text-based protocol.
If you can re-implement both the client and the server, just make them understand a new command for your purpose.
E.g. you can have the client send a XIP command just after authentication (or even before, if you need):
XIP 203.0.113.0
The server will just parse the IP and respond something like this (to follow the FTP specification):
200 OK
And then carry on as in a normal FTP session.
I always thought that when FTP data connection opens, it transfers data only in one way.
Now I found out that both sides can transfer data on the opened data connection.
My questions:
What is it used for? I read that it can be used to transfer files over SSL, so the bi-directional is used for negotiation, but then why not using ftps?
Data connection opens for transfer of files and listing (anything else?). So what should the sending side do when it receives data from the other side? how would it process it?
Are there clients supporting this behavior?
Is it common?
You are correct that FTP RFC really mentions possibility that data connection is used bi-directionally:
It ought to also be noted that the data connection may be used for simultaneous sending and receiving
But it's likely that the RFC authors just wanted to make sure such option is available for future features of the protocol.
But as far as I know, there's actually no such feature that make use of bi-directional data connection.
The FTP protocol does not allow simultaneous transfers at all, neither in the same nor opposite direction.
Currently the data connection is used:
For downloads, where only the server sends data.
For uploads, where only the client sends data.
For directory listings, where only the server sends data.
Regarding FTPS: Indeed if the data connection is encrypted using TLS/SSL, the connection is used bi-directionally on TCP-level, when the client and the server negotiate the encryption. But I do not think this is what the RFC refers too, as SSL/TLS did not exist at the time and the negotiation is out of scope of FTP protocol anyway.
Is it possible to create a website that makes possible this scenario:
User A logs into the website, uploads a file making a direct TCP connection to user B that it is within the same site at same time downloading the file. Without passing the file trough the server.
How to make user B to listen through a browser?
Would this violate "Same origin policy"?
Point is to use browser and no other software like P2P clients.
Is this crazy idea possible?
I doubt webRTC covers exactly what you need.
You have two issues:
B, if running from a web browser, cannot open a port to receive an inbound connection
Even if B were able to do that, you will likely have to face NAT traversal issues.
The solution is to use/implement a relay server:
A opens an outbound HTTP/Websocket connection to the relay server
B opens an outbound HTTP/Websocket connection to the relay server
A sends data to the relay server on the outbound channel (HTTP POST for instance)
B reads data from the relay server on the response (to an HTTP GET for instance)
Easier said than done.... (and yes it is a feature of advanced P2P networks like JXTA, XMPP, Skype..., and yes you unfortunately need an intermediate server)
Check ICE for a specification of 'how to do NAT traversal'
Sure, it's called P2P. You don't even need Ajax.
What I was looking is: WebRTC.
Others have mentioned WebRTC, but here is a live example:
http://sharefest.me
I have a multi-user Ruby on Rails web application that can interact with an FTP server via AJAX. The application allows the user to browse an FTP site. Javascript makes an AJAX call which communicates with a server-script that returns a list of files and directories within a given directory.
This works fine. However, each time a directory listing is requested, the server must re-establish a connection with the FTP server, which takes a lot of time. I'm looking for a way to leave the FTP connection open for until some number of timeout seconds.
I could probably do this using threads (though, I'm completely open to other ideas) or some fancy connection-pooling scheme (perhaps via a daemon that manages this).
What are some ways I could persist and regain reference to connections in my ruby source?
Someone suggested using a "Connection: Keep-Alive" header, but I don't see how that would help in this case.
Not a complete answer, but if you did have some sort of daemon or something managing the connection, you could use TCP keepalives to keep the control connection alive for an extended period of time.
FTP uses two connections. A control connection is established client-to-server, and data connections are established server-to-client for each request. So each directory listing or GET would prompt another data connection to be opened for the duration of the request.
You shouldn't worry about keeping lots of listening sockets open because the data connections are negotiated over the control connection just prior to being established. (Also the data connections could be made client-to-server instead of server-to-client by using passive mode if you want, but it's still a separate connection.)
Either way, I think the source of sluggishness is more to do with closing and reopening the control connection (and authenticating) for each request. I think if you have some process that keeps the control connection open using TCP keepalives (SO_KEEPALIVE socket option), you'll see a big improvement.