(如何)我可以从套接字文件描述符确定套接字系列

发布于 2024-07-13 00:34:14 字数 691 浏览 5 评论 0原文

我正在编写一个 API,其中包括 IPC 函数,这些函数将数据发送到另一个进程,该进程可能位于本地或另一台主机上。 我真的希望发送函数能够像这样简单:

int mySendFunc(myDataThing_t* thing, int sd);

调用者不必知道 - 在 mySendFunc() 调用的直接上下文中 - sd 是否导致本地或远程进程。 在我看来,如果我可以这样:

switch (socketFamily(sd)) {
case AF_UNIX:
case AF_LOCAL:
   // Send without byteswapping
   break;
default:
   // Use htons() and htonl() on multi-byte values
   break;
}

有人建议我可以将 socketFamily() 实现为:

unsigned short socketFamily(int sd)
{
   struct sockaddr sa;
   size_t len;
   getsockname(sd, &sa, &len);   
   return sa.sa_family;
}

但我有点担心 getsockname() 的效率,并且想知道我是否每次都能负担得起我发送。

I am writing an API which includes IPC functions which send data to another process which may be local or on another host. I'd really like the send function to be as simple as:

int mySendFunc(myDataThing_t* thing, int sd);

without the caller having to know -- in the immediate context of the mySendFunc() call -- whether sd leads to a local or remote process. It seems to me that if I could so something like:

switch (socketFamily(sd)) {
case AF_UNIX:
case AF_LOCAL:
   // Send without byteswapping
   break;
default:
   // Use htons() and htonl() on multi-byte values
   break;
}

It has been suggested that I might implement socketFamily() as:

unsigned short socketFamily(int sd)
{
   struct sockaddr sa;
   size_t len;
   getsockname(sd, &sa, &len);   
   return sa.sa_family;
}

But I'm a little concerned about the efficiency of getsockname() and wonder if I can afford to do it every time I send.

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

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

发布评论

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

评论(3

拥抱影子 2024-07-20 00:34:14

请参阅 getsockname(2)。 然后,您检查该系列的struct sockaddr

编辑:作为旁注,有时查询 info 也很有用,在这种情况下 info libc 套接字

编辑:

如果不每次都查找,你真的无法知道。 它不能简单地缓存,因为可以通过关闭并重新打开套接字来重用它。 我刚刚查看了 glibc 代码,似乎 getsockname 只是一个系统调用,这在性能方面可能会很糟糕。

但我的建议是使用某种面向对象的概念。 让用户传递一个指向您之前返回给他的结构的指针,即让他使用您的 API 注册/打开套接字。 然后你可以缓存你想要的关于该套接字的任何内容。

See getsockname(2). You then inspect the struct sockaddr for the family.

EDIT: As a side note, its sometimes useful to query info as well, in this case info libc sockets

EDIT:

You really can't know without looking it up every time. It can't be simply cached, as the socket number can be reused by closing and reopening it. I just looked into the glibc code and it seems getsockname is simply a syscall, which could be nasty performance-wise.

But my suggestion is to use some sort of object-oriented concepts. Make the user pass a pointer to a struct you had previously returned to him, i.e. have him register/open sockets with your API. Then you can cache whatever you want about that socket.

揽月 2024-07-20 00:34:14

为什么不总是以网络字节顺序发送?

Why not always send in network byte order?

无声静候 2024-07-20 00:34:14

如果您控制客户端和服务器代码,我有一个不同的建议,我过去已经成功使用过。

让消息的前四个字节是已知的整数值。 然后接收器可以检查前四个字节以查看它是否与已知值匹配。 如果匹配,则不需要字节交换。

当两台机器具有相同的字节顺序时,这可以使您不必进行字节交换。

If you control the client and server code I have a different suggestion, which I've used successfully in the past.

Have the first four bytes of your message be a known integer value. The receiver can then inspect the first four bytes to see if it matches the known value. If it matches, then no byte swapping is needed.

This saves you from having to do byte swapping when both machines have the same endianness.

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