vxworks实现的tftpd的实现缺陷

最近有同事问起我以前修改vxworks tftpd server的代码的原因，想了半天没有想起来。直到有当时的同事提醒了我，才记得是这么回事：

vxworks实现tftpd的时候，通过server socket接收tftp请求，然后创建一个单独的任务进行文件的传输。但是为了减少对系统的负载及（此处省略一堆字）原因，对能够同时服务的tftp请求的数量进行了限制，使用的同步机制是消息队列。ftpd的流程大概是：

loop start: 从server socket接收一条命令
等待可用的连接（使用消息队列），如果当前连接数量达到上限，则等待。
创建任务进行文件传输，然后转到loopstart.

而进行文件传输的任务就是传输文件，然后通过发送消息到消息队列，以通知主任务，现在可以处理新的tftp请求了。

问题来了，由于tftp client的发送到server，消息被缓存在server socket中，当连接已满的情况下，可能会过很长的时候，才轮到它被主任务读出，并进行处理，而此时client侧已经超时。尤其是如果client在超时中重发tftp请求，则会让情况变得更坏，坏到tftpd server读出来的每个请求都已经超时。