编写udp服务器

1.注意要点：

既然他不可靠为什么还要用呢？

如果一方的数据报丢失，那另一方将无限等待，解决办法是设置一个超时重传机制；

2.udp实现过程图：

由于udp是一种不可靠的传输协议，若出现丢包问题，此时recvfrom函数将会阻塞式等待数据的到来；

　 　返回：非负描述字－－－成功　　　-1－－－失败

第一个参数指明了协议簇，目前支持5种协议簇，最常用的有AF_INET(IPv4协议)和AF_INET6(IPv6协议)；第二个参数指明套接口类型，有三种类型可选：SOCK_STREAM(字节流套接口)、SOCK_DGRAM(数据报套接口)和SOCK_RAW(原始套接口)；如果套接口类型不是原始套接口，那么第三个参数就为0。

返回：0－－－成功　　　-1－－－失败　

　　第一个参数是socket函数返回的套接口描述字；第二和第第三个参数分别是一个指向特定于协议的地址结构的指针和该地址结构的长度。

返回接收到数据的长度－－－成功　　　-1－－－失败　

　　前三个参数等同于函数read()的前三个参数，flags参数是传输控制标志。最后两个参数类似于accept的最后两个参数。

返回发送数据的长度－－－成功　　　-1－－－失败　

　　前三个参数等同于函数read()的前三个参数，flags参数是传输控制标志。参数to指明数据将发往的协议地址 　　

3.应用层实现采用超时重传,实现udp的可靠传输

在规定的时间内，若没有收到sendto的信息，我们就认为数据包丢失，打破recvfrom的阻塞式等待，设置一个闹钟定时器alarm,当收到SIGALRM信号时，程序中断，转去处理中断响应函数，通知客户端进行重传；

alarm函数：

功能：从调用该函数开始，seconds秒之后向进程发送一个SIGALRM信号

仅仅只是这样是不够的！！！

看到这里也许你以为一切都解决了，但是还有一个容易被人忽视的问题：在Linux中，默认处理中断的方式是： 当从中断调用返回时，继续执行被中断的系统调用（用在刚才说的例子上就是：继续redvfrom……）这中默认处理方式大多数时候很有用，但是我们这里就不行了，那这个问题怎么解决呢？要解决这个问题，就不能单纯的用signal函数去设置中断处理程序了，而是要用另一个函数：sigaction

功能：拦截下signum消息，用act所给的方式处理，将原来的处理方式存在oldact（一般oldact设为NULL）;

参数： signum：需要拦截的消息，这里是SIGALRM； act：处理中断的方式，是一个结构体，后面会介绍这结构体； oldact：用来存储原来的处理方式，一般为NULL，表示忽略；

结构体：struct sigaction介绍：

struct sigaction { void (*sa_handler)(int); sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void); } 成员：第一个sa_handler就是中断处理程序的入口，比如：要用alarm程序处理这个中断，就讲此值设为alarm； sa_mask：表示在中断处理中要屏蔽的中断； sa_flags：这是很关键的东西～它包含了一些影响中断处理过程方式的标志，具体取值如下： SA_NOCLDSTOP：这表示如果所处理的中断是SIGCHLD，由于收到其他信号而导致了子进程终止，将不发送SIG_CHLD; SA_ONESHOT or SA_RESETHAND：sa_handler所指向的中断处理程序只被执行一次，之后将设为默认的中断处理程序； SA_RESTART：让被处理的系统调用在中断返回后重新执行； SA_NOMASK or SA_NODEFFER（这就是我们要用的）：在中断处理程序执行时，不屏蔽自己的中断信号；在处理此信号未结束前不理会此信号的再次到来。

signal与sigaction函数区别： signal是重启动函数，超时以后会自动启动已阻塞的函数，而不是中断它的执行，比如recvfrom，给人的感觉就是使用了alarm，程序依然阻塞在了recvfrom上，不往下执行，如果在信号处理函数中使用printf可以看到超时后输出了一条超时信息，然后signal又启动了recvfrom，继续阻塞。。。sigaction可以自己设置是否重启动函数，即上面例子中的alrmact.sa_flags = SA_NOMASK选项，SA_NOMASK为不重启动，中断已阻塞的函数recvfrom，使程序继续往下执行，SA_RESTART为重启动函数，与signal相同，继续阻塞在recvfrom上。。。

4.自己根据逻辑实现代码

udp_server.c