向文件服务器发送系统调用
我正在使用 C 中的套接字编程设计一个文件服务器。我使用流套接字将 open()、write() 等调用作为纯字符串发送，并在服务器端对其进行解密。即，如果它是一个开放调用，那么我们提取路径、模式、标志。可以吗？或者我应该使用某种结构来存储文件系统调用并发送到服务器，服务器只需访问这些字段。
有一些我不知道的标准方法吗？
谢谢
I was designing a file server using socket programming in C. I send the calls like open(), write() etc as plain strings using stream sockets and decipher it at the server end.i.e if it is a open call then we extract path, mode, flags. Is it ok or should I be using some kind of struct to store the file system calls and send to server where the server simply accesses the fields.
Is there some standard way i don't know?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您基本上开始定义自己的协议。如果您发送描述操作的数字而不是字符串，则会容易得多。
如果您对此很认真，您可能需要研究
RPC- RFC707（您确实要求一种标准方式，对吧？）。You're basically starting to define your own protocol. It would be a lot easier if you sent numbers describing operations instead of strings.
If you're serious about this you might want to look into
RPC- RFC707 (you did ask for a standard way, right?).是的，有一个标准的方法。查看NFS，法新社，CIFS 和 WebDAV，然后选择一个。
Yes, there is a standard way. Look into NFS, AFP, CIFS, and WebDAV, then pick one.
您已经有了标准方法的答案，因此我将向您提供一些您应该注意的警告。
如果您打算将文件服务器部署在不受信任的环境中（例如在 Internet 上），请考虑立即保护它。确保其安全不仅仅是加密的问题 - 您需要知道您打算如何验证用户身份，您希望如何授权对服务器不同部分的不同类型的访问，您将如何确保数据的真实性和完整性以及您打算如何保密数据。
您还需要考虑服务器的可用性。这意味着您应该具有容错能力 - 即连接可以（并且将会）中断（无论它们是否故意中断），因此您需要检测到这一点，或者某种保持活动状态（这将如果客户端离开则失败）或某种活动超时（如果客户端离开则超时）。您还需要考虑您愿意同时支持多少个客户端 - 这可以从根本上改变您的服务器的体系结构。
至于打开、关闭、读取、写入等命令，大多数文件传输协议不会详细说明，但根据您的情况执行此操作可能会很有趣。如果您的文件很大并且您只需要其中的一些块，或者如果您希望能够锁定文件以专门处理它们，等等，您可能需要了解这些细节。如果您没有这些要求，可以使用更简单的事务性命令，例如 get & put（而不是打开、读取、读取、读取、关闭和打开、写入、再写入一些、关闭）可能更容易实现，也更容易使用。
如果您希望人类与您的服务器交互并给它发出命令，文本是一个很好的方法：嗅探时很容易调试，而且人类理解文本并且可以轻松键入。如果没有人参与，使用整数作为命令可能是更好的方法：您可以构造命令以整数开头，后跟多个参数，并且总是简单地期望服务器端有相同的事情（并执行
切换您收到的命令）。但即使在这种情况下，在整数中包含人类可读的值也可能是个好主意。例如，将'READ'放入整数中作为读取命令，使用与0x00000001一样多的字节，但在使用 WireShark 嗅探时更容易读取。最后，您真正了解一下标准方法并尝试了解每种情况下所做的权衡。例如，问问自己为什么 HTTP 有如此冗长的标头以及 WebDAV 为什么使用它。为什么 FTP 使用两个连接（一个用于命令，一个用于数据），而许多其他协议仅使用一个连接？ NFS 是如何发展到现在的样子的，为什么？了解这些问题的答案将帮助您制定自己的协议 - 如果在您了解这些答案后，您仍然觉得需要自己的协议。
You already have answers for the standard way, so I'll give you a few caveats you should look out for.
If you intend to deploy your file server in an un-trusted environment (e.g. on the Internet) think about securing it right away. Securing it is not just a question of slapping encryption on - you need to know how you intend to authenticate your users, how you want to authorize different types of access to different parts of the server, how you will insure the authenticity and the integrity of the data and how you intend to keep the data confidential.
You'll also need to think about your server's availability. That means that you should be fault-tolerant - i.e. connections can (and will) break (regardless of whether they're being broken on purpose or not) so you need to detect that, either will some kind of keep-alive (which will fail if the client left) or with some kind of activity time-out (which will expire if the client left). You also need to think about how many clients you are willing to support simultaneously - which can radically change the architecture of your server.
As for the open, close, read, write etc. commands, most file transfer protocols don't go into so much detail, but it may be interesting to be able to do so depending on your situation. If your files are huge and you only need some chunks of it, or if you want to be able to lock files to work on them exclusively, etc. you may want to go into such detail. If you don't have those requirements, simpler, transactional commands such as get & put (rather than open, read, read, read, close and open, write, write some more, close) may both be easier to implement and easier to work with.
If you want a human being to interact with your server and give it commands, text is a good approach: it's easy to debug when sniffing and humans understand text and can type is easily. If there are no humans involved, using integers as commands is probably a better approach: you can structure your command to start with an integer followed by a number of parameters and always simply expect the same thing on the server's end (and do a
switchon the command you receive). Even in that case, though, it may be a good idea to have human-readable values in your integers. For example, putting'READ'in an integer as the read command uses as many bytes as0x00000001, but is easier to read when sniffed with WireShark.Finally, you really take a look at the standard approaches and try to understand the trade-offs made in each case. Ask yourself, for example, why HTTP has such verbose headers and why WebDAV uses it. Why does FTP use two connections (one for commands and one for data) while many other protocols use only one? How did NFS evolve to where it is now, and why? Understanding the answers to these questions will help you develop your own protocol - if after you understand those answers, you still feel you need your own protocol.