其实是想实现类似微信语音的效果，在发送方录制完音频后读取音频文件，一部分一部分地通过udp发出去，在接受方一部分一部分地接收保存到文件中。那么问题就是接收方怎么判定一个文件接收完了可以读取播放了。对udp的理解只停留在面向无连接，不可靠传输，但效率比较高，实时性比较好这个层面上。
发之前把文件MD5发出去，收完校验下就晓得了
客户端回传一个ack包，包含此消息的ID，如果最后收不到特定消息的ack把这个消息放入重发队列。
1)你确定要用UDP传语言文件吗？按照你的描述，语音已经本地保存为文件了，不是实时的传送。所以我觉得还是用tcp比较合适你的场景。
2）如果实在要用udp传文件，那需要你应用层来设计应答，重传，重排序等tcp本来就支持的机制。当然也包括结束声明。
使用适当的文件格式也许可以在应用层判断
如果这个语音要在录制完成后才开始发送，我怀疑它的“实时性”不值得放弃TCP
UDP是无状态的只管杀不管埋, 包发出去了, 按照UDP协议, 接收方不给你发送任何回执(所以发送发本来就不确定包到底是否到达, 这就是UDP的代价) 如果不使用TCP的话, 你可以自己在接收方收到数据后, 给发送方回传一个消息; 继续添加这种出错控制就基本上实现了TCP协议..
如何确定文件接收完毕
可以通过 接收方 回传一个 确认传输完毕的udp包 来增强可靠性。
引申
但是如果回传的这个udp包丢了怎么办，传送方因为没有收到确认数据而再次重试怎么办？
可以使用MsgID的机制对 消息/数据 去重。
但是讲道理，像问题中描述的这种 Server2Client/Client2Client 的数据传输情景应用，使用UDP是不合理的。
包含了内网穿透等诸多问题。
而且，TCP 相对于 UDP 的 效率/资源 问题也不是那么的不可忽略，同样也可以用很多方法去规避TCP的劣势。
比如尽量对 TCP 长连接的复用，等等。
如果使用 TCP 传输数据，每传一个包就重新建立一次连接，也不合理不是吗？