探讨和请教一个socket的端口绑定问题,编程高手千万不能错过,也许你还没发现这个问题~!

KuangXiang 2000-08-28 06:15:00
各位专家好!
工作中发现了一个问题这里解释如下:
请大家指教和发表一下自己的观点
我写了一个很简单的socket通信的server程序,大家都知道用了哪些函数:
socket(),bind(),listen()等等,这个时候我的通信socket就开始工作了,
比如我bind(123)端口的话,那么当外边向123端口发信息的时候,我的这个
程序就知道了,ok!现在的问题是: 我如果在建立一个同样的socket通信的
server程序的话,如果我在bind()到123端口的话,我的bind函数就会失败,程序会
提示bind失败,因为第一个通信程序已经bind了该端口,到这里都还很正常!
那么问题如下:
大家都知道windows NT机器有个netbios的139端口,该端口在系统的server启动
后就开始listen了(可以用一个端口扫描程序看得到该端口是正在listen的),
这个时候,如果我做一个socket通信程序bind到139端口的话,我竟然发现我能
bind成功!!!!
所以问题就在这里,就是说为什么可以进行两次bind到139的操作(一次是系统的server
服务启动后,一次是我自己写的server程序bind的),那么我听说windows 中有一个socket的dup功能,可以把本身的socket信息复制到另一个socket套接字中!~

另外需要强调的一点是,我虽然写程序bind到了139成功了,但是当外界和我这个在listen
139端口的程序通信的时候我这个程序并不能收到任何发过来的信息!
请大家指教和探讨!
为什么bind到已经在listening的139端口可以成功?
谢谢大家!

...全文
564 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
Tice 2001-07-14
  • 打赏
  • 举报
回复
重复bind只对udp有效,对tcp随可以bind成功,但无法得到数据
WhiteWaterBlueSky 2001-07-14
  • 打赏
  • 举报
回复
这是竟然是2000-8-28 18:15:00 KuangXiang的贴啊!
咦!!!又是meifen(meifen)兄弟第一个把它掏出来啦!
xxxbird 2001-07-14
  • 打赏
  • 举报
回复

一个完全的连接包含5个部分:
<协议,本地IP,本地Port, 远程IP, 远程Port>

只有这5个部分不全部相同的连接才是有效的。在你Bind的时候,需要你前3个不完全相同的时候才可能成功。唯一的例外就是vcbear与Kevin_qing说的情况。


vcbear 2001-07-13
  • 打赏
  • 举报
回复
摘录一段,你看有没有帮助

15. SO_REUSEADDR
选项值类型获取/设置Wi n s o c k版本说明
布尔值两者均可1 + 如果是T R U E,套接字就可与一个正由其他套接字使用的地
址绑定到一起,或与处在T I M E _ WA I T状态的地址绑定到一起
默认情况下,套接字不同一个正在使用的本地地址绑定到一起。但在少数情况下,仍有
必要以这种方式,来实现对一个地址的重复利用。通过第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状态下,其他任何套接字都不能与那个端口绑定到一起。但假若设置了该选项,
服务器便可在重新启动之后,在相同的本地接口及端口上进行监听。
vcbear 2001-07-13
  • 打赏
  • 举报
回复
摘录一段,你看有没有帮助

15. SO_REUSEADDR
选项值类型获取/设置Wi n s o c k版本说明
布尔值两者均可1 + 如果是T R U E,套接字就可与一个正由其他套接字使用的地
址绑定到一起,或与处在T I M E _ WA I T状态的地址绑定到一起
默认情况下,套接字不同一个正在使用的本地地址绑定到一起。但在少数情况下,仍有
必要以这种方式,来实现对一个地址的重复利用。通过第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状态下,其他任何套接字都不能与那个端口绑定到一起。但假若设置了该选项,
服务器便可在重新启动之后,在相同的本地接口及端口上进行监听。
meifen 2001-07-13
  • 打赏
  • 举报
回复
4
topch 2000-08-29
  • 打赏
  • 举报
回复
udp 和 tcp各有一个139端口,各不相同的,我想你可能没有注意这个问题。
sunx 2000-08-28
  • 打赏
  • 举报
回复
to: kuangxiang
呵呵, poorman 我是 sunx
我在 139上没 bind成功

to: Kevin_qing
而且理论上 端口重用技术在 139上是行不通的
因为,139会被win bind到他的所有 IP上

celxta 2000-08-28
  • 打赏
  • 举报
回复
这是个极其简单的问题:socket的默认方式的一个端口只能绑定一次,但在一个函数里(该函数我记不清了)可以设置为绑定多次,在MSDN里有详细的说明,特别是用UDP通讯时使用得更多,这并不是个怪问题。。。。。。。。。。。。。。。。。。
Kevin_qing 2000-08-28
  • 打赏
  • 举报
回复
我记得有一个参数可以使SOCKET允许多重bind

setsocketopt()参数
SO_REUSEADDR
By default, a socket cannot be bound (see bind) to a local address that is already in use. On occasion, however, it can be necessary to "re-use" an address in this way. Since every connection is uniquely identified by the combination of local and remote addresses, there is no problem with having two sockets bound to the same local address as long as the remote addresses are different. To inform the Windows Sockets provider that a bind on a socket should not be disallowed because the desired address is already in use by another socket, the application should set the SO_REUSEADDR socket option for the socket before issuing the bind. The option is interpreted only at the time of the bind. It is therefore unnecessary and harmless to set the option on a socket that is not to be bound to an existing address. Setting or resetting the option after the bind has no effect on this or any other socket

16,471

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧