htons和htonl引发的惨案

为什么80%的码农都做不了架构师？>>>   

什么都不说，先抛出问题：

客户端：connect: Connection refused

调试服务器出现以下问题：

port:传入的服务器端口号，设置为8888

srvaddr.sin_port：将本地端口号转化为网络端口号后存放在网络套接口地址数据结构中

这里竟然是0!

此处使用的是htonl

这就是死在htons手下的客户端，将客户端与服务器分割在银河的两端

原因：没有注意网络套接口地址数据结构中sin_port的数据类型，以及误以为htonl可以随意替代htons使用

IPV4通用网络套接口地址数据结构：

struct sockaddr_in {
               sa_family_t    sin_family; /* address family: AF_INET */
               in_port_t      sin_port;   /* port in network byte order */
               struct in_addr sin_addr;   /* internet address */
           };

       /* Internet address. */
           struct in_addr {
               uint32_t       s_addr;     /* address in network byte order */
           };

其中：in_port_t ：TCP或UDP端口，一般为uint16_t

Ps : Posix.lg中数据类型

数据类型	说明	头文件
int8_t	带符号的8位整数	sys/types.h
uint8_t	无符号的8位整数	sys/types.h
int16_t	带符号的16位整数	sys/types.h
uint16_t	无符号的16位整数	sys/types.h
int32_t	带符号的32位整数	sys/types.h
uint32_t	无符号的32位整数	sys/types.h
sa_family_t	套接口地址结构的地址簇	sys/socket.h
socklen_t	套接口地址的长度，一般为uint32_t	sys/socket.h
in_port_t	TCP或UDP端口，一般为uint16_t	netinet/in.h
in_addr_t	Ipv4地址，一般为uint32_t	netinet/in.h

 

字节排序函数

计算机内存中有两种数据存储方式，一种为小端字节序，也就是低地址存储数据低字节，高地址存储数据高字节；一种为大端字节序，也就是低地址存储高字节，高地址存储低字节。网络字节序采用大端字节序，而主机字节序有可能为小端字节序，因此，存在着字节序的转换问题。

函数：

uint16_t htons(uint16_t hostvalue);
uint32_t htonl(uint32_t hostvalue);
uint16_t ntohs(uint16_t netvalue);
uint16_t ntohl(uint32_t netvalue);

头文件：netinet/in.h

说明:函数中h表示host，n表示network，s表示short，l表示long，使用htons转换端口号，htonl和ntohl转换IP地址。

结果一目了然.....

Ps:部分内容引自：http://blog.csdn.net/xiaoweibeibei/article/details/6584250

转载于:https://my.oschina.net/SBaof/blog/477585