一种将 FTP 连接从守护进程移交给 Rails 应用程序的方法?

发布于 2024-10-20 15:17:39 字数 624 浏览 5 评论 0原文

我将创建一个 C 或 Ruby 守护程序,它将创建 FTP 连接、保持连接处于活动状态(即池连接),并充当我的 Rails 应用程序的 FTP 站点的代理。这将允许我的 Rails 应用程序通过 AJAX 调用与 FTP 站点进行通信,而不必在每次 AJAX 调用时重新连接到 FTP 站点。

我希望守护进程能够池化连接,但是,我不想将其用作代理,因为这是额外的功能,因此需要额外的时间。

我的问题:如果我在守护进程中打开 FTP 连接,是否有办法简单地将连接从守护进程移交给我的 Rails 应用程序?

因此,我不想在我的 Rails 应用程序中执行此操作,而是

connection = Net::FTP.new('my.site.com')
connection.login
connection.get(remote_file_path, local_file_path)

想做这样的事情

daemon_reference = ???
connection = daemon.getConnection(some_key)
connection.get(remote_file_path, local_file_path)

I am going to make either a C or a Ruby daemon which will create FTP connections, keep the connections alive (ie. pool connections), and act as a proxy to FTP sites for my Rails app. This will allow my Rails app to communicate with FTP sites across AJAX calls and not have to reconnect to FTP sites with each AJAX call.

I'd like the daemon to pool connections, but, I'd like to not have to use it as a proxy because that's extra functionality and thus extra time.

My question: If I open an FTP connection in my daemon process, is there a way to simply hand off connections from the daemon to my Rails app?

So rather than do this in my Rails app

connection = Net::FTP.new('my.site.com')
connection.login
connection.get(remote_file_path, local_file_path)

I'd like to do something like this

daemon_reference = ???
connection = daemon.getConnection(some_key)
connection.get(remote_file_path, local_file_path)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

野心澎湃 2024-10-27 15:17:39

通常,您不能将连接从一个进程移交给另一个进程,但有一个例外:分叉时,子进程将继承父进程的所有连接。正常的 fork 操作会为子进程留下与父进程相同的文件描述符集,并且所有打开的套接字都包含在该集中。不过,这是一项一次性操作,因为新的文件描述符将仅在一个进程的上下文中创建。

您可能需要代理才能使其工作,但这不会太难。您只需要一种方法让外部进程请求连接、使用该连接,然后将连接释放到池中。这可以通过 FTP 方式完成,您在一个套接字上进行通信,第二个套接字充当数据通道。

这并不像听起来那么棘手。您可以创建一个名为“proxy.sock”的 UNIX 套接字并让客户端连接到该套接字。一个命令可以请求连接到特定的 FTP 目标,并且它将获得一条返回路径,例如“ftp.example.com.sock”,它可以使用该路径连接到该位置。在这一点上,将一个流套接字桥接到另一个流套接字并不是很棘手,并且检测套接字何时在本地端关闭是例行公事。

UNIX 套接字比 TCP 套接字更方便,因为您不必担心端口号的分配或耗尽。

Generally you cannot hand off connections from one process to another with one exception: When forking, the child process will inherit all connections from the parent. A normal fork operation leaves the child with the same set of file descriptors as the parent, and any open sockets are included in this set. This is a one-time operation, though, as new file descriptors will be created within the context of one process only.

You will probably have to proxy in order for this to work, but that won't be crazy hard. You'll just need a way for your external process to request a connection, make use of the connection, and then release the connection into the pool. This could be done FTP style where you communicate on one socket, and a second acts as a data channel.

This isn't as tricky as it sounds. You could create a UNIX socket called "proxy.sock" and have clients connect to that. One command could request a connection to a particular FTP destination and it would get a path back like "ftp.example.com.sock" which it can use to connect to that location. Bridging one stream socket to another isn't very tricky at that point and detecting when the socket is closed on the local end is routine.

UNIX sockets can be more convenient than TCP sockets since you won't have to worry about allocating, or running out of port numbers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文