杭州达内嵌入式培训火热招生中。。。|杭州达内c++培训火热招生中
您现在的位置: 杭州达内 >>嵌入式培训>>linux网络编程之socket
linux网络编程之socket
杭州达内 - 嵌入式培训 来源:杭州达内 发布时间:2014-02-07 14:21

我们在前面曾经说过,发送端可以是一K一K地发送数据,而接收端的应用程序可以两K两K地提走数据,当然也有可能一次提走3K或6K数据,或者一次只提走几个字节的数据,也就是说,应用程序所看到的数据是一个整体,或说是一个流(stream),在底层通讯中这些数据可能被拆成很多数据包来发送,但是一个数据包有多少字节对应用程序是不可见的,因此TCP协议是面向流的协议,这也是容易出现粘包问题的原因。而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的。

一、粘包问题可以用下图来表示:


假设主机A发送了两个数据包M1和M2给主机B,由于主机B一次接收的字节数是不确定的,故可能存在上图的4种情况,

1、分两次接收两个数据包,一次一个,没有粘包问题;

2、一次接收了两个数据包,存在粘包问题;

3、个接收了M1和M2的一部分,第二次接收M2的另一部分,存在粘包问题;

4、次接收了M1的一部分,第二次接收M1的另一部分和M2,存在粘包问题;

当然实际的情况可能不止以上4种,可以得知的是在互联网上通信很容易造成粘包问题。


二、粘包问题产生的原因

如下图所示,产生的原因主要有3个,当应用程序write 写入的大小大于套接口发送缓冲区大小时;当进行MSS大小的tcp分段时;当以太网帧的payload大于MTU进行ip分片时;都很容易产生粘包问题。

三、粘包问题的解决方案

本质上是要在应用层维护消息与消息的边界
1、定长包
2、包尾加\r\n(ftp)
3、
包头加上包体长度

4、更复杂的应用层协议

对于条目2,缺点是如果消息本身含有\r\n字符,则也分不清消息的边界,条目4不在本文讨论范围内。

对于条目1,即我们需要发送和接收定长包。因为TCP协议是面向流的,read和write调用的返回值往往小于参数指定的字节数。对于read调用(套接字标志为阻塞),如果接收缓冲区中有20字节,请求读100个字节,就会返回20。对于write调用,如果请求写100个字节,而发送缓冲区中只有20个字节的空闲位置,那么write会阻塞,直到把100个字节全部交给发送缓冲区才返回,但如果socket文件描述符有O_NONBLOCK标志,则write不阻塞,直接返回20。为避免这些情况干扰主程序的逻辑,确保读写我们所请求的字节数,我们实现了两个包装函数readn和writen,如下所示。

 

 C++ Code 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 

ssize_t readn(int fd, void *buf, size_t count)
{
    size_t nleft = count;
    ssize_t nread;
    char *bufp = (char *)buf;

    while (nleft > 0)
    {



        ssize_t readn(int fd, void * buf, size_t count)
        {
            size_t nleft = count;
            ssize_t nread;
            char *bufp = (char *)buf;

            while (nleft > 0)
            {

                if ((nread = read(fd, bufp, nleft)) < 0)
                {

                    if (errno == EINTR)
                        continue;
                    return -1;
                }

                else if (nread == 0//对方关闭或者已经读到eof
                    return count - nleft;

                bufp += nread;
                nleft -= nread;
            }

            return count;
        }

        ssize_t writen(int fd, const void * buf, size_t count)
        {
            size_t nleft = count;
            ssize_t nwritten;
            char *bufp = (char *)buf;

            while (nleft > 0)
            {

                if ((nwritten = write(fd, bufp, nleft)) < 0)
                {

                    if (errno == EINTR)
                        continue;
                    return -1;
                }

                else if (nwritten == 0)
                    continue;

                bufp += nwritten;
                nleft -= nwritten;
            }

            return count;

        }


 需要注意的是一旦在我们的客户端/服务器程序中使用了这两个函数,则每次读取和写入的大小应该是一致的,比如设置为1024个字节,但定长包的问题在于不能根据实际情况读取数据,可能会造成网络阻塞,比如现在我们只是敲入了几个字符,却还是得发送1024个字节,造成极大的空间浪费。

此时条目3是比较好的解决办法,其实也可以算是自定义的一种简单应用层协议。比如我们可以自定义一个包体结构

struct packet {
    int len;
    char buf[1024];
};

先接收固定的4个字节,从中得知实际数据的长度n,再调用readn 读取n个字符,这样数据包之间有了界定,且不用发送定长包浪费网络资源,是比较好的解决方案。服务器端在前面的fork程序的基础上把do_service函数更改如下:

 

 C++ Code 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
void do_service(int conn)
{
    struct packet recvbuf;
    int n;
    while (1)
    {
        memset(&recvbuf, 0sizeof(recvbuf));
        int ret = readn(conn, &recvbuf.len, 4);
        if (ret == -1)
            ERR_EXIT("read error");
        else if (ret < 4)   //客户端关闭
        {
            printf("client close\n");
            break;
        }

        n = ntohl(recvbuf.len);
        ret = readn(conn, recvbuf.buf, n);
        if (ret == -1)
            ERR_EXIT("read error");
        if (ret < n)   //客户端关闭
        {
            printf("client close\n");
            break;
        }

        fputs(recvbuf.buf, stdout);
        writen(conn, &recvbuf, 4 + n);
    }
}

客户端程序的修改与上类似,不再赘述。


相关标签:达内(343)
 达内简介 达内就业 达内课程 联系我们 网站导航
杭州达内为上软件有限公司 Copyright @ 2007-2012 版权所有 苏ICP备10118953号-1
分享到: