UDP服务端send_to返回EINVAL错误，请求技术排查

嘿，我之前也踩过UDP服务端send_to报EINVAL的坑，结合你给出的初始化代码片段，大概率是下面几个地方出了问题，咱们一步步捋：

• 目标地址结构填充错误：这是最常见的触发原因！EINVAL经常因为sockaddr_in结构体的字段没填对而出现：

  • 确认sin_family被手动设置为AF_INET（bzero会把它清0，必须显式赋值）；
  • 客户端的端口号sin_port必须用htons()转换成网络字节序，直接填主机字节序的port_number肯定会报错；
  • 如果是通过hostname指定客户端IP，要确保地址解析正确（比如用inet_aton()或者getaddrinfo()，别直接把字符串塞给sin_addr）。
    正确的填充示例：

  struct sockaddr_in client_addr;
  bzero((char *)&client_addr, sizeof(client_addr));
  client_addr.sin_family = AF_INET;
  // 解析hostname到IP地址
  if (inet_aton(hostname, &client_addr.sin_addr) == 0) {
      error("ERROR invalid hostname");
  }
  client_addr.sin_port = htons(port_number); // 必须转换为网络字节序
  

• send_to的地址长度参数传错：send_to的最后一个参数addrlen必须严格等于sizeof(struct sockaddr_in)（如果是通过recv_from获取的客户端地址，要用当时保存的socklen_t类型的长度值）。要是你传了比如sizeof(int)或者其他错误值，直接就会触发EINVAL。

• 套接字状态异常：虽然你初始化了socket并设置了SO_REUSEADDR，但要确认服务端是否成功执行了bind()操作。UDP服务端虽然可以不bind就调用recv_from，但如果没bind就直接send_to，某些系统下可能会因为套接字未关联本地地址而报错。另外，检查socket创建后有没有被意外关闭或修改了状态。

• 参数顺序或类型错误：再核对一遍send_to的参数顺序：

  ssize_t send_to(int sockfd, const void *buf, size_t len, int flags,
                  const struct sockaddr *dest_addr, socklen_t addrlen);
  

  要是把flags和addrlen搞混，或者dest_addr传了NULL但addrlen不为0，也会触发EINVAL错误。

如果你的代码里bzero之后的客户端地址填充部分有遗漏，优先检查这部分——我当初就是忘了给sin_family赋值，折腾了好久才找到问题！

内容的提问来源于stack exchange，提问作者Arka Pal