对于 C 守护进程来说，基于套接字的协议应该是什么样子？
我正在编写一个 C 守护进程，我的 Web 应用程序将使用它作为与 FTP 服务器通信的代理。我的 Web 应用程序使用户能够通过 AJAX 连接 FTP 站点并与之交互。我需要 C 守护进程的原因是我无法在 AJAX 调用之间保持 FTP 连接处于活动状态。
我的 Web 应用程序需要能够告诉我的守护进程为给定的用户帐户将文件列出、获取、放置、删除、移动和重命名到给定的 FTP 服务器。因此，当我的应用程序与守护进程对话时，它需要通过我定义的某些协议传递以下内容：1）操作，2）连接ID，3）用户ID，4）操作的任何其他参数（注意：连接信息存储在一个数据库，因此守护进程也会与之对话）。
这就是我需要我的守护进程做的事情。我认为我的网络应用程序和守护进程之间的通信将通过 TCP 套接字进行，但我不知道我要发送什么数据。我需要一个例子。例如，我应该通过套接字向守护进程发送类似的内容吗？
action=list&connection_id=345&user_id=12345&path=/some/path
或者我应该在字节级别做一些硬核的事情，就像这样？
+-----------------+-------------------------+-------------------+-----------------------------------+
| 1 byte (action) | 4 bytes (connection id) | 4 bytes (user id) | 255 bytes (additional parameters) |
+-----------------+-------------------------+-------------------+-----------------------------------+
| 0x000001 | 345 | 12345 | /some/path |
+-----------------+-------------------------+-------------------+-----------------------------------+
通过套接字进行的这种通信通常是什么样的？
I am writing a C daemon which my web application will use as a proxy to communicate with FTP servers. My web application enables users to connect and interact with FTP sites via AJAX. The reason I need a C daemon is that I have no way of keeping FTP connections alive across AJAX calls.
My web application will need to be able to tell my daemon to do list, get, put, delete, move, and rename files to a given FTP server for a given user account. So when my application talks to the daemon, it needs to pass the following via some protocol I define: 1) action, 2) connection id, 3) user id, 4) any additional parameters for action (note: connection information is stored in a database, so the daemon will talk to that as well).
So that's what I need my daemon to do. I'm thinking communication between my web app and the daemon will take place via a TCP socket, but I don't know exactly what data I would send. I need an example. For instance, should I just send something like this over the socket to the daemon?
action=list&connection_id=345&user_id=12345&path=/some/path
or should I do something hardcore at the byte level, like this?
+-----------------+-------------------------+-------------------+-----------------------------------+
| 1 byte (action) | 4 bytes (connection id) | 4 bytes (user id) | 255 bytes (additional parameters) |
+-----------------+-------------------------+-------------------+-----------------------------------+
| 0x000001 | 345 | 12345 | /some/path |
+-----------------+-------------------------+-------------------+-----------------------------------+
What does such communication over a socket normally look like?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上，这主要是关于最容易编码和解析的格式，这就是为什么我个人会使用现有的远程过程调用解决方案，而不是用我自己的协议重新发明轮子。我的第二个选择是位域，因为它很容易打包进或打包出结构。
Really it's mostly about whatever format is easiest for you to encode and parse, which is why rather than reinventing the wheel with my own protocol, I personally would go with an existing remote procedure call solution. My second choice would be the bitfields, as that's easy to pack into and out of a struct.
您不一定需要实现自己的协议。您是否考虑过使用 XML-RPC 之类的东西，甚至只是简单的 XML？有一些 C 库可以让您解析它。
You don't necessarily need to implement your own protocol. Have you thought about using something like XML-RPC, or even just plain XML? There are C libraries that should let you parse it.
二进制协议更容易处理一些。只需将长度添加到消息（或只是消息的可变部分） - TCP 不知道您的应用程序级消息边界。注意数字字节序。
另一方面，基于文本的协议更加灵活。
另外，请查看 Google Protocol Buffers - 可能非常有用，虽然我不确定是否支持ajax。
Binary protocols are a bit easier to deal with. Just prepend the length to the message (or just the variable part of it) - TCP doesn't know about your application-level message boundaries. Pay attention to number endianness.
On the other hand, text-based protocols are more flexible.
Also, take a look at Google Protocol Buffers - could be very useful, though I'm not sure ajax is supported.