C++博客-to myself 的分类学习日志-随笔分类-network programminghttp://www.cppblog.com/toMyself/category/9701.html做自己想做的事zh-cnSun, 20 Nov 2011 16:35:48 GMTSun, 20 Nov 2011 16:35:48 GMT60protobuf的使用http://www.cppblog.com/toMyself/archive/2010/12/02/135268.htmlkongkongzikongkongziThu, 02 Dec 2010 06:21:00 GMThttp://www.cppblog.com/toMyself/archive/2010/12/02/135268.htmlhttp://www.cppblog.com/toMyself/comments/135268.htmlhttp://www.cppblog.com/toMyself/archive/2010/12/02/135268.html#Feedback2http://www.cppblog.com/toMyself/comments/commentRss/135268.htmlhttp://www.cppblog.com/toMyself/services/trackbacks/135268.html使用protobuf定义消息 下载protobuf-2.3.0：
    http://protobuf.googlecode.com/files/protobuf-2.3.0.zip
安装：
unzip protobuf-2.3.0.zip
cd protobuf-2.3.0
./configure
make
make check
make install

结果：
Libraries have been installed in:
   /usr/local/lib
Head files hava been installed in:
/usr/local/include/google/
protobuf/


开始写.proto文件：
BaseMessage.proto：
message MessageBase
{
    required int32 opcode = 1;
    // other: sendMgrId, sendId, recvMgrId, recvId, ...
}

message BaseMessage
{
    required MessageBase msgbase = 1;
}

BaseMessage.proto是其它消息proto文件的基础，以容器模块的C2S_GetContainerInfo为例：
ContainerMessage.proto：
import "BaseMessage.proto";

message C2SGetContainerInfoMsg
{
    required MessageBase msgbase = 1;
    optional int32 containerType = 2;
}

.proto文件编写规则：
1）所有消息都需要包含msgbase这项，并编号都为1，即：
  required MessageBase msgbase = 1;
2）除了msgbase这项写成required外，其它所有项都写成optional。

编译 .proto 文件
protoc -I=. --cpp_out=. BaseMessage.proto
protoc -I=. --cpp_out=. ContainerMessage.proto
生成BaseMessage.pb.h、BaseMessage.pb.cc
    ContainerMessage.pb.h、ContainerMessage.pb.cc
将它们添加到工程文件中。

编写C++代码：
1）发送消息：
C2SGetContainerInfoMsg msg;
msg.mutable_msgbase()->set_opcode(C2S_GetContainerInfo);
msg.set_containertype(1);
std::string out = msg.SerializeAsString();
send(sockfd, out.c_str(), out.size(), 0);
2）接收消息
char buf[MAXBUF + 1];
int len;
bzero(buf, MAXBUF + 1);
len = recv(new_fd, buf, MAXBUF, 0);
if (len > 0)
{
    printf("%d接收消息成功:'%s'，共%d个字节的数据\n",
            new_fd, buf, len);

    BaseMessage baseMsg;
    std::string data = buf;
    baseMsg.ParseFromString(data);

    int opcode = baseMsg.mutable_msgbase()->opcode();

    printf("opcode=%d\n", opcode);

    switch (opcode)
    {
    case C2S_GetContainerInfo:
    {
        C2SGetContainerInfoMsg msg;
        msg.ParseFromString(data);

        printf("containerType=%d\n", msg.containertype());

        break;
    }
    default:
    {
        break;
    }
    }
}
else
{
    if (len < 0)
        printf("消息接收失败！错误代码是%d，错误信息是'%s'\n",
             errno, strerror(errno));
    close(new_fd);
    return -1;
}


编译C++代码：
Need to link lib:
protobuf
pthread


参考：
1， Google Protocol Buffer 的使用和原理: http://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html?ca=drs-
2，http://code.google.com/p/protobuf/



kongkongzi 2010-12-02 14:21 发表评论
]]>网络数据格式http://www.cppblog.com/toMyself/archive/2010/09/30/128125.htmlkongkongzikongkongziThu, 30 Sep 2010 06:16:00 GMThttp://www.cppblog.com/toMyself/archive/2010/09/30/128125.htmlhttp://www.cppblog.com/toMyself/comments/128125.htmlhttp://www.cppblog.com/toMyself/archive/2010/09/30/128125.html#Feedback0http://www.cppblog.com/toMyself/comments/commentRss/128125.htmlhttp://www.cppblog.com/toMyself/services/trackbacks/128125.html第一种类型,二进制格式的网络数据包,通常要首先接收包头,在包头中有校验数据校验获取的数据是否正确,同时包头中还有数据域存放接下来的内容域的大小,得到该大小之后开始接收内容包,然后对内容包进行解析,包头的大小是固定的,否则无法知道何时接收包头完毕进行解析.

第二种类型,XML格式组织的数据包,通常以连续几个\r\n之类的字符表示结束,在接收包的时候无法知道所要获取数据包的大小,只有每次判断时候已经接收到了表示结束的字符.

两种传送数据包优缺点比较:
1)网络传送效率比较:第一种的优点是接收数据包的效率高,首先按照包头的数据大小接收包头可以获知内容包的大小,再按照此大小获取数据包;而第二种数据包无法在接收的时候获取该数据包的大小,只能在每次接收的时候判断时候已经到达包的结尾,因此相比较而言第一种格式的数据包在网络传送效率上高一些.同时,由于第一种格式可以在包头中加入一些校验字段判断包是否合法,在数据校验这一块也具有优势.

2)解析数据包:第一种数据包没有固定的格式,或者准确的说没有固定的解析器用于解析这种格式的数据,因为每个人定出的协议都不尽相同;而第二种数据包有完备的解析XML格式数据的第三方库可用(libxml2,tinyxml,expat等),但是并不见得有了第三方的库解析起数据起来效率就一定高(这里指的是程序的效率,而不是编码的效率),因为XML解析比普通的数据解析要复杂的多,效率也就更加慢一些.

3)可扩展性:第一种数据包的格式不同,可扩展性也不尽相同,具体与每种格式的包有区别.第二种格式的数据包由于采用了XML格式,天正的具备很好的可扩展性.

4)数据安全性:第一种格式的数据包可以方便的实现数据的加密,而XML格式的数据实现加密不容易,基本上抓包就能看到数据.

综上，个人认为XML格式的数据包仅在可扩展性上有较大的优势，但是对于安全性，性能要求不太高而扩展性要求较大的协议还是建议使用XML格式的协议，毕竟如果协议制定的不好造成扩展性差也是麻烦的事情，因为客户端一旦放出去就收不回来的。目前jabber的通讯协议就是采用的XML格式的协议。

来自：http://www.cppblog.com/converse/archive/2008/03/26/45472.html




 

 

一、      json介绍

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。

JSON建构于两种结构：

  • “名称/值”对的集合（A collection of name/value pairs）。不同的语言中，它被理解为对象（object），纪录（record），结构（struct），字典（dictionary），哈希表（hash table），有键列表（keyed list），或者关联数组 （associative array）。
  • 值的有序列表（An ordered list of values）。在大部分语言中，它被理解为数组（array）。

这些都是常见的数据结构。事实上大部分现代计算机语言都以某种形式支持它们。这使得一种数据格式在同样基于这些结构的编程语言之间交换成为可能。

JSON具有以下这些形式：

对象是一个无序的“‘名称/值’对”集合。一个对象以“{”（左括号）开始，“}”（右括号）结束。每个“名称”后跟一个“:”（冒号）；“‘名称/值’ 对”之间使用“,”（逗号）分隔。

 

数组是值（value）的有序集合。一个数组以“[”（左中括号）开始，“]”（右中括号）结束。值之间使用“,”（逗号）分隔。

 

值（value）可以是双引号括起来的字符串（string）、数值(number)、true、false、 null、对象（object）或者数组（array）。这些结构可以嵌套。

 

字符串（string）是由双引号包围的任意数量Unicode字符的集合，使用反斜线转义。一个字符（character）即一个单独的字符串（character string）。

字符串（string）与C或者Java的字符串非常相似。

 

数值（number）也与C或者Java的数值非常相似。除去未曾使用的八进制与十六进制格式。除去一些编码细节。

 

空白可以加入到任何符号之间。

参考：

1、   http://www.json.org/

2、   http://www.json.org/json-zh.html

二、      jsoncpp介绍

本文选择一个第三方库 jsoncpp 来解析 JSON。jsoncpp 是比较出名的 C++ JSON 解析库。下载地址为：http://sourceforge.net/projects/jsoncpp。本文使用的 jsoncpp 版本为：0.5.0。License: Public Domain。

Jsoncpp是Json数据格式的编码解码器，使用c++编写，提供reader和writer来进行解码和编码。

jsconcpp 进行 JSON 解析的源码文件分布在 include/json、src/lib_json 下。

jsoncpp 主要包含三种类型的 class：Value、Reader、Writer。jsoncpp 中所有对象、类名都在 namespace Json 中，包含 json.h 即可。

    Json::Value 只能处理 ANSI 类型的字符串，如果 C++ 程序是用 Unicode 编码的，最好加一个 Adapt 类来适配。

1、Reader
该库中的Reader类用来将字串或者流载入解析器。是的后期可以用Reader里面的解析方法来解码Json字串为C++认识的数据。可以用Json::Reader来声明一个Reader实例。Reader中最常用的就是一个parse方法，该方法用来将载入的json字串解析为C++格式的数据。
    2、Value
这是该库中的核心类，用于存储各样格式的数据，可以包括int,double,short,char*,string,bool,object,array等几乎所有格式的数据。该库的编码和解码的核心功能都是用Value类实现的。就用以上的Reader的parse方法来说，需要传入一个Value类别的引用值，就是用来存储Json数据的根值，并且可以用这个根值来存取其他的所有值。
    3、Writer
这是该库的一个虚类，没有真正的实现encode的功能。需要重载里头的方法来实现真正的encode功能。

4.FastWriter
这是该库中真正实现encode功能的类，用来实现将Value编码称为Json串。

参考：

1、 http://sourceforge.net/projects/jsoncpp/

2、 http://jsoncpp.sourceforge.net/index.html

3、 http://blog.csdn.net/xt_xiaotian/archive/2010/06/04/5648388.aspx

4、 http://adebugger.cn/2009/11/cpp-json-data-communication/

三、      protobuf介绍

ProtoBuf，全称是Protocol Buffers, 它是谷歌内部用的一种高效的、可扩展的对结构化数据进行编码的格式规范。谷歌自己内部很多程序之间的通信协议都用了ProtoBuf。

ProtoBuf可以支持多种编程语言，目前已经C++, Java和Python，本文中所前的内容用到例子的话，会以C++为例。

ProtoBuf在Google Code上的主页是：http://code.google.com/p/protobuf/， 感兴趣的可以在这里下载ProtoBuf的源码，也可以在这里阅读ProtoBuf的详细的文档。

1、        序列化和反序列化

在开始本部分的内容之前，首先有必要介绍两个基本概念，一个是序列化，一个是反序列化。这两个概念的定义在网上搜一下都很多的，但大多都讲得比较晦涩，不太好理解，在这里我会用比较通俗的文字来解释，尽可能让读都朋友们一读就明白是怎么回事：

序列化：是指将结构化的数据按一定的编码规范转成指定格式的过程。

反序列化：是指将转成指定格式的数据解析成原始的结构化数据的过程。

举个例子，Person是一个表示人的对象类型，person是一个Person类型的对象，将person存到一个对应的XML文档中的过程就是一种序列化，而解析XML生成对应Person类型对象person的过程，就是一个反序列化的过程。在这里结构化数据指的就是Person类型的数据，一定的编码规范指的就是XML文档的规范。XML是一种简单的序列化方式，用XML序列化的好处是，XML的通用性比较好，另外，XML是一种文本格式，对人阅读比较友好，但是XML方式比较占空间，效率也不是很高。通常，比较高效的序列化都是采用二进制方式的，将要序列化的结构化数据，按一定的编码规范，转成为一串二进制的字节流存储下来，需要用的时候再从这串二进制的字节流中反序列化出对应的结构化的数据。

通过上面的介绍，我们给protobuf下一个比较正式的定义了：Google ProtoBuf是Google制定的一种用来序列化结构化数据的程序库。

2、        ProtoBuf中的编码

1) ProtoBuf编码基础——Varints, varints是一种将一个整数序列化为一个或者多个Bytes的方法，越小的整数，使用的Bytes越少。

Varints的基本规则是：

（a） 每个Byte的最高位(msb)是标志位，如果该位为1，表示该Byte后面还有其它Byte，如果该位为0，表示该Byte是最后一个Byte。

（b）每个Byte的低7位是用来存数值的位

（c）Varints方法用Litte-Endian(小端）字节序

举个例子：300用Varints序列化的结果是1010 1100 0000 0010，运算过程如下 所示：

1010 1100 0000 0010->010 1100 000 0010（去标志位）->

000 0010 010 1100（调整字节序）-> 1 0010 1100 ->256+32+8+4=300（计算值）

300用Varints序列化的过程：-> (二进制)0000 0001 0010 1100 -> (7位一组)000 0010 010 1100 -> (调整字节序)010 1100 000 0010 -> (增加标志位)1010 1100 0000 0010。

2)ProtoBuf中消息的编码规则：

（a）每条消息(message)都是有一系列的key-value对组成的, key和value分别采用不同的编码方式。

（b）对某一条件消息(message)进行编码的时候，是把该消息中所有的key-value对序列化成二进制字节流；而解码的时候，解码程序读入二进制的字节流，解析出每一个key-value对，如果解码过程中遇到识别不出来的类型，直接跳过。这样的机制，保证了即使该消息添加了新的字段，也不会影响旧的编/解码程序正常工作。

（c）key由两部分组成，一部分是在定义消息时对字段的编号（field_num），另一部分是字段类型（wire_type）。字段类型定义如下表所示。

Type

Meaning

Used For

0

Varint

int32, int64, uint32, uint64, sint32, sint64, bool, enum

1

64-bit

fixed64, sfixed64, double

2

Length-delimited

string, bytes, embedded messages, packed repeated fields

3

Start group

groups (deprecated)

4

End group

groups (deprecated)

5

32-bit

fixed32, sfixed32, float

（d）key的编码方式：field_num << 3 | wire_type

（e）varint类型(wire_type=0)的编码，与第(1)部分中介绍的方法基本一致，但是int32, int64和sint32,sint64有些特别之处：int32和int64就是简单的按varints方法来编码，所以像-1、-2这样负数也会占比较多的Bytes。于是sint32和sint64采用了一种改进的方法：先采用Zigzag方法将所有的整数（正数、0和负数）一一映射到所有的无符号数上，然后再采用varints编码方法进行编码。Zigzag映射函数为：

Zigzag(n) = (n << 1) ^ (n >> 31),  n为sint32时

Zigzag(n) = (n << 1) ^ (n >> 63),  n为sint64时

下表是一个比较直观的映射表，这样映射后再进行编码的好处就是绝对值比较小的负数序列化后的结果占的Bytes数也会比较少。

Signed Original

Encoded As

0

0

-1

1

1

2

-2

3

2

4

-3

5

…

…

2147483647

4294967294

-2147483648

4294967295

（f）64-bit(wire_type=1)和32-bit(wire_type=5)的编码方式就比较简单了，直接在key后面跟上64bits或32bits，采用Little-Endian(小端)字节序。

（g）length-delimited(wire_type=2)的编码方式：key+length+content, key的编码方式是统一的，length采用varints编码方式，content就是由length指定的长度的Bytes。

（h）wire_type=3和4的现在已经不推荐使用了，因此这里也不再做介绍。

3）ProtoBuf编解码中字段顺序(Field order)的问题：

(a) 编码/解码与字段顺序无关，这一点由key-value机制就能保证

(b)对于未知的字段，编码的时候会把它写在序列化完的已知字段后面。

3、         工作流程

首先需要在一个 .proto 文件中定义你需要做串行化的数据结构信息。每个ProtocolBuffer信息是一小段逻辑记录，包含一系列的键值对。这里有个非常简单的 .proto 文件定义了个人信息:
message Person {
    required string name=1;
    required int32 id=2;
    optional string email=3;

    enum PhoneType {
        MOBILE=0;
        HOME=1;
        WORK=2;
    }

    message PhoneNumber {
        required string number=1;
        optional PhoneType type=2 [default=HOME];
    }

    repeated PhoneNumber phone=4;
}

有如你所见，消息格式很简单，每个消息类型拥有一个或多个特定的数字字段，每个字段拥有一个名字和一个值类型。值类型可以是数字(整数或浮点)、布尔型、字符串、原始字节或者其他ProtocolBuffer类型，还允许数据结构的分级。你可以指定可选字段，必选字段和重复字段。你可以在( http://code.google.com/apis/protocolbuffers/docs/proto.html )找到更多关于如何编写 .proto 文件的信息。
一旦你定义了自己的报文格式(message)，你就可以运行ProtocolBuffer编译器，将你的 .proto 文件编译成特定语言的类。这些类提供了简单的方法访问每个字段(像是 query() 和 set_query() )，像是访问类的方法一样将结构串行化或反串行化。例如你可以选择C++语言，运行编译如上的协议文件生成类叫做 Person 。随后你就可以在应用中使用这个类来串行化的读取报文信息。你可以这么写代码:
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream.output("myfile",ios:out | ios::binary);
person.SerializeToOstream(&output);

然后，你可以读取报文中的数据:
fstream input("myfile",ios::in | ios:binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

你可以在不影响向后兼容的情况下随意给数据结构增加字段，旧有的数据会忽略新的字段。所以如果使用ProtocolBuffer作为通信协议，你可以无须担心破坏现有代码的情况下扩展协议。
你可以在API参考( http://code.google.com/apis/prot ... rence/overview.html )中找到完整的参考，而关于ProtocolBuffer的报文格式编码则可以在( http://code.google.com/apis/protocolbuffers/docs/encoding.html )中找到。

参考：

1、http://code.google.com/p/protobuf/

2、http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/tutorials.html

3、http://www.wuzesheng.com/?p=1258

 

四、      json和protobuf的性能对比

1、        占用空间比较

json一种文本格式，带有字符串标签，对人阅读比较友好，但是json方式比较占空间。

protobuf的每条消息(message)都是有一系列的key-value对组成的，key和value分别采用不同的编码方式，编码后占用的空间比较小。

2、        性能测试

测试程序是定义Person消息，先序列化到一个string里，然后又从string里反序列化出来，如此重复100000，计算总共花费的时间。

测试结果：使用protobuf大概需要10秒，使用json大概需要58秒。

从结果可以看出，protobuf的序列化、反序列化是比json更快的。




 



kongkongzi 2010-09-30 14:16 发表评论
]]>epollhttp://www.cppblog.com/toMyself/archive/2010/09/16/126767.htmlkongkongzikongkongziThu, 16 Sep 2010 07:20:00 GMThttp://www.cppblog.com/toMyself/archive/2010/09/16/126767.html服务器代码：
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <sys/epoll.h>
#include <sys/time.h>
#include <sys/resource.h>
#define MAXBUF 1024
#define MAXEPOLLSIZE 10000

/*
 *     setnonblocking - 设置句柄为非阻塞方式
 */
int setnonblocking(int sockfd)
{
    if (fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFD, 0)|O_NONBLOCK) == -1)
    {
        return -1;
    }
    return 0;
}

/*
 *     handle_message - 处理每个 socket 上的消息收发
 */
int handle_message(int new_fd)
{
    char buf[MAXBUF + 1];
    int len;
    /*  开始处理每个新连接上的数据收发 */
    bzero(buf, MAXBUF + 1);
    /*  接收客户端的消息 */
    len = recv(new_fd, buf, MAXBUF, 0);
    if (len > 0)
    {
        printf("%d接收消息成功:'%s'，共%d个字节的数据\n",
                new_fd, buf, len);
    }
    else
    {
        if (len < 0)
            printf("消息接收失败！错误代码是%d，错误信息是'%s'\n",
                 errno, strerror(errno));
        close(new_fd);
        return -1;
    }
    /*  处理每个新连接上的数据收发结束 */
    return len;
}

int main(int argc, char **argv)
{
    int listener, new_fd, kdpfd, nfds, n, ret, curfds;
    socklen_t len;
    struct sockaddr_in my_addr, their_addr;
    unsigned int myport, lisnum;
    struct epoll_event ev;
    struct epoll_event events[MAXEPOLLSIZE];
    struct rlimit rt;
    myport = 5000;
    lisnum = 2; 
    
    /*  设置每个进程允许打开的最大文件数 */
    rt.rlim_max = rt.rlim_cur = MAXEPOLLSIZE;
    if (setrlimit(RLIMIT_NOFILE, &rt) == -1) 
    {
        perror("setrlimit");
        exit(1);
    }
    else 
    {
        printf("设置系统资源参数成功！\n");
    }
    
    /*  开启 socket 监听 */
    if ((listener = socket(PF_INET, SOCK_STREAM, 0)) == -1)
    {
        perror("socket");
        exit(1);
    }
    else
    {
        printf("socket 创建成功！\n");
    }

    setnonblocking(listener);
    bzero(&my_addr, sizeof(my_addr));
    my_addr.sin_family = PF_INET;
    my_addr.sin_port = htons(myport);
    my_addr.sin_addr.s_addr = INADDR_ANY;
    if (bind(listener, (struct sockaddr *) &my_addr, sizeof(struct sockaddr)) == -1) 
    {
        perror("bind");
        exit(1);
    } 
    else
    {
        printf("IP 地址和端口绑定成功\n");
    }
    if (listen(listener, lisnum) == -1) 
    {
        perror("listen");
        exit(1);
    }
    else
    {
        printf("开启服务成功！\n");
    }
    /*  创建 epoll 句柄，把监听 socket 加入到 epoll 集合里 */
    kdpfd = epoll_create(MAXEPOLLSIZE);
    len = sizeof(struct sockaddr_in);
    ev.events = EPOLLIN | EPOLLET;
    ev.data.fd = listener;
    if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, listener, &ev) < 0) 
    {
        fprintf(stderr, "epoll set insertion error: fd=%d\n", listener);
        return -1;
    }
    else
    {
        printf("监听 socket 加入 epoll 成功！\n");
    }
    curfds = 1;
    while (1) 
    {
        /*  等待有事件发生 */
        nfds = epoll_wait(kdpfd, events, curfds, -1);
        if (nfds == -1)
        {
            perror("epoll_wait");
            break;
        }
        /*  处理所有事件 */
        for (n = 0; n < nfds; ++n)
        {
            if (events[n].data.fd == listener) 
            {
                new_fd = accept(listener, (struct sockaddr *) &their_addr,&len);
                if (new_fd < 0) 
                {
                    perror("accept");
                    continue;
                } 
                else
                {
                    printf("有连接来自于： %d:%d， 分配的 socket 为:%d\n",
                            inet_ntoa(their_addr.sin_addr), ntohs(their_addr.sin_port), new_fd);
                }
                setnonblocking(new_fd);
                ev.events = EPOLLIN | EPOLLET;
                ev.data.fd = new_fd;
                if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, new_fd, &ev) < 0)
                {
                    fprintf(stderr, "把 socket '%d' 加入 epoll 失败！%s\n",
                            new_fd, strerror(errno));
                    return -1;
                }
                curfds++;
            } 
            else
            {
                ret = handle_message(events[n].data.fd);
                if (ret < 1 && errno != 11)
                {
                    epoll_ctl(kdpfd, EPOLL_CTL_DEL, events[n].data.fd,&ev);
                    curfds--;
                }
            }
        }
    }
    close(listener);
    return 0;
}
客户端代码：
#include <stdio.h> 
#include <stdlib.h> 
#include <errno.h> 
#include <string.h> 
#include <unistd.h>
#include <netdb.h> 
#include <sys/types.h> 
#include <netinet/in.h> 
#include <sys/socket.h> 
#define PORT 5000 /*  Server的端口 */ 
#define MAXDATASIZE 100 /* 一次可以读的最大字节数 */ 

int main(int argc, char *argv[]) 
{ 
    int sockfd, numbytes; 
    struct hostent *he; /*  主机信息 */ 
    struct sockaddr_in their_addr; /*  对方地址信息 */ 

    if (argc != 2) 
    { 
        fprintf(stderr,"usage: client hostname\n"); 
        exit(1); 
    } 

    /*  get the host info */ 
    if ((he = gethostbyname(argv[1])) == NULL) 
    { 
        /*  注意：获取DNS信息时，显示出错需要用herror而不是perror */ 
        herror("gethostbyname"); 
        exit(1); 
    } 

    if ((sockfd = socket(AF_INET,SOCK_STREAM,0)) == -1) 
    { 
        perror("socket"); 
        exit(1); 
    } 
         
    their_addr.sin_family = AF_INET; 
    their_addr.sin_port = htons(PORT); /*  short, NBO */ 
    their_addr.sin_addr = *((struct in_addr *)he->h_addr); 
    bzero(&(their_addr.sin_zero), 8); /*  其余部分设成0 */ 
    if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof(struct sockaddr)) == -1) 
    { 
        perror("connect"); 
        exit(1); 
    } 

    char* pMsg= "Hello,world!";
    if ((numbytes = send(sockfd, pMsg, strlen(pMsg), 0)) == -1) 
    { 
        perror("send"); 
        exit(1); 
    } 

    close(sockfd); 
    return 0; 
}     


kongkongzi 2010-09-16 15:20 发表评论
]]>网络爬虫--larbinhttp://www.cppblog.com/toMyself/archive/2010/08/28/125073.htmlkongkongzikongkongziSat, 28 Aug 2010 12:38:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/28/125073.htmllarbin分析、源码分析、结构分析

 

单线程非阻塞。这是目前使用的比较多的一种做法，无论在client还是server都有着广泛的应用。在一个线程内打开多个非阻塞的连接，通过poll/epoll/select对连接状态进行判断，在第一时间响应请求，不但充分利用了网络资源，同时也将本机CPU资源的消耗降至最低。这种方法需要对dns请求，连接，读写操作都采用异步非阻塞操作，其中第一种比较复杂，可以采用adns作为解决方案，后面三个操作相对简单可以直接在程序内实现。

效率问题解决后就需要考虑具体的设计问题了。

url肯定需要一个单独的类进行处理，包括显示，分析url，得到主机，端口，文件数据。

然后需要对url进行排重，需要一个比较大的url Hash表。

如果还要对网页内容进行排重，则还需要一个Document Hash表。

爬过的url需要记录下来，由于量比较大，我们将它写到磁盘上，所以还需要一个FIFO的类(记作urlsDisk)。

现在需要爬的url同样需要一个FIFO类来处理，重新开始时，url会从定时从爬过的url FIFO里取出来，写到这个FIFO里。正在运行的爬虫需要从这个FIFO里读数据出来，加入到主机类的url列表里。当然，也会从前一个FIFO里直接读url出来，不过优先级应该比这个里面出来的url低，毕竟是已经爬过的。

爬虫一般是对多个网站进行爬取，但在同时站点内dns的请求可以只做一次，这就需要将主机名独立于url，单独有一个类进行处理。

主机名解析完成后需要有一个解析完成的IP类与之应用，用于connect的时候使用。

HTML文档的解析类也要有一个，用来分析网页，取出里面的url，加入到urlsDisk。

再加上一些字符串，调度类，一个简单的爬虫基本上就完成了。

以上基本上是Larbin的设计思路，Larbin在具体实现上还有一些特殊的处理，例如带了一个webserver，以及对特殊文件的处理。 Larbin有一点设计不不太好，就是慢的访问会越来越多，占用大量的连接，需要改进，另外如果对于大规模的爬虫，这仅仅实现了抓取的部分，要分布式的扩展还需要增加url的集中管理与调度以及前台spider的分布式算法。

说的简单易懂一些，网络爬虫跟你使用的〖离线阅读〗工具差不多。说离线，其实还是要跟网络联结，否则怎么抓东西下来？

那么不同的地方在哪里？

1】 网络爬虫高度可配置性。
2】 网络爬虫可以解析抓到的网页里的链接
3】 网络爬虫有简单的存储配置
4】 网络爬虫拥有智能的根据网页更新分析功能
5】 网络爬虫的效率相当的高

那么依据特征，其实也就是要求了，如何设计爬虫呢？要注意哪些步骤呢？

1】 url 的遍历和纪录
这点 larbin 做得非常的好，其实对于url的遍历是很简单的，例如：
cat [what you got]| tr " \n | gawk &apos;{print $2}&apos; | pcregrep ^ http://
就可以得到一个所由的 url 列表

2】多进程 VS 多线程
各有优点了，现在一台普通的PC 例如 booso.com 一天可以轻松爬下5个G的数据。大约20万网页。

3】时间更新控制
最傻的做法是没有时间更新权重，一通的爬，回头再一通的爬。
通常在下一次爬的的数据要跟上一次进行比较，如果连续5次都没有变化，那么将爬这个网页的时间间隔扩大1倍。

如果一个网页在连续5次爬取的时候都有更新，那么将设置的爬取时间缩短为原来的1／2。

注意，效率是取胜的关键之一。

4】爬的深度是多少呢？
看情况了。如果你比较牛，有几万台服务器做网络爬虫，我劝您跳过这一点。
如果你同我一样只有一台服务器做网络爬虫，那么这样一个统计您应该知道：

网页深度：网页个数：网页重要程度
0 : 1 : : 10
1 :20 : :8
2: :600: :5
3: :2000: :2
4 above: 6000: 一般无法计算

好了，爬到三级就差不多了，再深入一是数据量扩大了3／4倍，二是重要度确下降了许多，这叫做“种下的是龙种，收获的是跳蚤。”

5】爬虫一般不直接爬对方的网页，一般是通过一个Proxy出去，这个proxy有缓解压力的功能，因为当对方的网页没有更新的时候，只要拿到 header 的 tag就可以了，没有必要全部传输一次了，可以大大节约网络带宽。

apache webserver里面纪录的 304 一般就是被cache的了。

6】请有空的时候照看一下robots.txt

7】存储结构。
这个人人见智，google 用 gfs 系统，如果你有7／8台服务器，我劝你用NFS系统，要是你有70／80个服务器的话我建议你用afs 系统，要是你只有一台服务器，那么随便。

给一个代码片断，是我写的新闻搜索引擎是如何进行数据存储的：

NAME=`echo $URL |perl -p -e &apos;s/([^w-.@])/$1 eq " " ? " ":sprintf("%%%2.2x",ord($1))/eg&apos;`
mkdir -p $AUTHOR
newscrawl.pl $URL --user-agent="news.booso.com+(+ http://booso.com)" -outfile=$AUTHOR/$NAME


larbin官方地址：http://larbin.sourceforge.net/index-eng.html


larbin，a input system。
定制larbin： http://larbin.sourceforge.net/custom-eng.html
1、对爬来的网页定制自己的输出。
目前系统已经定义了4中输出，参见src/interf/useroutput.cc。自己的输出可以参考它们写。
2、修改larbin.conf，options.h进行简单定制。



 

 

 Labin、OpenSpider、天网 三款爬虫对比分析

    Labin、OpenSpider、天网 是三款比较著名的网络爬虫，其中天网现在已经做成了分布式爬虫，据称天网在ftp搜索方面水平比较高。这三款爬虫本人都接触过，对于Labin和天网的源代码也研究过一段时间。

    Larbin:

    首先，Labin采用的socket方式是 单线程非阻塞式的爬取。具体的技术实现采用 linux/unix的poll轮询接口。当Larbin读取种子网站以后，会解析出网页中的url.从源代码中来看，Larbin提取url的技术水平并不高，只是采取简单的字符串操作。然而url是各种各样的，字符串操作能否提取90%以上html网页中的url，还值得怀疑。

    当被urls被提取以后，Labin建立了四个队列存取之：两个优先权队列、两个普通队列。为什么要这么做呢？我想做着可能这样想：优先权队列用作采集优先权高的url，而这个优先权怎么计算？这个要根据系统的实际情况了！如果是垂直搜索引擎，可能会根据倾向性、内容相关性来打分，分数高则优先级高。甚至会用分类、聚类或者各种评判手段，甚至pagerank/hits 算法来预先计算url的权重。如果是普通搜索引擎，那么可以这样计算打分：要不根据爬取的网页深度，要不根据是否location字段等等。Larbin中优先权是根据什么来计算的，我想读了上面的东西已经不重要了。

    既然提取了urls,就要对url进行域名解析。Larbin自建立了一个DNS服务器。关于DNS服务器的运作，鲜有说明。我自己是这样认为的：首先，本地（Larbin)的dns与外网的DNS进行交互，将外网的DNS的相关内容读取进来。然后，就可以响应larbin的解析请求了。所以当开启DNS服务器的时候，应该会有一个大量读取外网DNS内容的过程。

    Larbin似乎是将解析完毕的DNS存入一个管道之中，一头进，一头出。出的一头就是继续重复爬取了。另外Larbin的url消重算法是采用的是普通的bloom filter算法。不在累赘了。

   总结：从上面看来，Larbin只是一个小型架构的爬虫，并不适合大型分布式爬取。其架构针对小型爬虫来说，轻装上阵，非常合理。但是对于大型爬虫则是非常的不合理了。

   OpenSpider:

   OpenSpider我并没细看，大体上也就是那么个流程。不过值得一提的是，OpenSpider提取urls采用的是正则表达式的方法。这个是值得大书特书的。

   关于正则表达式的具体设计，需要丰富的工程项目经验。其设计非常复杂。

   天网：

   天网的初期版本在这三个爬虫之中是最差劲的。几乎毫无架构可言。不过凡事都是从低级做起，还是要大书一番。勇气可嘉么。 

   看得出来，天网模仿了很多开源系统。譬如一个http的简单读取器，还有Larbin似乎也看到了模仿的影子。低等科技国家只能够从模仿开始。一味鼓吹创新只能是自欺欺人。

    天网开了几个线程，并行进行爬取。爬取流程大约如下：

                 

 足见，天网将爬来的并解析的url直接放在了map,vector等容器中，消重也是简单的MD5匹配。同时也设置了一个已爬取的容器。socket采用的是非阻塞的select。但是我怀疑他们的select没有起作用。用法等于没有用。

   以上是我对三款爬虫的简要分析。因为没有必要进行非常细致的抠，所以很多地方都是一笔带过。谬误之处肯定很多的，希望大家多指教。

 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/liwenjia1981/archive/2009/11/21/4846668.aspx



kongkongzi 2010-08-28 20:38 发表评论
]]>学习《TCP/IP详解》http://www.cppblog.com/toMyself/archive/2010/08/19/123932.htmlkongkongzikongkongziThu, 19 Aug 2010 02:27:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/19/123932.html  TCP/IP详解

（在第21章我们将看到TCP的超时和重发算法的细节）

本书第17～22章将详细讨论TCP的内部操作细节。然后，我们将介绍一些TCP的应用，如第26章中的Telnet和Rlogin、第27章中的FTP以及第28章中的SMTP等。这些应用通常都是用户进程。

本书第11章将讨论UDP，然后在第14章（DNS:域名系统），第15章（TFTP：简单文件传送协议），以及第16章（BOOTP：引导程序协议）介绍使用UDP的应用程序。SNMP也使用了UDP协议，但是由于它还要处理许多其他的协议，因此本书把它留到第25章再进行讨论。

2010-6-8 概述、链路层、IP、ARP、RARP

分层：
         

1)       链路层，有时也称作数据链路层或网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。

2)       网络层，有时也称作互联网层，处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。

3)       运输层主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两个互不相同的传输协议： TCP（传输控制协议）和UDP（用户数据报协议）。

TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。

而另一方面， UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。

4)       应用层负责处理特定的应用程序细节。Telnet、FTP、SMTP、SNMP。

 

以太网驱动程序、令牌环驱动程序

网桥是在链路层上对网络进行互连，而路由器则是在网络层上对网络进行互连。网桥使得多个局域网（LAN）组合在一起，这样对上层来说就好像是一个局域网。

有三类I P地址：单播地址（目的为单个主机）、广播地址（目的端为给定网络上的所有主机）以及多播地址（目的端为同一组内的所有主机）。

典型以太网帧首部的字节长度：（UDP的首部长为8字节）


由于TCP、UDP、ICMP和IGMP都要向IP传送数据，因此IP必须在生成的IP首部中加入某种标识，以表明数据属于哪一层。

网络接口分别要发送和接收IP、ARP和RARP数据，因此也必须在以太网的帧首部中加入某种形式的标识，以指明生成数据的网络层协议。为此，以太网的帧首部也有一个16 bit的帧类型域。

 

链路层：

     TCP/IP支持多种不同的链路层协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI（光纤分布式数据接口）及RS-232串行线路等。

以太网链路层协议，两个串行接口链路层协议（SLIP和PPP），以及大多数实现都包含的环回（loopback）驱动程序。

以太网：

     它是当今TCP/IP采用的主要的局域网技术。它采用一种称作CSMA/CD的媒体接入方法，其意思是带冲突检测的载波侦听多路接入（Carrier Sense, Multiple Access with Collision Detection）。它的速率为10 Mb/s，地址为48 bit。

以太网首部：

    

     这里的目的地址和源地址都是Mac地址。

     类型：对于IP数据，该值为0800；对于ARP数据，该值为0806；对于RARP数据，该值为8035

以太网尾部：

     为CRC字段，用于帧内后续字节差错的循环冗余码检验（检验和）（它也被称为FCS或帧检验序列）。

SLIP:

     全称是Serial Line IP。它是一种在串行线路上对IP数据报进行封装的简单形式, SLIP适用于家庭中每台计算机几乎都有的RS-232串行端口和高速调制解调器接入Internet。

PPP: 
      

     协议字段: 当它的值为0x0021时，表示信息字段是一个IP数据报；值为0xc021时，表示信息字段是链路控制数据；值为0x8021时，表示信息字段是网络控制数据。

     由于标志字符的值是0x7e，因此当该字符出现在信息字段中时， PPP需要对它进行转义。在异步链路中，特殊字符0x7d用作转义字符。当它出现在PPP数据帧中时，那么紧接着的字符的第6个比特要取其补码。

MTU:

     不同类型的网络会有不同的MTU值。

     路径MTU的发现机制，即在任何时候确定路径MTU的方法。

IP:

          

//定义IP首部
typedef struct _iphdr{
    unsigned char h_lenver; //4 位IP版本号+4位首部长度
    unsigned char tos; //8 位服务类型TOS
    unsigned short total_len; //16 位IP包总长度（字节）
    unsigned short ident; //1 6位标识, 用于辅助IP包的拆装,本实验不用,置零
    unsigned short frag_and_flags; //3 位标志位+13位偏移位, 也是用于IP包的拆装,本实验不用,置零
    unsigned char ttl; //8 位IP包生存时间 TTL
    unsigned char proto; //8 位协议 (TCP, UDP 或其他), 本实验置ICMP,置为1
    unsigned short checksum; //16 位IP首部校验和,最初置零,等所有包头都填写正确后,计算并替换.
    unsigned int sourceIP; //32 位源IP地址
    unsigned int destIP; //32 位目的IP地址
}IP_HEADER;

     总长度字段是指整个IP数据报的长度，以字节为单位。利用首部长度字段和总长度字段，就可以知道IP数据报中数据内容的起始位置和长度。

     为了计算一份数据报的IP检验和，首先把检验和字段置为0。然后，对首部中每个16 bit进行二进制反码求和（整个首部看成是由一串16 bit的字组成），结果存在检验和字段中。当收到一份IP数据报后，同样对首部中每个16 bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和，因此，如果首部在传输过程中没有发生任何差错，那么接收方计算的结果应该为全1。如果结果不是全1（即检验和错误），那么IP就丢弃收到的数据报。但是不生成差错报文，由上层去发现丢失的数据报并进行重传。

     以太网地址一般通过ARP获得。

     子网对于子网内部的路由器是不透明的。

ARP:

地址解析为这两种不同的地址形式提供映射：32bit的IP地址和数据链路层使用的任何类型的地址。

ARP发送一份称作ARP请求的以太网数据帧给以太网上的每个主机。ARP请求数据帧中包含目的主机的IP地址，其意思是“如果你是这个IP地址的拥有者，请回答你的硬件地址。” 目的主机的ARP层收到这份广播报文后，识别出这是发送端在寻问它的IP地址，于是发送一个ARP应答。这个ARP应答包含IP地址及对应的硬件地址。

ARP的功能是在32 bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射。

     

     帧类型：对于ARP请求或应答来说，该字段的值为0x0806。

     硬件类型：它的值为1即表示以太网地址。

     协议类型：它的值为0x0800即表示IP地址。

     硬件地址长度：对于以太网上IP地址的ARP请求或应答来说，它的值为6。

     协议地址长度：对于以太网上IP地址的ARP请求或应答来说，它的值为4。

     操作(op)：ARP请求（值为1）、ARP应答（值为2）、RARP请求（值为3）和RARP应答（值为4）。

RARP:

     RARP协议是许多无盘系统在引导时用来获取IP地址的。

     RARP请求或应答的帧类型代码为0x8035。

     RARP服务程序。

     RARP服务器的设计与系统相关而且比较复杂。RARP服务器的功能就由用户进程来提供，

而不是作为内核的TCP/IP实现的一部分。

ARP服务器很简单，通常是TCP/IP在内核中实现的一部分。由于内核知道I P地址和硬件地址，因此当它收到一个询问I P地址的ARP请求时，只需用相应的硬件地址来提供应答就可以了。

ICMP:

     
      

//定义ICMP首部
typedef struct _icmphdr{
    unsigned char i_type; //8 位类型, 本实验用 8: ECHO 0:ECHO REPLY
    unsigned char i_code; //8 位代码, 本实验置零
    unsigned short i_cksum; //16位校验和, 从TYPE开始,直到最后一位用户数据,如果为字节数为奇数则补充一位
    unsigned short i_id ; // 识别号（一般用进程号作为识别号）, 用于匹配ECHO和ECHO REPLY包
    unsigned short i_seq ; // 报文序列号, 用于标记ECHO报文顺序
    unsigned int i_data; //不同类型和代码有不同的内容: type==0时为时间戳timestamp;
}ICMP_HEADER;

     不同类型由报文中的类型字段和代码字段来共同决定。

     ICMP地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码：

     

     ICMP时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自午夜开始计算的毫秒数，协调的统一时间（UTC）：(这种ICMP报文的好处是它提供了毫秒级的分辨率）

      

     发起时间戳（orig）、接收时间戳（recv）以及发送时间戳（xmit），往返时间（rtt）。

ICMP不可达报文：

UDP的规则之一是，如果收到一份UDP数据报而目的端口与某个正在使用的进程不相符，那么UDP返回一个ICMP不可达报文。

ICMP的一个规则是， ICMP差错报文必须包括生成该差错报文的数据报IP首部（包含任何选项），还必须至少包括跟在该IP首部后面的前8个字节。

         

采用一种指数退避方法来设置超时值，分别在0、5、15和35秒时重发报文，这正是所推荐的方法。

netstat -s 是查看每个协议统计数据的常用方法。

Ping程序:

     几年前我们还可以作出这样没有限定的断言，如果不能Ping到某台主机，那么就不能Telne t或FTP到那台主机。随着Internet安全意识的增强，出现了提供访问控制清单的路由器和防火墙，那么像这样没有限定的断言就不再成立了。一台主机的可达性可能不只取决于IP层是否可达，还取决于使用何种协议以及端口号。Ping程序的运行结果可能显示某台主机不可达，但我们可以用Telnet远程登录到该台主机的25号端口（邮件服务器）。

     大多数的TCP/IP实现都在内核中直接支持Ping服务器—这种服务器不是一个用户进程。

     地址掩码和时间戳请求，也都是直接在内核中进行处理的。

     IP记录路由选项。IP时间戳选项。

     提供-r选项，以提供记录路由的功能。它使得ping程序在发送出去的IP数据报中设置IP RR（记录路由）选项（该IP数据报包含ICMP回显请求报文）。这样，每个处理该数据报的路由器都把它的IP地址放入选项字段中。当数据报到达目的端时，IP地址清单应该复制到ICMP回显应答中，这样返回途中所经过的路由器地址也被加入清单中。当ping程序收到回显应答时，它就打印出这份IP地址清单。（RFC 791指定路由器记录出口IP地址。）

Traceroute程序:（Windows下为tracert）

     开始时发送一个TTL字段为1的UDP数据报，然后将TTL字段每次加1，以确定路径中的每个路由器。每个路由器在丢弃UDP数据报时都返回一个ICMP超时报文2，而最终目的主机则产生一个ICMP端口不可达的报文。

     Traceroute程序使用ICMP报文和IP首部中的TTL字段（生存周期）。

     每个处理数据报的路由器都需要把TTL的值减1。

     Traceroute程序发送一份UDP数据报给目的主机，但它选择一个不可能的值作为UDP端口号（大于30000），使目的主机的任何一个应用程序都不可能使用该端口。因为，当该数据报到达时，将使目的主机的UDP模块产生一份“端口不可达”错误的ICMP报文。这样，Traceroute程序所要做的就是区分接收到的ICMP报文是超时还是端口不可达，以判断什么时候结束。

     40字节的数据报包含20字节IP首部、8字节的UDP首部和12字节的用户数据（12字节的用户数据包含每发一个数据报就加1的序列号，送出TTL的副本以及发送数据报的时间）。

     对于每个TTL值，发送3份数据报。每接收到一份ICMP报文，就计算并打印出往返时间。如果在5秒种内仍未收到3份数据报的任意一份的响应，则打印一个星号，并发送下一份数据报。

     每个打印出来的RTT值是从发送主机到路由器的总时间。

     目的主机UDP端口号最开始设置为33435，且每发送一个数据报加1。可以通过命令行选项来改变开始的端口号。

     返回的ICMP报文中的信源IP地址是UDP数据报到达的路由器接口的IP地址。这与IP记录路由选项不同，记录的IP地址指的是发送接口地址。

TCP:
     第17章   TCP：传输控制协议

     对TCP的介绍将由本章开始，并一直包括随后的7章。第18章描述如何建立和终止一个TCP连接，第19和第20章将了解正常的数据传输过程，包括交互使用（远程登录）和批量数据传送（文件传输）。第21章提供TCP超时及重传的技术细节，第22和第23章将介绍两种其他的定时器。最后，第24章概述TCP新的特性以及TCP的性能。

   

//定义TCP首部
typedef struct tcp_hdr 
{
    USHORT th_sport; //16位源端口
    USHORT th_dport; //16位目的端口
    unsigned int th_seq; //32位序列号
    unsigned int th_ack; //32位确认号
    unsigned char th_lenres; //4位首部长度/6位保留字
    unsigned char th_flag; //6位标志位
    USHORT th_win; //16位窗口大小
    USHORT th_sum; //16位校验和
    USHORT th_urp; //16位紧急数据偏移量
}TCP_HEADER; 

每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。有时，一个IP地址和一个端口号也称为一个插口（socket）。插口对（socket  pair）(包含客户IP地址、客户端口号、服务器IP地址和服务器端口号的四元组)可唯一确定互联网络中每个TCP连接的双方。

URG 紧急指针（urgent pointer）有效。

ACK 确认序号有效。

PSH 接收方应该尽快将这个报文段交给应用层。

RST 重建连接。

SYN 同步序号用来发起一个连接。

FIN 发端完成发送任务。

     TCP的流量控制由连接的每一端通过声明的窗口大小来提供。

    TCP检验和的计算和UDP检验和的计算相似，使用如11.3节所述的一个伪首部。(???)

    选项：

MSS (Maximum Segment Size)，最长报文大小，每个连接方通常都在通信的第一个报文段（为建立连接而设置S Y N标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。



IPv4头和TCP头校验和计算算法

IP首部校验和的计算方法：

◆当发送IP包时，需要计算IP报头的校验和：
1、把校验和字段置为0；
2、对IP头部中的每16bit进行二进制求和；
3、如果和的高16bit不为0，则将和的高16bit和低16bit反复相加，直到和的高16bit为0，从而获得一个16bit的值；
4、将该16bit的值取反，存入校验和字段。

◆当接收IP包时，需要对报头进行确认，检查IP头是否有误，算法同上2、3步，然后判断取反的结果是否为0，是则正确，否则有错。

 
算法：

SHORT checksum(USHORT* buffer, int size)
{
    unsigned long cksum = 0;

    //step 2    
    while (size > 1)
    {
        cksum += *buffer++;
        size -= sizeof(USHORT);
    }
    if (size)
    {
        cksum += *(UCHAR*)buffer;
    }
    
    //step 3
    cksum = (cksum >> 16) + (cksum & 0xffff);  //将高16bit与低16bit相加
    cksum += (cksum >> 16);  //将进位到高位的16bit与低16bit 再相加    
    
    //step 4
    return (USHORT)(~cksum);
}

实例：

IP头： 

              45 00    00 31

              89 F5    00 00

              6E 06    00 00（校验字段）

              DE B7   45 5D       ->    222.183.69.93

              C0 A8   00 DC     ->    192.168.0.220

计算：   

    4500 + 0031 +89F5 + 0000 + 6e06+ 0000 + DEB7 + 455D + C0A8 + 00DC =3 22C4

    0003 + 22C4 = 22C7

     ~22C7 = DD38      ->即为应填充的校验和

当接受到IP数据包时，要检查IP头是否正确，则对IP头进行检验，方法同上：

计算：

    4500 + 0031 +89F5 + 0000 + 6E06+ DD38 + DEB7 + 455D + C0A8 + 00DC =3 FFFC

    0003 + FFFC = FFFF

     ~FFFF = 00000     ->正确

 

TCP首部检验和与IP首部校验和的计算方法相同，在程序中使用同一个函数来计算。

需要注意的是，由于TCP首部中不包含源地址与目标地址等信息，为了保证TCP校验的有效性，在进行TCP校验和的计算时，需要增加一个TCP伪首部的校验和，定义如下：

struct 
{
    unsigned long saddr; //源地址
    unsigned long daddr; //目的地址
    char mbz; //置空
    char ptcl; //协议类型
    unsigned short tcpl; //TCP长度
} psd_header;

然后我们将这两个字段复制到同一个缓冲区SendBuf中并计算TCP校验和：

memcpy(SendBuf, &psd_header, sizeof(psd_header)); 

memcpy(SendBuf + sizeof(psd_header), &tcp_header, sizeof(tcp_header));

tcp_header.th_sum = checksum((USHORT *)SendBuf, sizeof(psd_header) + sizeof(tcp_header));



kongkongzi 2010-08-19 10:27 发表评论
]]>函数inet_addr和inet_ntoahttp://www.cppblog.com/toMyself/archive/2010/08/13/123353.htmlkongkongzikongkongziFri, 13 Aug 2010 09:46:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/13/123353.htmlinet_addr 将"数字+句点"的格式的IP地址转换到unsigned long中,返回值已经是按照网络字节顺序的
相反inet_ntoa把类型为struct in_addr的数据转化为"数字+句点"的形式的字符串
typedef u_int32_t in_addr_t;
struct in_addr
{
       in_addr_t s_addr;
};

本机字节顺序与网络字节顺序的转换
#include <arpa/inet.h>
htons  ------"host to network short"
htonl   -------"host to network long"
ntohs  -------"network to host short"
ntohl   -------"network to host long"
*注意:在你的数据放到网络上的时候，确信它是网络字节顺序
网络字节顺序(大端字节)和x86机器字节顺序(小端字节)
eg:0X3132  在x86上显示21  在网络传输中为12

inet_addr返回的整数形式是网络字节序，而inet_network返回的整数形式是主机字节序。他俩都有一个小缺陷，
那就是当IP是255.255.255.255时，这两个函数会认为这是个无效的IP地址，这是历史遗留问题，其实在目前大部
分的路由器上，这个255.255.255.255的IP都是有效的。
inet_aton函数和上面这俩个函数的区别就是在于他认为255.255.255.255是有效的，他不会冤枉这个看似特殊的IP地址。对了，inet_aton函数返回的是网络字节序的IP地址。

综上所述，应该使用inet_aton和inet_ntoa这一对函数。


资料：

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

typedef uint32_t in_addr_t;

int inet_aton(const char *cp, struct in_addr *inp);
in_addr_t inet_addr(const char *cp);
in_addr_t inet_network(const char *cp);
char *inet_ntoa(struct in_addr in);
struct in_addr inet_makeaddr(int net, int host);
in_addr_t inet_lnaof(struct in_addr in);
in_addr_t inet_netof(struct in_addr in);


 

// Internet address.
struct in_addr {
        union {
                struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
                struct { u_short s_w1,s_w2; } S_un_w;
                u_long S_addr; /* port in network byte order */
        } S_un;
#define s_addr  S_un.S_addr
};
// Socket address, internet style.
struct sockaddr_in {        // struct sockaddr的一种特殊形式
        short            sin_family;    /* address family: AF_INET */
        u_short        sin_port;        /* port in network byte order */
        struct in_addr sin_addr;        /* port in network byte order */
        char            sin_zero[8];    /* 8 byte pad */
};
// Structure used by kernel to store most addresses.
struct sockaddr {
        u_short sa_family; /* address family */
        char    sa_data[14]; /* up to 14 bytes of direct address */
};

struct in_addr {
    unsigned long int s_addr;
}


 



kongkongzi 2010-08-13 17:46 发表评论
]]>ioctlhttp://www.cppblog.com/toMyself/archive/2010/08/13/123302.htmlkongkongzikongkongziFri, 13 Aug 2010 02:48:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/13/123302.html

ioctl 函数

本函数影响由fd 参数引用的一个打开的文件。

 

#include<unistd.h>

int ioctl( int fd, int request, .../* void *arg */ );

返回0 ：成功    -1 ：出错

 

第三个参数总是一个指针，但指针的类型依赖于request 参数。

我们可以把和网络相关的请求划分为6 类：

套接口操作

文件操作

接口操作

ARP 高速缓存操作

路由表操作

流系统

下表列出了网络相关ioctl 请求的request 参数以及arg 地址必须指向的数据类型：

 

类别

Request

说明

数据类型

套

接

口

SIOCATMARK

SIOCSPGRP

SIOCGPGRP

是否位于带外标记

设置套接口的进程ID 或进程组ID

获取套接口的进程ID 或进程组ID

int

int

int

 

文

 

件

 

 

FIONBIN

FIOASYNC

FIONREAD

FIOSETOWN

FIOGETOWN

 

设置/ 清除非阻塞I/O 标志

设置/ 清除信号驱动异步I/O 标志

获取接收缓存区中的字节数

设置文件的进程ID 或进程组ID

获取文件的进程ID 或进程组ID

int

int

int

int

int

 

 

 

 

接

口

 

 

 

 

 

 

 

 

 

 

SIOCGIFCONF

SIOCSIFADDR

SIOCGIFADDR

SIOCSIFFLAGS

SIOCGIFFLAGS

SIOCSIFDSTADDR

SIOCGIFDSTADDR

SIOCGIFBRDADDR

SIOCSIFBRDADDR

SIOCGIFNETMASK

SIOCSIFNETMASK

SIOCGIFMETRIC

SIOCSIFMETRIC

SIOCGIFMTU

SIOCxxx

获取所有接口的清单

设置接口地址

获取接口地址

设置接口标志

获取接口标志

设置点到点地址

获取点到点地址

获取广播地址

设置广播地址

获取子网掩码

设置子网掩码

获取接口的测度

设置接口的测度

获取接口MTU

（还有很多取决于系统的实现）

struct ifconf

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

struct ifreq

 

ARP

SIOCSARP

SIOCGARP

SIOCDARP

创建/ 修改ARP 表项

获取ARP 表项

删除ARP 表项

struct arpreq

struct arpreq

struct arpreq

路

由

SIOCADDRT

SIOCDELRT

增加路径

删除路径

struct rtentry

struct rtentry

流

I_xxx

 

 

 

 

套接口操作：

明确用于套接口操作的ioctl 请求有三个, 它们都要求ioctl 的第三个参数是指向某个整数的一个指针。

 

SIOCATMARK:    如果本套接口的的度指针当前位于带外标记，那就通过由第三个参数指向的整数返回一个非0 值；否则返回一个0 值。POSIX 以函数sockatmark 替换本请求。

SIOCGPGRP ：       通过第三个参数指向的整数返回本套接口的进程ID 或进程组ID ，该ID 指定针对本套接口的SIGIO 或SIGURG 信号的接收进程。本请求和fcntl 的F_GETOWN 命令等效，POSIX 标准化的是fcntl 函数。

SIOCSPGRP ：     把本套接口的进程ID 或者进程组ID 设置成第三个参数指向的整数，该ID 指定针对本套接口的SIGIO 或SIGURG 信号的接收进程，本请求和fcntl 的F_SETOWN 命令等效，POSIX 标准化的是fcntl 操作。

 

文件操作：

以下5 个请求都要求ioctl 的第三个参数指向一个整数。

 

FIONBIO ：        根据ioctl 的第三个参数指向一个0 或非0 值分别清除或设置本套接口的非阻塞标志。本请求和O_NONBLOCK 文件状态标志等效，而该标志通过fcntl 的F_SETFL 命令清除或设置。

 

FIOASYNC ：      根据iocl 的第三个参数指向一个0 值或非0 值分别清除或设置针对本套接口的信号驱动异步I/O 标志，它决定是否收取针对本套接口的异步I/O 信号（SIGIO ）。本请求和O_ASYNC 文件状态标志等效，而该标志可以通过fcntl 的F_SETFL 命令清除或设置。

 

FIONREAD ：     通过由ioctl 的第三个参数指向的整数返回当前在本套接口接收缓冲区中的字节数。本特性同样适用于文件，管道和终端。

 

FIOSETOWN ：    对于套接口和SIOCSPGRP 等效。

FIOGETOWN ：    对于套接口和SIOCGPGRP 等效。

 

接口配置：

得到系统中所有接口由SIOCGIFCONF 请求完成，该请求使用ifconf 结构，ifconf 又使用ifreq

结构，如下所示：

 

Struct ifconf{

    int ifc_len;                 // 缓冲区的大小

    union{

        caddr_t ifcu_buf;        // input from user->kernel

        struct ifreq *ifcu_req;    // return of structures returned

    }ifc_ifcu;

};

 

#define  ifc_buf  ifc_ifcu.ifcu_buf    //buffer address

#define  ifc_req  ifc_ifcu.ifcu_req    //array of structures returned

 

#define  IFNAMSIZ  16

 

struct ifreq{

    char ifr_name[IFNAMSIZ];           // interface name, e.g., “le0”

    union{

        struct sockaddr ifru_addr;

        struct sockaddr ifru_dstaddr;

        struct sockaddr ifru_broadaddr;

        short ifru_flags;

        int ifru_metric;

        caddr_t ifru_data;

    }ifr_ifru;

};

 

#define ifr_addr     ifr_ifru.ifru_addr            // address

#define ifr_dstaddr   ifr_ifru.ifru_dstaddr         // otner end of p-to-p link

#define ifr_broadaddr ifr_ifru.ifru_broadaddr    // broadcast address

#define ifr_flags     ifr_ifru.ifru_flags        // flags

#define ifr_metric    ifr_ifru.ifru_metric      // metric

#define ifr_data      ifr_ifru.ifru_data        // for use by interface

 

再调用ioctl 前我们必须先分撇一个缓冲区和一个ifconf 结构，然后才初始化后者。如下图

展示了一个ifconf 结构的初始化结构，其中缓冲区的大小为1024 ，ioctl 的第三个参数指向

这样一个ifconf 结构。

ifc_len

 Ifc_buf

1024

---------------------> 缓存

 

 

假设内核返回2 个ifreq 结构，ioctl 返回时通过同一个ifconf 结构缓冲区填入了那2 个ifreq 结构，ifconf 结构的ifc_len 成员也被更新，以反映存放在缓冲区中的信息量

一般来讲ioctl在用户程序中的调用是：
ioctl(int fd,int command, (char*)argstruct)
ioctl调用与网络编程有关（本文只讨论这一点），文件描述符fd实际上是由socket()系统调用返回的。参数command的取值由/usr/include/linux/sockios.h 所规定。这些command的由于功能的不同，可分为以下几个小类：
• 改变路由表 (例如 SIOCADDRT, SIOCDELRT),
• 读/更新 ARP/RARP 缓存(如：SIOCDARP, SIOCSRARP),
• 一般的与网络接口有关的(例如 SIOCGIFNAME, SIOCSIFADDR 等等)
在 Gooodies目录下有很多样例程序展示了如何使用ioctl。当你看这些程序时，注意参数argstruct是与参数command相关的。例如，与路由表相关的ioctl使用rtentry这种结构，rtentry定义在/usr/include/linux/route.h（参见例子 adddefault.c）。与ARP有关的ioctl调用使用arpreq结构，arpreq定义在/usr/include/linux /if_arp.h（参见例子arpread.c）
与网络接口有关的ioctl调用使用的command参数通常看起来像 SIOCxIFyyyy的形式，这里x要么是S（设定set，写write），要么是G（得到get，读read）。在getifinfo.c程序中就使用了这种形式的command参数来读 IP地址，硬件地址，广播地址和得到与网络接口有关的一些标志（flag）。在这些ioctl调用中，第三个参数是ifreq结构，它在/usr /include/linux/if.h中定义。在某些情况下， ioctrl调用可能会使用到在sockios.h之外的新的定义，例如，WaveLAN无线网络卡会保存有关无线网络信号强度的信息，这对用户的程序可 能有用。但用户怎么得到这种信息呢？我们的第一个本能是在sockios.h中定义新的ioctl命令，例如SIOCGIFWVLNSS（它的英文缩写表 示WaveLAN的信号强度）。但不幸的是，这种命令不是对所有其他的网络接口（例如：loopback环回接口）有意义，而且不应当允许对于 WAVLAN卡以外的网络接口使用ioctl命令。那么，我们需要的是这样一种机制：它能够定义一种与网络接口相关的ioctl命令。幸运的是，在 Linux操作系统中已经为实现这个目的内建了一种挂钩（hook）机制。当你再次看sockios.h文件时，你将发现每一种设备已经预先定义了 SIOCDEVPRIVATE的ioctl命令。而它的实现将留给开发相应驱动程序的人去完成。
通常，一个用户程序使用ioctl (sockid,SIOCDEVPRIVATE,(char*)&ifr)来调用与某种设备（指像WaveLAN那样的特殊设备）相关的 ioctl命令，这里ifr是struct ifreq ifr形式的变量。用户程序应当在ifr.ifr_name中填充与这个设备相关的名字，例如，假设WaveLAN使用的接口号为eth1。一般的，一个 用户程序还需要与内核互相交换ioctl的command参数和结果，这可以通过ifr.ifr_data这个变量来实现，例如，想得到WaveLAN中 表示信号强度的信息时，可以通过返回这个变量来实现。Linux的源代码已经包括了两种设备de4x5和ewrk3，它们定义并且实现了特定的ioctl 调用。这两个设备的源代码在de4x5.h,de4x5.c,ewrk3.h,ewrk3.c中（在 /usr/src/linux/drivers/net/目录中）。这两种设备都定义了它们特有的结构（struct ewrk3_ioctl 和 struct de4x5_ioctl）来方便用户程序和设备驱动之间交换信息。每次调用ioctl前，用户程序应当在相应的结构变量中设定合适的初值，并且将 ifr.ifr_data指向该值。
在我们进一步讨论ewrk3和de4x5的代码前，让我们仔细看看ioctl调用是如何一步步地实现的。所有的和接口相关的ioctl请求 (SIOCxIFyyyy 和 SIOCDEVPRIVATE)将会调用dev_ioctl()（在/usr/src/linux/net/core/dev.c中）。但这只是一个包装 器（wrapper），实际的动作将由dev_ifsioc()（也在dev.c中）来实现。差不多dev_ioctl()这个函数所做的所有工作只是检 查这个调用是否已经有了正当的权限（例如，改变路由表需要有root的权限）。而dev_ifsioc()这个函数首先要做的一些事情包括得到与 ifr.ifr_name相匹配的设备的结构（在/usr/include/linux/netdevice.h中定义）。但这是在实现特定的接口命令 （例如：SIOCGIFADDR）之后。这些特定的接口命令被放置到一个巨大的switch语句之中。其中SIOCDEVPRIVATE命令和其他的在 0x89F0到0x89FF之间的代码将出现在switch语句中的一个分支——default语句中。内核会检查表示设备的结构变量中，是否已经定义了 一个与设备相关的ioctl句柄（handler）。这里的句柄是一个函数指针，它在表示设备的结构变量中do_ioctl部分。如果已经设置了这个句 柄，那么内核将会执行它。
所以，如果要实现一个与设备相关的ioctl命令，所要做的只是编写一个与这个设备相关的ioctl句柄，并且将表示这 个设备的结构变量中do_ioctl部分指向这个句柄。对于ewrk3这个设备，它的句柄是ewrk3_ioctl()（在ewrk3.c里面）并且相应 的表示该设备的结构变量由ewrk3_init()来初始化。在ewrk3_ioctl()的代码中清晰的指出ifr.ifr_data是用作设备驱动程 序和用户程序之间交换信息的。注意，这部分的内存可以双向的交流信息。例如，在ewrk3的驱动程序代码中，if.ifr_data的头两个字节是用来表 示特殊的动作（例如，EWRK3_SET_PROM,EWRK3_CLR_PROM），而这个动作是符合使用者（驱动程序实现了多个与设备相关的、由 SIOCDEVPRIVATE调用的命令）的要求的。另外，ifr.ifr_data中第5个字节指向的缓冲区(buffer)被用来交换其他的信息 （如：当使用EWRK3_SET_HWADDR和EWRK3_GET_HWADDR时为硬件地址）
在你深入ewrk3_ioctl()时，请注意一般情况下一个用户进程不能直接访问内核所在的内存。为此，驱动开发者可以使用两个特殊的函数 memcpy_tofs()和memcpy_fromfs()。内核函数memcpy_tofs(arg1, arg2, arg3) 从地址arg2（用户空间）向地址arg1(内核空间)拷贝arg3个字节。类似的，memcpy_fromfs(arg1,arg2,arg3)从地址 arg2（用户空间）向地址arg1（内核空间）拷贝arg3个字节。在这些调用之前，verify_area()将会检查这个进程是否拥有合适的访问权 限。另外，注意使用printk()函数可以输出debug信息。这个函数与printf()函数类似，但不能处理浮点类型的数。内核代码不能够使用 printf()函数。printk()函数产生的结果将记录在/usr/adm/messages里。如果想知道更多的关于这些函数的或者与它们相关的 信息，可以参考《Linux Kernel Hacker’s Guide》（在Linux文档网站的首页） 这本书中Supporting Functions部分。


使用ioctl与内核交换数据

1. 前言

使用ioctl系统调用是用户空间向内核交换数据的常用方法之一，从ioctl这个名称上看，本意是针对I/O设备进行的控制操作，但实际并不限制是真正的I/O设备，可以是任何一个内核设备即可。

2. 基本过程

在内核空间中ioctl是很多内核操作结构的一个成员函数，如文件操作结构struct file_operations(include/linux/fs.h)、协议操作结构struct proto_ops(include/linux/net.h)等、tty操作结构struct tty_driver(include/linux/tty_driver.h)等，而这些操作结构分别对应各种内核设备，只要在用户空间打开这些设备， 如I/O设备可用open(2)打开，网络协议可用socket(2)打开等，获取一个文件描述符后，就可以在这个描述符上调用ioctl(2)来向内核 交换数据。

3. ioctl(2)

ioctl(2)函数的基本使用格式为：
int ioctl(int fd, int cmd, void *data)
第一个参数是文件描述符；cmd是操作命令，一般分为GET、SET以及其他类型命令，GET 是用户空间进程从内核读数据，SET是用户空间进程向内核写数据，cmd虽然是一个整数，但是有一定的参数格式的，下面再详细说明；第三个参数是数据起始位置指针，
cmd命令参数是个32位整数，分为四部分：
dir(2b) size(14b) type(8b) nr(8b)
详细定义cmd要包括这4个部分时可使用宏_IOC(dir,type,nr,size)来定义，而最简单情况下使用_IO(type, nr)来定义就可以了，这些宏都在include/asm/ioctl.h中定义
本文cmd定义为：
#define NEWCHAR_IOC_MAGIC   'M'
#define NEWCHAR_SET    _IO(NEWCHAR_IOC_MAGIC, 0)
#define NEWCHAR_GET    _IO(NEWCHAR_IOC_MAGIC, 1)
#define NEWCHAR_IOC_MAXNR   1

要定义自己的ioctl操作，可以有两个方式，一种是在现有的内核代码中直接添加相关代码进行支持，比如想通过socket描述符进行 ioctl操作，可在net/ipv4/af_inet.c中的inet_ioctl()函数中添加自己定义的命令和相关的处理函数，重新编译内核即可， 不过这种方法一般不推荐；第二种方法是定义自己的内核设备，通过设备的ioctl()来操作，可以编成模块，这样不影响原有的内核，这是最通常的做法。

4. 内核设备

为进行ioctl操作最通常是使用字符设备来进行，当然定义其他类型的设备也可以。在用户空间，可使用mknod命令建立一个字符类型设备文件，假设该设备的主设备号为123，次设备号为0：
mknode /dev/newchar c 123 0
如果是编程的话，可以用mknode(2)函数来建立设备文件。

建立设备文件后再将该设备的内核模块文件插入内核，就可以使用open(2)打开 /dev/newchar文件，然后调用ioctl(2)来传递数据，最后用close(2)关闭设备。而如果内核中还没有插入该设备的模块，open(2)时就会失败。

由于内核内存空间和用户内存空间不同，要将内核数据拷贝到用户空间，要使用专用拷贝函数 copy_to_user()；要将用户空间数据拷贝到内核，要使用copy_from_user()。
要最简单实现以上功能，内核模块只需要实现设备的open, ioctl和release三个函数即可，
下面介绍程序片断：
static int newchar_ioctl(struct inode *inode, struct file *filep,
   unsigned int cmd, unsigned long arg);
static int newchar_open(struct inode *inode, struct file *filep);
static int newchar_release(struct inode *inode, struct file *filep);
// 定义文件操作结构，结构中其他元素为空
struct file_operations newchar_fops =
{
owner: THIS_MODULE,
ioctl: newchar_ioctl,
open: newchar_open,
release: newchar_release,
};
// 定义要传输的数据块结构
struct newchar{
int a;
int b;
};
#define MAJOR_DEV_NUM 123
#define DEVICE_NAME "newchar"

打开设备，非常简单，就是增加模块计数器，防止在打开设备的情况下删除模块,
当然想搞得复杂的话可进行各种限制检查，如只允许指定的用户打开等：
static int newchar_open(struct inode *inode, struct file *filep)
{
MOD_INC_USE_COUNT;
return 0;
}

关闭设备，也很简单，减模块计数器：
static int newchar_release(struct inode *inode, struct file *filep)
{
MOD_DEC_USE_COUNT;
return 0;
}

进行ioctl调用的基本处理函数
static int newchar_ioctl(struct inode *inode, struct file *filep,
      unsigned int cmd, unsigned long arg)
{
int ret;
// 首先检查cmd是否合法
if (_IOC_TYPE(cmd) != NEWCHAR_IOC_MAGIC) return -EINVAL;
if (_IOC_NR(cmd) > NEWCHAR_IOC_MAXNR) return -EINVAL;
// 错误情况下的缺省返回值
ret = EINVAL;
switch(cmd)
{
case KNEWCHAR_SET:
// 设置操作，将数据从用户空间拷贝到内核空间
{
   struct newchar nc;
   if(copy_from_user(&nc, (const char*)arg, sizeof(nc)) != 0)
    return -EFAULT;
   ret = do_set_newchar(&nc);
}
break;
case KNEWCHAR_GET:
// GET操作通常会在数据缓冲区中先传递部分初始值作为数据查找条件，获取全部
// 数据后重新写回缓冲区
// 当然也可以根据具体情况什么也不传入直接向内核获取数据
{
   struct newchar nc;
   if(copy_from_user(&nc, (const char*)arg, sizeof(nc)) != 0)
    return -EFAULT;
   ret = do_get_newchar(&nc);
   if(ret == 0){
    if(copy_to_user((unsigned char *)arg, &nc, sizeof(nc))!=0)
     return -EFAULT;
   }
}
break;
}
return ret;
}
模块初始化函数，登记字符设备
static int __init _init(void)
{
int result;
// 登记该字符设备，这是2.4以前的基本方法，到2.6后有了些变化，
// 是使用MKDEV和cdev_init()来进行，本文还是按老方法
result = register_chrdev(MAJOR_DEV_NUM, DEVICE_NAME, &newchar_fops);
if (result < 0) {
printk(KERN_WARNING __FUNCTION__ ": failed register character device for /dev/newchar\n");
return result;
}
return 0;
}

模块退出函数，登出字符设备
static void __exit _cleanup(void)
{
int result;
result = unregister_chrdev(MAJOR_DEV_NUM, DEVICE_NAME);
if (result < 0)
printk(__FUNCTION__ ": failed unregister character device for /dev/newchar\n");
return;
}
module_init(_init);
module_exit(_cleanup);

5. 结论

用ioctl()在用户空间和内核空间传递数据是最常用方法之一，比较简单方便，而且可以在同一个ioctl中对不同的命令传送不同的数据结构，本文只是为描述方便而在不同命令中使用了相同的数据结构。


kongkongzi 2010-08-13 10:48 发表评论
]]>setsockopthttp://www.cppblog.com/toMyself/archive/2010/08/13/123300.htmlkongkongzikongkongziFri, 13 Aug 2010 02:39:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/13/123300.html一、设置 SO_LINGER 选项

 

此选项指定函数close对面向连接的协议如何操作（如TCP）。内核缺省close操作是立即返回，如果有数据残留在套接口缓冲区中则系统将试着将这些数据发送给对方。

 

SO_LINGER选项用来改变此缺省设置。使用如下结构：

struct linger {

     int l_onoff; /* 0 = off, nozero = on */

     int l_linger; /* linger time */

};

 

有下列三种情况：

1、设置 l_onoff为0，则该选项关闭，l_linger的值被忽略，等于内核缺省情况，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据；

 

2、设置 l_onoff为非0，l_linger为0，则套接口关闭时TCP夭折连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态；

 

3、设置 l_onoff 为非0，l_linger为非0，当套接口关闭时内核将拖延一段时间（由l_linger决定）。如果套接口缓冲区中仍残留数据，进程将处于睡眠状态，直 到（a）所有数据发送完且被对方确认，之后进行正常的终止序列（描述字访问计数为0）或（b）延迟时间到。此种情况下，应用程序检查close的返回值是非常重要的，如果在数据发送完并被确认前时间到，close将返回EWOULDBLOCK错误且套接口发送缓冲区中的任何数据都丢失。close的成功返回仅告诉我们发送的数据（和FIN）已由对方TCP确认，它并不能告诉我们对方应用进程是否已读了数据。如果套接口设为非阻塞的，它将不等待close完成。

 

注释：l_linger的单位依赖于实现: 4.4BSD假设其单位是时钟滴答（百分之一秒），但Posix.1g规定单位为秒。

 

下面的代码是一个使用SO_LINGER选项的例子，使用30秒的超时时限：
#define TRUE     1
#define FALSE    0
int z; /* Status code
*/ int s;       /* Socket s */
struct linger so_linger;
...
so_linger.l_onoff = TRUE;
so_linger.l_linger = 30;
z = setsockopt(s,
    SOL_SOCKET,
    SO_LINGER,
    &so_linger,
    sizeof so_linger);
if ( z )
   perror("setsockopt(2)");

下面的例子显示了如何设置SO_LINGER的值来中止套接口s上的当前连接：
#define TRUE     1
#define FALSE    0
int z; /* Status code */
int s;       /* Socket s */
struct linger so_linger;
...
so_linger.l_onoff = TRUE;
so_linger.l_linger = 0;
z = setsockopt(s,
    SOL_SOCKET,
    SO_LINGER,
    &so_linger,
    sizeof so_linger);
if ( z )
    perror("setsockopt(2)");
    close(s); /* Abort connection */

在上面的这个例子中，当调用close函数时，套接口s会立即中止。中止的语义是通过将超时值设置为0来实现的。

 

/********** WINDOWS **********/

 
/* 当连接中断时，需要延迟关闭(linger)以保证所有数据都被传输，所以需要打开SO_LINGER这个选项； 
 * //注：大致意思就是说SO_LINGER选项用来设置当调用closesocket时是否马上关闭socket；
 * linger的结构在/usr/include/linux/socket.h中定义：//注：这个结构就是SetSocketOpt中的Data的数据结构
 *　 struct linger
 *　 {
 *　　 int l_onoff;　 /* Linger active */       //低字节，0和非0，用来表示是否延时关闭socket
 *　　 int l_linger; /* How long to linger */   //高字节,延时的时间数，单位为秒
 *　 };
 *　 如果l_onoff为0，则延迟关闭特性就被取消。

 *   如果非零，则允许套接口延迟关闭； l_linger字段则指明延迟关闭的时间
 */


更具体的描述如下：
1、若设置了SO_LINGER（亦即linger结构中的l_onoff域设为非零），并设置了零超时间隔，则closesocket()不被阻塞立即执行，不论是否有排队数据未发送或未被确认。这种关闭方式称为“强制”或“失效”关闭，因为套接口的虚电路立即被复位，且丢失了未发送的数据。在远端的recv()调用将以WSAECONNRESET出错。

2、若设置了SO_LINGER并确定了非零的超时间隔，则closesocket()调用阻塞进程，直到所剩数据发送完毕或超时。这种关闭称为“优雅”或“从容”关闭。请注意如果套接口置为非阻塞且SO_LINGER设为非零超时，则closesocket()调用将以WSAEWOULDBLOCK错误返回。

3、若在一个流类套接口上设置了SO_DONTLINGER（也就是说将linger结构的l_onoff域设为零），则closesocket()调用立即返回。但是，如果可能，排队的数据将在套接口关闭前发送。请注意，在这种情况下WINDOWS套接口实现将在一段不确定的时间内保留套接口以及其他资源，这对于想用所以套接口的应用程序来说有一定影响。
 

SO_DONTLINGER 若为真，则SO_LINGER选项被禁止。
SO_LINGER延迟关闭连接 struct linger上面这两个选项影响close行为；


     选项          间隔    关闭方式  等待关闭与否
  SO_DONTLINGER   不关心     优雅         否
  SO_LINGER        零        强制         否
  SO_LINGER       非零       优雅         是

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/factor2000/archive/2009/02/23/3929816.aspx



二、设置 SO_KEEPALIVE 选项

SO_KEEPALIVE 保持连接检测对方主机是否崩溃，避免（服务器）永远阻塞于TCP连接的输入。设置该选项后，如果2小时内在此套接口的任一方向都没有数据交换，TCP就自动给对方 发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况：对方接收一切正常：以期望的ACK响应。2小时后，TCP将发出另一个探测分节。对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET，套接 口本身则被关闭。对方无任何响应：源自berkeley的TCP发送另外8个探测分节，相隔75秒一个，试图得到一个响应。在发出第一个探测分节11分钟15秒后若仍无响应就放弃。套接口的待处理错误被置为ETIMEOUT，套接口本身则被关闭。如ICMP错误是“host unreachable(主机不可达)”，说明对方主机并没有崩溃，但是不可达，这种情况下待处理错误被置为 EHOSTUNREACH。 在该书的第158页有更详细的描述。 根据上面的介绍我们可以知道对端以一种非优雅的方式断开连接的时候，我们可以设置SO_KEEPALIVE属性使得我们在2小时以后发现对方的TCP连接是否依然存在。 keepAlive = 1； Setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive)); 如果我们不能接受如此之长的等待时间，从TCP-Keepalive-HOWTO上可以知道一共有两种方式可以设置，一种是修改内核关于网络方面的配置参数，另外一种就是SOL_TCP字段的TCP_KEEPIDLE， TCP_KEEPINTVL， TCP_KEEPCNT三个选项。


三、设置 SO_REUSEADDR 选项

SO_REUSEADDR 套接字选项:使两个server socket可以监听同一个端口 默认情况下，套接字不同一个正在使用的本地地址绑定到一起。但在少数情况下，仍有必要以这种方式，来实现对一个地址的重复利用。通过第7章的学习，大家已经知道，每个连接都是通过它的本地及远程地址的组合，“独一无二”地标识出来的。针对我们想要连接的地址，只要能用极其细微的差异（比如T C P / I P中采用不同的端口号），来维持这种“独一无二”或者“唯一”的特点，绑定便是允许的。唯一例外的是监听套接字。两个独立的套接字不可与同一个本地接口（在T C P / I P的情况下，则是端口）绑定到一起，以等待进入的连接通知。 假定两个套接字都在同一个端口上进行监听，那么到底由谁来接收一个进入连接通知呢？对于这个问题，目前尚无一种正式规范提出了解决方案。在T C P的环境下，假如服务器关闭，或异常退出，造成本地地址和端口均进入T I M E _ WA I T状态，那么S O _ R E U S E A D D R 这个套接字选项便显得非常有用。在T I M E _ WA I T状态下，其他任何套接字都不能与那个端口绑定到一起。但假若设置了该选项，服务器便可在重新启动之后，在相同的本地接口及端口上进行监听。 将服务端socket套接字设置上SO_REUSEADDR属性,代码如下: //设置socket套接字的属性:允许多个设备在同一个本地网中监听同一下端口 int one = 1; if (sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one))) { printf("setsockopt SO_REUSEADDR error\n"); close(sock); return; } 这么设置套接字的作用是:允许两个server端的套接字在同一个本地网段中监听同一个端口.

四、设置 TCP_NODELA 选项

TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在这里的含义是采用Nagle算法把较小的包组装为更大的帧。John Nagle是Nagle算法的发明人，后者就是用他的名字来命名的，他在1984年首次用这种方法来尝试解决福特汽车公司的网络拥塞问题（欲了解详情请参看IETF RFC 896）。他解决的问题就是所谓的silly window syndrome ，中文称“愚蠢窗口症候群”，具体含义是，因为普遍终端应用程序每产生一次击键操作就会发送一个包，而典型情况下一个包会拥有一个字节的数据载荷以及40个字节长的包头，于是产生4000%的过载，很轻易地就能令网络发生拥塞,。 Nagle化后来成了一种标准并且立即在因特网上得以实现。它现在已经成为缺省配置了，但在我们看来，有些场合下把这一选项关掉也是合乎需要的。 现在让我们假设某个应用程序发出了一个请求，希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。如果我们马上发送数据，那么交互性的以及客户/服务器型的应用程序将极大地受益。例如，当我们正在发送一个较短的请求并且等候较大的响应时，相关过载与传输的数据总量相比就会比较低，而且，如果请求立即发出那么响应时间也会快一些。以上操作可以通过设置套接字的TCP_NODELAY选项来完成，这样就禁用了Nagle算法。 另外一种情况则需要我们等到数据量达到最大时才通过网络一次发送全部数据，这种数据传输方式有益于大量数据的通信性能，典型的应用就是文件服务器。应用Nagle算法在这种情况下就会产生问题。但是，如果你正在发送大量数据，你可以设置TCP_CORK选项禁用Nagle化，其方式正好同TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就让我们仔细分析下其工作原理。 假设应用程序使用sendfile()函数来转移大量数据。应用协议通常要求发送某些信息来预先解释数据，这些信息其实就是报头内容。典型情况下报头很小，而且套接字上设置了TCP_NODELAY。有报头的包将被立即传输，在某些情况下（取决于内部的包计数器），因为这个包成功地被对方收到后需要请求对方确认。这样，大量数据的传输就会被推迟而且产生了不必要的网络流量交换。 但是，如果我们在套接字上设置了TCP_CORK（可以比喻为在管道上插入“塞子”）选项，具有报头的包就会填补大量的数据，所有的数据都根据大小自动地通过包传输出去。当数据传输完成时，最好取消TCP_CORK 选项设置给连接“拔去塞子”以便任一部分的帧都能发送出去。这同“塞住”网络连接同等重要。 总而言之，如果你肯定能一起发送多个数据集合（例如HTTP响应的头和正文），那么我们建议你设置TCP_CORK选项，这样在这些数据之间不存在延迟。能极大地有益于WWW、FTP以及文件服务器的性能，同时也简化了你的工作。

kongkongzi 2010-08-13 10:39 发表评论
]]>如何划分子网http://www.cppblog.com/toMyself/archive/2010/08/12/123155.htmlkongkongzikongkongziThu, 12 Aug 2010 02:58:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/12/123155.html网络ID为“192.168.0.0/24”，这个网络ID中的IP地址是一个C类网段，其中“24”表示在二进制形式的子网掩码中“1”的个数是24个。其实这是“255.255.255.0”的另外一种表示方法，每个“255”表示二进制的8个“1”，最后的“0”表示二进制的8个“0”，用二进制表示为“11111111.11111111.11111111.00000000”。

　　果冻提示：可别小看这个“0”，根据“0”的个数可以计算出该子网能够容纳的客户机的数量。

 



kongkongzi 2010-08-12 10:58 发表评论
]]>网络地址转换（NAT）http://www.cppblog.com/toMyself/archive/2010/08/12/123150.htmlkongkongzikongkongziThu, 12 Aug 2010 02:40:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/12/123150.html摘要

网络地址转换(NAT,Network Address Translation)属接入广域网(WAN)技术,是一种将私有(保留)地址转化为合法IP地址的转换技术,它被广泛应用于各种类型Internet接入方式和各种类型的网络中。原因很简单，NAT不仅完美地解决了lP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。


网络地址转换(NAT,NetworkAddressTranslation)被广泛应用于各种类型Internet接入方式和备种类型的网络中。原因很简单，NAT不仅完美地解决了lP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。虽然NAT可以借助于某些代理服务器来实现，但考虑到运算成本和网络性能，很多时候都是在路由器上来实现的。随着接入Internet的计算机数量的不断猛增，IP地址资源也就愈加显得捉襟见肘。事实上，除了中国教育和科研计算机网(CERNET)外，一般用户几乎申请不到整段的C类IP地址。在其他ISP那里，即使是拥有几百台计算机的大型局域网用户，当他们申请IP地址时，所分配的地址也不过只有几个或十几个IP地址。显然，这样少的IP地址根本无法满足网络用户的需求，于是也就产生了NAT技术。

 

网络地址转换-基本简介

    

网络地址转换

借助于NAT，私有(保留)地址的"内部"网络通过路由器发送数据包时，私有地址被转换成合法的IP地址，一个局域网只需使用少量IP地址(甚至是1个)即可实现私有地址网络内所有计算机与Internet的通信需求。

 

NAT将自动修改IP报文头申的源IP地址和目的IP地址，Ip地址校验则在NAT处理过程中自动完成。有些应用程序将源IP地址嵌入到IP报文的数据部分中，所以还需要同时对报文进行修改，以匹配IP头中已经修改过的源IP地址。否则，在报文数据都分别嵌入IP地址的应用程序就不能正常工作。

网络地址转换-实现方式

    

NAT静态转换

NAT的实现方式有三种，即静态转换StaticNat、动态转换DynamicNat和端口多路复用OverLoad。

 

静态转换是指将内部网络的私有IP地址转换为公有IP地址，IP地址对是一对一的，是一成不变的，某个私有IP地址只转换为某个公有IP地址。借助于静态转换，可以实现外部网络对内部网络中某些特定设备(如服务器)的访问。

动态转换是指将内部网络的私有IP地址转换为公用IP地址时，IP地址对是不确定的，而是随机的，所有被授权访问上Internet的私有IP地址可随机转换为任何指定的合法IP地址。也就是说，只要指定哪些内部地址可以进行转换，以及用哪些合法地址作为外部地址时，就可以进行动态转换。动态转换可以使用多个合法外部地址集。当ISP提供的合法IP地址略少于网络内部的计算机数量时。可以采用动态转换的方式。

端口多路复用是指改变外出数据包的源端口并进行端口转换，即端口地址转换(PAT，PortAddressTranslation).采用端口多路复用方式。内部网络的所有主机均可共享一个合法外部IP地址实现对Internet的访问，从而可以最大限度地节约IP地址资源。同时，又可隐藏网络内部的所有主机，有效避免来自internet的攻击。因此，目前网络中应用最多的就是端口多路复用方式。





NAT英文全称是“Network Address Translation”，中文意思是“网络地址转换”，它是一个IETF(Internet Engineering Task Force, Internet工程任务组)标准，允许一个整体机构以一个公用IP（Internet Protocol）地址出现在Internet上。顾名思义，它是一种把内部私有网络地址（IP地址）翻译成合法网络IP地址的技术。如图


    简单的说，NAT就是在局域网内部网络中使用内部地址，而当内部节点要与外部网络进行通讯时，就在网关（可以理解为出口，打个比方就像院子的门一样）处，将内部地址替换成公用地址，从而在外部公网（internet）上正常使用，NAT可以使多台计算机共享Internet连接，这一功能很好地解决了公共IP地址紧缺的问题。通过这种方法，您可以只申请一个合法IP地址，就把整个局域网中的计算机接入Internet中。这时，NAT屏蔽了内部网络，所有内部网计算机对于公共网络来说是不可见的，而内部网计算机用户通常不会意识到NAT的存在。如图2所示。这里提到的内部地址，是指在内部网络中分配给节点的私有IP地址，这个地址只能在内部网络中使用，不能被路由（一种网络技术，可以实现不同路径转发）。虽然内部地址可以随机挑选，但是通常使用的是下面的地址：10.0.0.0~10.255.255.255，172.16.0.0~172.16.255.255，192.168.0.0~192.168.255.255。NAT将这些无法在互联网上使用的保留IP地址翻译成可以在互联网上使用的合法IP地址。而全局地址，是指合法的IP地址，它是由NIC（网络信息中心）或者ISP(网络服务提供商)分配的地址，对外代表一个或多个内部局部地址，是全球统一的可寻址的地址。


    NAT功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中。比如Cisco路由器中已经加入这一功能，网络管理员只需在路由器的IOS中设置NAT功能，就可以实现对内部网络的屏蔽。再比如防火墙将WEB Server的内部地址192.168.1.1映射为外部地址202.96.23.11，外部访问202.96.23.11地址实际上就是访问访问192.168.1.1。另外资金有限的小型企业来说，现在通过软件也可以实现这一功能。Windows 98 SE、Windows 2000 都包含了这一功能。

 

    NAT技术类型
    NAT有三种类型：静态NAT(Static NAT)、动态地址NAT(Pooled NAT)、网络地址端口转换NAPT（Port－Level NAT）。
    其中静态NAT设置起来最为简单和最容易实现的一种，内部网络中的每个主机都被永久映射成外部网络中的某个合法的地址。而动态地址NAT则是在外部网络中定义了一系列的合法地址，采用动态分配的方法映射到内部网络。NAPT则是把内部地址映射到外部网络的一个IP地址的不同端口上。根据不同的需要，三种NAT方案各有利弊。
    动态地址NAT只是转换IP地址，它为每一个内部的IP地址分配一个临时的外部IP地址，主要应用于拨号，对于频繁的远程联接也可以采用动态NAT。当远程用户联接上之后，动态地址NAT就会分配给他一个IP地址，用户断开时，这个IP地址就会被释放而留待以后使用。
    网络地址端口转换NAPT（Network Address Port Translation）是人们比较熟悉的一种转换方式。NAPT普遍应用于接入设备中，它可以将中小型的网络隐藏在一个合法的IP地址后面。NAPT与动态地址NAT不同，它将内部连接映射到外部网络中的一个单独的IP地址上，同时在该地址上加上一个由NAT设备选定的TCP端口号。
    在Internet中使用NAPT时，所有不同的信息流看起来好像来源于同一个IP地址。这个优点在小型办公室内非常实用，通过从ISP处申请的一个IP地址，将多个连接通过NAPT接入Internet。实际上，许多SOHO远程访问设备支持基于PPP的动态IP地址。这样，ISP甚至不需要支持NAPT，就可以做到多个内部IP地址共用一个外部IP地址上Internet，虽然这样会导致信道的一定拥塞，但考虑到节省的ISP上网费用和易管理的特点，用NAPT还是很值得的。




 




参考资料：
1、互动百科：http://www.hudong.com/wiki/%E7%BD%91%E7%BB%9C%E5%9C%B0%E5%9D%80%E8%BD%AC%E6%8D%A2 
2、IT168：http://publish.it168.com/cword/514.shtml 

kongkongzi 2010-08-12 10:40 发表评论
]]>Tcp 断开连接http://www.cppblog.com/toMyself/archive/2010/08/11/123072.htmlkongkongzikongkongziWed, 11 Aug 2010 07:34:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/11/123072.htmlTCP状态转移要点
    TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得注意的状态有两个：CLOSE_WAIT和TIME_WAIT。
1、LISTENING状态
　　FTP服务启动后首先处于侦听（LISTENING）状态。
2、ESTABLISHED状态
　　ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
    对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4、TIME_WAIT
    我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。
    目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。
 
 
 
在连接撤销过程中，有如下四个过程:   

1.         HOST1上的应用程序关闭己方的连接导致TCP发送一个FIN消息给HOST2。
2.         HOST2发送一个确认消息给HOST1,并且HOST2把FIN作为EOF递交给HOST2上的应用程序。
3.         一段时间过后，HOST2上的应用程序关闭它那边的连接，引发一个FIN消息给HOST1。
4.         HOST1给HOST2发送一个确认消息，然后HOST2关闭连接并释放资源，然而，HOST1却没有关闭连接，而是进入了TIME_WAIT状态，并为两个最大段生存时间(2MSL)保留在此状态.

为什么需要time_wait?
1.       因为在第四步的时候，HOST1发送的ACK可能丢失并导致HOST2重新发送FIN消息，TIME_WAIT维护连接状态.
       如果执行主动关闭的一方HOST1 不进入到TIME_WAIT状态就关闭连接那会发生什么呢？当重传的FIN消息到达时，因为TCP已经不再有连接的信息了，所以就用RST(重新启动)消息应答，导致HOST2进入错误的状态而不是有序终止状态，如果发送最后ACK消息的一方处于TIME_WAIT状态并仍然记录着连接的信息，它就可以正确的响应对等方HOST2的FIN消息了.
2.       TIME_WAIT为连接中”离群的段”提供从网络中消失的时间.
         考虑一下，如果延迟或者重传段在连接关闭后到达时会发生什么呢？通常情况下，因为TCP仅仅丢弃该数据并响应RST消息，所以这不会造成任何问题。当RST消息到达发出延时段的主机时，因为该主机也没有记录连接的任何信息，所以它也丢弃该段。然而，如果两个相同主机之间又建立了一个具有相同端口号的新连接，那么离群的段就可能被看成是新连接的，如果离群的段中数据的任何序列号恰恰在新连接的当前接收窗口中，数据就会被重新接收，其结果就是破坏新连接。

 
 
 
 
一、TCP连接关闭的几种方式：
1、“正常”关闭：调用close()关闭socket、没close但进程正常结束(当然这是不应该的做法)、进程core掉、在shell命令行中kill掉进程，都可抽象成“正常”关闭。因为即使core掉，内核也会马上帮应用程序回收(close)socket文件描述符。
     “正常”关闭，默认情况下(非默认即设置Linger下面会介绍)，关闭端即客户端TCP层会发FIN包，对端即服务器TCP层收到后，回ACK，客户端进入FIN_WAIT2状态。此时，TCP终止连接的4个分组中服务器应该发的第3个分组FIN包，其TCP层是不会主动发的，只有服务器端socket“正常”关闭，才会发出这个FIN包。至此，客户端进入TIME_WAIT状态。
2、“非”正常关闭：客户端崩溃了，此时肯定发不出FIN包了(当然啦，内核都没机会帮应用程序回收资源了)。这种情况，服务器端有如下两种情况：
    A、服务器send数据，因为客户端已经崩溃，服务器收不到ACK自然会不停的重传。源自
        Berkeley的重传机制，重传8次，相对第一次传的15分钟后仍没收到ACK，则返回
        ETIMEDOUT或EHOSTUNREAC错误。如果服务器不理会这个错误，再次调用send，则
        立马返回Broken Pipe错误。    
       注：15分钟超时可以在 /proc/sys/net/ipv4/tcp_retries2 中修改
   B、 服务器不发任何数据了，那只有靠应用层心跳检测机制或Keepalive，来发觉TCP断连了。
二、SO_LINGER套接口选项
           A、l_onoff设置为0，这也是默认情况，函数close()是立即返回的，然后TCP连接双方是通过
                FIN、ACK4分组来终止TCP连接的。当然,发送缓冲区还有数据的话，系统将试着将这些数据
                发送到对方。
           B、l_onoff非0，l_linger设置0，函数close()立即返回，并发送RST终止连接，发送缓冲区的数据丢弃。
           C、l_onoff非0，l_linger非0，函数close()不立即返回,而是在(a)发送缓冲区数据发送完并得到确认
                 (b)l_linger延迟时间到,l_linger时间单位为微妙。两者之一成立时返回。如果在发送缓冲区数据发送
                完并被确认前延迟时间到的话，close返回EWOULDBLOCK(或EAGAIN)错误。
三、客户端TCP连接“正常”关闭，服务器的几种情况：
          情形 客户端l_onoff设置为0，
“正常”关闭 客户端l_onoff非0，l_linger设置0,“正常”关闭
服务器阻塞模式send，正阻塞在send函数未返回 客户端TCP发送FIN，服务器send函数返回成功(返回字节数是实际拷贝到发送缓冲区的字节数)。客户端发送RST。如果服务器再次调用send,将返回errno[32]:Broken pipe 客户端TCP发送RST，服务器函数返回成功(返回字节数是实际拷贝到发送缓冲区的字节数)。若服务器再次调用send，则返回-1，errno[104]:Connection reset by peer。若再次调用send，则返回-1，errno[32]:Broken pipe
服务器空闲 客户端TCP发送FIN，若服务器没理会而调用send，客户端发送RST，send返回-1，errno[32]:Broken pipe 客户端TCP发送RST,若服务器没理会而调用send，send返回-1，errno[104]:Connection reset by peer。若再次调用send，则返回-1，errno[32]:Broken pipe
总之，1、收到对端RST后，仍然调入send()，则返回Connection reset by peer,再次调用send()，则返回Broken pipe
         2、收到对端FIN后，仍然调研哪个send(),直接返回Broken pipe


kongkongzi 2010-08-11 15:34 发表评论
]]>TCP: SYN ACK FIN RST PSH URG 详解http://www.cppblog.com/toMyself/archive/2010/08/11/123068.htmlkongkongzikongkongziWed, 11 Aug 2010 07:08:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/11/123068.html
三次握手Three-way Handshake
一个虚拟连接的建立是通过三次握手来实现的
1. (B) –> [SYN] –> (A)
假如服务器A和客户机B通讯. 当A要和B通信时，A首先向B发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不能让外部任何主机主动建立连接。
2. (A) <– [SYN/ACK] <–(B)
接着，B收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.
注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.
3. (A) –> [ACK] –> (B)
A收到SYN/ACK 包,A发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位
这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包
四次握手Four-way Handshake
四次握手用来关闭已建立的TCP连接
1. (B) –> ACK/FIN –> (A)
2. (B) <– ACK <– (A)
3. (B) <– ACK/FIN <– (A)
4. (B) –> ACK –> (A)
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的
连接复位Resetting a connection
四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记
请注意RST包是可以不要收到方确认的?
无效的TCP标记Invalid TCP Flags
到目前为止，你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和URG (Urgent)标记.
最常见的非法组合是SYN/FIN 包. 注意:由于 SYN包是用来初始化连接的, 它不可能和 FIN和RST标记一起出现. 这也是一个恶意攻击.
由于现在大多数防火墙已知 SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。
别的已知的非法包有FIN (无ACK标记)和”NULL”包。如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有 ACK 标记。”NULL”包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。
到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。
UDP (用户数据包协议User Datagram Protocol)
TCP是面向连接的，而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机制。对丢包的处理是在应用层来完成的。(or accidental arrival).
此处需要重点注意的事情是：在正常情况下，当UDP包到达一个关闭的端口时，会返回一个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到达目的地。因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口(?)。
由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口(非防火墙的)的UDP包将不会到达目的，它们将返回一个复位UDP包。
因为这个原因，UDP端口扫描总是不精确、不可靠的。
看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式 (这里有个DOS攻击的例子，http://grc.com/dos/grcdos.htm ).
ICMP (网间控制消息协议Internet Control Message Protocol)
如同名字一样， ICMP用来在主机/路由器之间传递控制信息的协议。 ICMP包可以包含诊断信息(ping, traceroute – 注意目前unix系统中的traceroute用UDP包而不是ICMP)，错误信息(网络/主机/端口 不可达 network/host/port unreachable), 信息(时间戳timestamp, 地址掩码address mask request, etc.)，或控制信息 (source quench, redirect, etc.) 。
你可以在http://www.iana.org/assignments/icmp-parameters中找到ICMP包的类型。
尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。
Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用来转发通讯。
Echo (8), Timestamp (13) and Address Mask Request (17) 能用来分别判断主机是否起来，本地时间和地址掩码。注意它们是和返回的信息类别有关的。它们自己本身是不能被利用的，但它们泄露出的信息对攻击者是有用的。
ICMP消息有时也被用来作为DOS攻击的一部分(例如：洪水ping flood ping,死 ping ?呵呵，有趣 ping of death)?/p>
包碎片注意A Note About Packet Fragmentation
如果一个包的大小超过了TCP的最大段长度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit)，能够把此包发往目的的唯一方法是把此包分片。由于包分片是正常的，它可以被利用来做恶意的攻击。
因为分片的包的第一个分片包含一个包头，若没有包分片的重组功能，包过滤器不可能检测附加的包分片。典型的攻击Typical attacks involve in overlapping the packet data in which packet header is 典型的攻击Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作为 DOS 攻击的一部分，它可以crash older IP stacks 或涨死CPU连接能力。
Netfilter/Iptables中的连接跟踪代码能自动做分片重组。它仍有弱点，可能受到饱和连接攻击，可以把CPU资源耗光。
握手阶段：
序号 方向 seq ack
1　　A->B 10000 0
2 B->A 20000 10000+1=10001
3 A->B 10001 20000+1=20001
解释：
1：A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0
2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001
3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001
数据传输阶段：
序号　　方向　　　　　　seq ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释：
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24:于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头，IP头，TCP头)，以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。
其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.


kongkongzi 2010-08-11 15:08 发表评论
]]>连接状态http://www.cppblog.com/toMyself/archive/2010/08/03/122071.htmlkongkongzikongkongziTue, 03 Aug 2010 08:06:00 GMThttp://www.cppblog.com/toMyself/archive/2010/08/03/122071.html　　ESTABLISHED 有一个确定的连接
　　SYN_SENT 活动socket尝试建立连接
　　SYN_RECV 连接请求已经收到
　　FIN_WAIT1 socket已经关闭，链接已经断开。
　　FIN_WAIT2 socket已经关闭，链接在最后断开。
　　TIME_WAIT The socket is waiting after close to handle packets still in the network.
　　CLOSED The socket is not being used.
　　CLOSE_WAIT The remote end has shut down, waiting for the socket to close.
　　LAST_ACK The remote end has shut down, and the socket is closed. Waiting for acknowledgement.
　　LISTEN The socket is listening for incoming connections.
　　CLOSING Both sockets are shut down but we still donot have all our data sent.
　　UNKNOWN The state of the socket is unknown.

kongkongzi 2010-08-03 16:06 发表评论
]]>网络编程时的注意点http://www.cppblog.com/toMyself/archive/2009/09/15/96257.htmlkongkongzikongkongziTue, 15 Sep 2009 10:13:00 GMThttp://www.cppblog.com/toMyself/archive/2009/09/15/96257.html

从网络上来的整形数据，若使用string来接收，则可能因为整形数据中含有字符0而将整形数据截断了。


考虑问题(目前定位)要从系统API层来考虑，所有的在系统API上的库都是垃圾。



kongkongzi 2009-09-15 18:13 发表评论
]]>建立连接http://www.cppblog.com/toMyself/archive/2009/03/05/75638.htmlkongkongzikongkongziThu, 05 Mar 2009 07:37:00 GMThttp://www.cppblog.com/toMyself/archive/2009/03/05/75638.html
        一条已经建立的连接当TCP的一方已经在自己一端关闭或者中断连接且不知道另一端的情况，或者当连接双方由于崩溃导致失忆变成不同步，就称为“半打开”的连接。如果尝试在该连接的任何一个方向上发送数据，这个连接就会自动变成reset。

        如果在A端连接不再存在，则用户在B端在该连接发送任何数据会导致B端的TCP接收到一个reset控制信息。该信息指示B端TCP连接发生了错误，且它被期望终止连接。

        Rest产生：作为一条基本规则，reset（RST）在一个分片到达且明显不是当前连接的分片的任何时候必须被发送。如果还不清楚，reset不能被发送


kongkongzi 2009-03-05 15:37 发表评论
]]>