bind

使用格式

#include <sys/types.h>

#include <sys/socket.h>

int  bind( int   sockfd ,  const struct sockaddr  * addr , socklen_t  * addrlen );

功能描述

当用socket()函数创建套接字以后，套接字在名称空间(网络地址族)中存在，但没有任何地址给它赋值。

参数

 参数
sockfd 
指定地址与哪个套接字绑定，这是一个由之前的socket函数调用返回的套接字。调用bind的函数之后，该套接字与一个相应的地址关联，发送到这个地址的数据可以通过这个套接字来读取与使用。
 
参数
addr 
指定地址。这是一个地址结构，并且是一个已经经过填写的有效的地址结构。调用bind之后这个地址与参数sockfd指定的套接字关联，从而实现上面所说的效果。
 
参数
addrlen 
正如大多数socket接口一样，内核不关心地址结构，当它复制或传递地址给驱动的时候，它依据这个值来确定需要复制多少数据。这已经成为socket接口中最常见的参数之一了。

 

bind()把用addr指定的地址赋值给用文件描述符代表的套接字sockfd。addrlen指定了以addr所指向的地址结构体的字节长度。一般来说，该操作称为“给套接字命名”。

通常，在一个SOCK_STREAM套接字接收连接之前，必须通过bind()函数用本地地址为套接字命名。

 

备注：

调用bind()函数之后，为socket()函数创建的套接字关联一个相应地址，发送到这个地址的数据可以通过该套接字读取与使用。

bind()函数并不是总是需要调用的，只有用户进程想与一个具体的地址或端口相关联的时候才需要调用这个函数。如果用户进程没有这个需要，那么程序可以依赖内核的自动的选址机制来完成自动地址选择，而不需要调用bind()函数，同时也避免不必要的复杂度。在一般情况下，对于服务器进程问题需要调用bind()函数，对于客户进程则不需要调用bind()函数。

套接字的命名规则在不同的网络协议族中有所不同。对于AF_INET参看ip()，对于AF_INET6参看ipv6()，对于AF_INET6参看unix()，对于AF_APPLETALK参看ddp()，对于AF_APPLETALK参看packet()，对于AF_X25参看x25()，对于AF_NETLINK参看netlink()。

传送给参数addr的实际结构依赖于网络协议族。sockaddr结构定义为如下格式：

[plain]  view plain copy print ?

1. struct sockaddr {  
2.     sa_family_t     sa_family;  
3.     char            sa_data[14];  
4. }  

该结构的唯一目的是强制结构指针在addr参数中传送，以避免编译过程出现warning。参看如下实例。

返回值

成功，返回0；出错，返回－1，相应地设定全局变量errno。

错误

EACCESS

地址空间受保护，用户不具有超级用户的权限。

EADDRINUSE

给定的地址正被使用。

原文：http://blog.csdn.net/david_xtd/article/details/7090590

在最开始接触bind的时候，只是在写基于tcp的server端的时候，知道在listen之前需要先bind一下，用来确保socket能在某个固定的端口监听。而bind的时候，函数参数中的端口填自己将要绑定的端口就行；而IP地址，需要填本机的IP，但是也可以用一个宏INADDR_ANY代替，用这个宏就可以不用查找本机的IP，它就可以代替本机的IP。当时只觉得这个INADDR_ANY比较神奇，但是由于当时觉得用起来很方便，也没出啥问题，也就没有再深究

　　但是最近在做RTSP服务器的时候，有种特殊的应用，导致我不得不对bind这个函数仔细地看一下。
　　我们知道无论是UDP还是TCP，socket都会与一个本地的IP和端口想对应，我们往往把这个IP和端口称之为socket的源地址和源端口。当我们作为客户端利用socket去发送数据时，很少会去考虑这个源地址和源端口到底是什么，我们更关心的是它的目的地址和端口。我们往往只有在监听的时候，才去考虑这个源端口，所以我们在监听的时候会去用bind。当我们bind之后，内核就会将这个socket的源端口锁定到我们设定的端口上。但是这就有一个问题，这个bind绑定端口，是将本来没有源端口的socket绑定到我们指定的端口上，还是将一个已经分配了端口的socket重定向到我们指定的端口上呢？
　　在《UNIX网络编程》这本书中提到：“如果一个TCP客户或者服务器未曾调用bind捆绑一个端口，当调用connect或listen时，内核就要为相应的套接字选择一个临时接口。”从这句话中可以判断出，其实在调用socket函数创建socket时，内核还并未给socket分配源地址和源端口。而对于UDP，我猜测在调用sendto发送数据时，在未捆绑端口的情况下，内核也会随机分配端口。
　　而我遇到的特殊应用要求我在用UDP发送数据之前要告诉对方我的发送端口，这也就意味着我在sendto之前必须要捆绑端口，因此我在发送数据之前就得调用bind函数绑定一下端口了。但是我就在想内核既然有随机分配端口的能力，而我需要的也只是让它绑定一下而不用绑定在固定端口的业务，socket中应该能够提供这种业务。然后果然我发现bind就具备这种能力，当bind的参数中端口地址为0的时候，这时候就是由内核分配端口。这样我就不用考虑端口地址重复的问题，而放心的把这个问题交给内核处理了。
　　就在发现bind的这个机制的同时，我发现其实bind对于源地址也同样具备这种处理方式，当系统具有多IP（多网卡）的情况，当我们把bind函数中的ip参数置0时，就是由内核自己选择分配IP。而之前一直觉得很神奇的INADDR_ANY其实一点也不神奇，它的值其实就是0。所以当我们只有单一IP的时候，我们就可以用INADDR_ANY去代替那个单一的IP，因为内核分配的时候只能选择这一个IP。从而造成了INADDR_ANY就是本机IP的现象。

 

原文：http://www.cnblogs.com/nightwatcher/archive/2011/07/03/2096717.html