recvfrom

sendto 头文件 ： #include <sys/types.h> #include <sys/socket.h> 定义函数 ： int sendto(int s, const void * msg, int len, unsigned int flags, const struct sockaddr * to, int tolen); 参数说明 ： s：一个标识套接口的描述字。 buf：包含待发送数据的缓冲区。 len：buf缓冲区中数据的长度。 flags：调用方式标志位。 to：（可选）指针，指向目的套接口的地址。 tolen：to所指地址的长度。 函数说明 ： sendto() 用来将数据由指定的socket 传给对方主机. 参数s 为已建好连线的socket, 如果利用UDP协议则不需经过连线操作. 参数msg 指向欲连线的数据内容, 参数flags 一般设0, 详细描述请参考send(). 参数to 用来指定欲传送的网络地址, 结构sockaddr 请参考bind(). 参数tolen 为sockaddr 的结果长度. 返回值 ： 成功则返回实际传送出去的字符数, 失败返回－1, 错误原因存于errno 中. 错误代码 ： 1、EBADF 参数s 非法的socket 处理代码. 2、EFAULT 参数中有一指针指向无法存取的内存空间. 3、WNOTSOCK

因为项目需要，接触和使用了Netty，Netty是高性能NIO通信框架，在业界拥有很好的口碑，但知其然不知其所以然。 所以本系列文章将从基础开始学起，深入细致的学习NIO。本文主要是介绍五种I/O模型，概念是枯燥的，不过还是得理解才行。 LINUX与UNIX中一些概念 在网络管理,Linux UNIX很相似.UNIX系统一直被用做高端应用或服务器系统,因此拥有一套完善的网络管理机制和规则, Linux沿用了这些出色的规则,使网络的可配置能力很强,为系统管理提供了极大的灵活性. 通俗一点讲，就是在网络方面Linux和UNIX是非常相似的，网络模型大可借鉴UNIX网络编程中的描述。 这里介绍四个概念，方便五种I/O模型的理解： 1.所有外部设备皆文件 Linux的内核将所有的 外部设备都看作是一个文件 来操作，对一个文件的读写操作会调用内核提供的系统命令，返回一个file descriptor（fd，文件描述符）。 面对一个socket也会有相应的描述符，成为socketfd(socket描述符)，描述符就是一个数字，他指向内核中的一个结构体（文件路径，数据区等一些属性）。 2.recvfrom（）函数 ssize_t recvfrom(int sockfd, void *buff, size_t nbytes, int flags, strut sockaddr *from,

TCP协议与UDP协议 TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket， 因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。 UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。 不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。 tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），那也不是空消息，udp协议会帮你封装上消息头。 TCP与UDP的不同接包处理方式 1.TCP的发包问题 问：tcp 发送两次数据，第一次发送100字节 ，第二次发送200字节，

client中： sendto(sfd,buf,strlen(buf),0,(struct sockaddr *)&saddr,len); recvfrom(sfd,buf,sizeof(buf),0,NULL,NULL); server中： recvfrom(fd,buf,sizeof(buf),0,(struct sockaddr *)&caddr,&len); 将网络字节序的IP地址转换成字符串输出 // inet_ntoa : struct ip -> char *ip char *paddr = NULL; paddr = inet_ntoa(caddr.sin_addr); printf("client[%s] say:%s\n",paddr,buf); sendto(fd,buf,strlen(buf),0,(struct sockaddr *)&caddr,len); struct sockaddr_in saddr; socklen_t len = sizeof(saddr); sendto最后两个参数是(struct sockaddr *)&saddr【 saddr 是自己 新建的sockaddr_in型的变量】, len【len 是socklen_t型的变量 其值为sizeof(saddr)】在client和server的编程中相似。

I/O模型(I/O Models) 阻塞式I/O（blocking I/O） 非阻塞式I/O（nonblocking I/O） I/O多路复用（I/O multiplexing） 信号驱动I/O（signal driven I/O） 异步I/O（asynchronous I/O） 对于一个network I/O涉及两个系统对象，一个是调用I/O的进程(process)，另一个是系统内核(kernel)。 下面用read操作来当做例子，当一个read操作发生时涉及的两个步骤： 等待内核将数据准备好 内核将准备好的数据拷贝到进程，也就是从kernel space拷贝到user space 对于一个socket的read操作，第一步通常是等待网络数据。当包到达时，会先拷贝到内核的内存中。然后第二步，把数据从内核的缓冲区拷贝到应用程序的缓冲区。 阻塞式I/O(blocking I/O) 姜太公钓鱼，愿者上钩。鱼竿丢下去，就等到鱼上来，啥事不干，啥事也干不了。 当应用程序调用recvfrom这个system call，kernel只有等到准备好数据，把数据拷贝到应用程序的缓冲区，才会返回。应用程序在调用recvfrom后，如果kernel没有准备好数据，会被“睡觉”。进程一直阻塞着，在呼叫recvfrom这个system call之后，直到kernel返回数据，或者错误。 blocking

在介绍网络IO模型，我们先来看一下同步和异步，以及阻塞和非阻塞的概念。 同步和异步关注的是结果消息的通信机制 同步：同步的意思就是调用方需要主动等待结果的返回 异步：异步的意思就是不需要主动等待结果的返回，而是通过其他手段比如，状态通知，回调函数等。 阻塞和非阻塞主要关注的是等待结果返回调用方的状态 阻塞：是指结果返回之前，当前线程被挂起，不做任何事 非阻塞：是指结果在返回之前，线程可以做一些其他事，不会被挂起。 然后我们就来了解一些基本的网络IO模型 阻塞I/O（blocking I/O） 非阻塞I/O （nonblocking I/O） I/O复用(select 、poll和epoll) （I/O multiplexing） 信号驱动I/O （signal driven I/O (SIGIO)） 异步I/O （asynchronous I/O ） 阻塞I/O模型 应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待，知道数据准备好了，从内核拷贝到用户空间，IO函数返回成功指示。 当调用recvfrom()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recvfrom()函数时，未必用户空间就已经存在数据

HAproxy 技术分享 简介 HAProxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件 Features 1.免费 2.能够做到4层以上代理 3.高性能 4.高稳定性 使用案例 淘宝CDN(HTTP反向代理) 测试: HTTP代理 ab -i -c 500 -n 100000 | --- node 8910 URL = / HAproxy| --- node 8911 URL = / | --- node 8912 URL = / | --- node 8913 /test/ (reqisetbe ^[^\ ]*\ /(test|uri)/ server_uri_route) #按照规则转发 ####### haproxy : (单独由haproxy进行均衡负载) Concurrency Level: 500 Time taken for tests: 32.562 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Total transferred: 36606588 bytes HTML transferred: 0 bytes Requests per second: 3071.02 [#/sec] (mean) Time per