socket编程accept返回值为0，是否正常？

[ssissi821]

socket编程server端程序接收client多连接请求后，sock = accept(iSock, &sin, &len); sock的返回值为0，多数情况下看到的返回值都是正数，出现个零很是奇怪，在这里求助下有人遇到过吗？什么情况下会返回零呢？求大虾....

再看返回了错误码：Socket error 10038 - Socket operation on non-socket 即：非法的socket对象在操作 这个原因基本定位可以给accept返回值为0原因导致。

从我的程序运行来看确实出现了：too many openfiles 这个错误，即打开文件句柄过过。但是我的程序既有打开的文件也有打开的socket，用pfiles看进程打开的句柄数却并没用什么变化。程序日志跟踪打开的文件都被及时关闭，打开的socket也被关闭了。
确实有些奇怪，到底是因为什么原因导致打开文件句柄数过多呢？

[linus]

0 stdin 1 stdout 2 stderr 如果accept返回是0 1 或2 是不正常的

[justkk]

0 也是一个合法的描述符
如果你事先关闭了0这个描述符，然后再accept，那么很可能返回0

close(0);
int fd = accept(...);

[qq120848369]

[Quote=引用 2 楼 justkk 的回复:]

0 也是一个合法的描述符
如果你事先关闭了0这个描述符，然后再accept，那么很可能返回0

close(0);
int fd = accept(...);
[/Quote]

++。

[linus]

楼上2位不错，可 0 1 2 是默认给系统预留的。 如果accept使用0 作为通道， 那么其他程序会受到影响。

[StoneBBS]

"too many openfiles"----出现这种情况，"描述符打开过多"这一点应该是可以肯定的，你再仔细检查下是否有打开但没有关闭的描述符(包括文件和socket)。ls -l /proc/"进程号"/fd/基本可以查看某一进程所打开的描述符资源，对于socket可以使用netstat命令查看，如果有未关闭的socket，那么会有大量的CLOSE_WAIT状态的连接。
或者说是你的系统的最大描述符数量被改动过了(ulimit -n查看)。
希望能帮上忙，楼主解决问题时请与大家分享下原因。(:-:)

[JoeBlackzqq]

楼主这种问题我遇到过一次。
1.　楼主用的是本地socket，还是网络socket？
2.　楼主是不是用了一个未关闭的socket的？
3.　如果使用了一个未关闭的端口，试着换一个端口试下

[JoeBlackzqq]

楼主这种问题我遇到过一次。
1.　楼主用的是本地socket，还是网络socket？
2.　楼主是不是用了一个未关闭的socket的？
3.　如果使用了一个未关闭的端口，试着换一个端口试下

[ssissi821]

TO:StoneBBS
您提到的情况我都查过了，提示打开的文件句柄数过多，由于目前运行的机器为：HP-UX XTtest02 B.11.11 U 9000/800 2232404678 unlimited-user license 不支持pfiles和pstack命令，因此暂无法看到其真正打开的句柄数为文件句柄还是socket句柄。但是使用netstat 看端口的连接数一直维持在固定几个数目，因此基本排除socket未关闭的情况。
我将程序放到HP-IA运行，client端连接后即断开，连续测试三天大约连接过三万多次（client连接上server后数据收发完毕会马上关闭socket），socket的连接使用pfiles看打开的文件句柄数稳定维持在15个左右（跟进程刚开始启动时相同），pstack看进程打开线程数大约维持在5个左右（跟进程刚开始启动时相同），netstat看端口连接数一直在固定7-8，而且只有一会TIMEWAIT状态，很快就会被系统资源回收，都是正常状态。不过在HP-IA上运行也存在accept返回值为0的情况，期间看程序运行日志，数据可以正常接收，运行过程也正常，但是并未出现打开句柄说过多及“Socket operation on non-socket”错误。程序还在继续运行再观察一段时间。
不知道是不是因为HP-UX XTtest02 B.11.11 U 9000/800 2232404678 unlimited-user license 系统版本比较低导致还是由于某些核心参数设置有问题导致。
这是我做的压力测试，不断的用client连接断开server，实际情况倒是不太可能出现三天连接三万多次的情况。

[ssissi821]

[Quote=引用 2 楼 justkk 的回复:]
0 也是一个合法的描述符
如果你事先关闭了0这个描述符，然后再accept，那么很可能返回0

close(0);
int fd = accept(...);
[/Quote]

哪里可以打开0这个表述符号？程序前二天运行的时候都是正常 正数 是不会出现0的，运行到第三天一共累积了三万多连接数的时候才会打开到0.

[ssissi821]

[Quote=引用 8 楼 vince025 的回复:]
很有可能返回0的时候,你的socket文件描述符已经被异常或正常关闭了.Socket operation on non-socket,提示不是socket 文件符操作了.
[/Quote]

描述符为0的时候，可以正常进行数据的收发。

[二狗蹲坑]

很有可能返回0的时候,你的socket文件描述符已经被异常或正常关闭了.Socket operation on non-socket,提示不是socket 文件符操作了.

[jcback]

accept有返回1或2的情况不？
如果有很有可能说明你的server端进程是有守护进程的，并且你这个dameom还是位于socket和accept之间的。

[jcback]

[Quote=引用 13 楼 cicy821 的回复:]
引用 12 楼 jcback 的回复:
accept有返回1或2的情况不？
如果有很有可能说明你的server端进程是有守护进程的，并且你这个dameom还是位于socket和accept之间的。


运行了6天了，目前没有再出现"too many files"这种错误。
accept值为0程序都正常运行，没有看到1和2的情况。
我的程序不是守护进程，程序未做成守护进程。
[/Quote]
贴个代码看看，有点奇怪

[ssissi821]

[Quote=引用 12 楼 jcback 的回复:]
accept有返回1或2的情况不？
如果有很有可能说明你的server端进程是有守护进程的，并且你这个dameom还是位于socket和accept之间的。
[/Quote]

运行了6天了，目前没有再出现"too many files"这种错误。
accept值为0程序都正常运行，没有看到1和2的情况。
我的程序不是守护进程，程序未做成守护进程。

[ssissi821]

观察了几天，使用pfiles查看程序打开的文件句柄数，使用pstack查看打开的线程数，使用netstat查看端口连接数，都是正常的，程序日志也未再出现“too many open files”和“non-socket”这种异常。

[ssissi821]

[Quote=引用 15 楼 jcback 的回复:]
引用 13 楼 cicy821 的回复:
引用 12 楼 jcback 的回复:
accept有返回1或2的情况不？
如果有很有可能说明你的server端进程是有守护进程的，并且你这个dameom还是位于socket和accept之间的。


运行了6天了，目前没有再出现"too many files"这种错误。
accept值为0程序都正常运行，没有看到1和2的情况。
我的程序不……
[/Quote]

如果自己写代码我所知道的做成守护进程就是使用fork创建子进程，父进程接退出，子进程由init接管从而是此进程为守护进程，使用setsid设置用户组及用户权限。如果是守护进程直接执行kill 是无法将进程杀掉的，我的程序kill 就直接杀掉。
我的程序中没有做子进程，只有线程。
代码太多了，贴出来不太方便。socket通信就是最基本的socket通信。

[reactiveF]

socket标准规定成功后accept返回非负描述符即可,错误则返回-1;

只要非负就是正常的,有什么问题吗?