C语言实现TFTP Server测试时RRQ请求多数异常求助

看起来你遇到的TFTP服务器RRQ请求不稳定的问题，大概率是UDP传输特性或者TFTP协议细节没处理到位——毕竟UDP是无连接的，很容易丢包、乱序，而TFTP对报文顺序、确认机制要求得特别严格。结合你提到的857字节文件（刚好需要2个512字节块+1个小于512的结束块），我整理了几个最可能的排查方向：

1. UDP地址处理是否正确？ #

TFTP服务器在收到RRQ后，必须用客户端请求里携带的IP和端口来回复数据块，而不是用固定端口或者默认地址。如果你的代码里没正确保存客户端的struct sockaddr_in信息，或者sendto时地址参数写错，大部分情况下客户端会收不到数据，只有凑巧地址匹配时才会成功。

• 检查recvfrom调用时，是不是正确传递了客户端地址长度的指针（socklen_t *类型），很多新手会直接传值导致地址信息获取错误；
• 后续发送数据块时，必须复用第一次接收RRQ时拿到的客户端地址，不能重新初始化或者用其他地址。

2. TFTP数据块的编号与确认逻辑有没有漏洞？ #

TFTP的核心规则：

• 数据块编号从1开始，每个块发送后必须等待对应编号的ACK确认，才能发送下一块；
• 最后一块数据长度小于512字节时，客户端收到后就会判定传输结束。

如果你的代码存在以下问题，就会出现不稳定的情况：

• 块号从0开始，或者发送后没递增编号；
• 没等待ACK就连续发送所有块（UDP无连接，乱序丢包概率极高）；
• 最后一块还按512字节发送（填充了多余字节），导致客户端一直等待下一个块。

3. 缓冲区与报文格式是否符合规范？ #

TFTP的DATA报文格式是固定的：0x0003（操作码，2字节） + 块号（2字节） + 数据内容（最多512字节）。这里容易踩的坑：

• 字节序问题：TFTP用大端字节序，x86平台是小端，所以操作码、块号必须用htons()转换后再放入报文；
• 数据长度问题：你的buffer是512字节，但最后一次读取文件时实际字节数是857-512=345，发送时报文总长度应该是4+345字节，而不是固定的4+512；
• 检查fread的返回值，不要默认每次都读满512字节，要根据实际读取的字节数来构造报文。

4. 缺失超时重传机制 #

UDP没有丢包重传的特性，TFTP协议要求如果发送数据块后一定时间内没收到ACK，必须重传该块。如果你的代码里没有超时等待逻辑，一旦某个块丢包，传输就会卡住，只有网络完全无丢包时才能成功——这刚好对应你说的“极少数情况正确”。

可以用select()实现超时等待，比如设置5秒超时，超时后重新发送当前块，直到收到对应ACK：

// 示例：发送DATA块并等待ACK的核心逻辑
uint16_t block_num = 1;
int bytes_read;
char buffer[512];
struct sockaddr_in client_addr;
socklen_t client_addr_len = sizeof(client_addr);

// 假设已解析RRQ、打开文件、获取到客户端地址
while ((bytes_read = fread(buffer, 1, 512, fp)) > 0) {
    // 构造DATA报文
    char data_packet[516];
    *(uint16_t*)data_packet = htons(3); // DATA操作码
    *(uint16_t*)(data_packet + 2) = htons(block_num);
    memcpy(data_packet + 4, buffer, bytes_read);

    int ack_received = 0;
    while (!ack_received) {
        sendto(sockfd, data_packet, 4 + bytes_read, 0, 
               (struct sockaddr*)&client_addr, client_addr_len);

        // 设置5秒超时
        fd_set read_fds;
        FD_ZERO(&read_fds);
        FD_SET(sockfd, &read_fds);
        struct timeval tv = {5, 0};

        int select_ret = select(sockfd + 1, &read_fds, NULL, NULL, &tv);
        if (select_ret == -1) {
            perror("select error");
            break;
        } else if (select_ret == 0) {
            // 超时重传
            continue;
        } else {
            // 接收并验证ACK
            char ack_packet[4];
            recvfrom(sockfd, ack_packet, 4, 0, 
                     (struct sockaddr*)&client_addr, &client_addr_len);
            uint16_t op_code = ntohs(*(uint16_t*)ack_packet);
            uint16_t ack_block = ntohs(*(uint16_t*)(ack_packet + 2));
            if (op_code == 4 && ack_block == block_num) {
                ack_received = 1;
                block_num++;
            }
        }
    }

    // 最后一块（长度<512），结束传输
    if (bytes_read < 512) break;
}

最后再提几个容易忽略的细节：

• 一定要检查fread、sendto、recvfrom的返回值，排查潜在的读写/网络错误；
• 服务器的UDP套接字不需要绑定客户端端口，保持监听状态即可，每次用recvfrom获取客户端地址后回复。

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