Hello!
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 40
> fcntl(40, F_GETFL) = 0x2 (flags O_RDWR)
> fcntl(40, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> setsockopt(40, SOL_SOCKET, SO_LINGER, [1], 8) = 0
> connect(40, {sin_family=AF_INET, sin_port=htons(2030),
> sin_addr=inet_addr("127.0.0.1")}}, 16) = -1 EINPROGRESS (Operation now in
> progress)
> select(41, NULL, [40], NULL, {180, 0}) = 1 (out [40], left {180, 0})
> getsockopt(40, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> select(41, [40], NULL, NULL, {180, 0}) = 1 (in [40], left {175, 550000})
> ioctl(4, FIONREAD, [0]) = 0
> select(41, [40], NULL, NULL, {180, 0}) = 1 (in [40], left {180, 0})
> recv(4, 0x806aa28, 1, 0x4000) = -1 EAGAIN (Resource temporarily
> unavailable)
>
> As far as you can see select say that socket is writable after connect. This
> mean that connection is completed... But later before read we do select on
> read, and get OK. But recv fails with EAGAIN. This situation is repeated
> constantly. The program stucks in the loop trying to connect, but fails.
>
> Any ideas what can this be?
F.e. this can be recv() on wrong descriptor, which is seen from strace above.
:-)
BTW why do you use funny getsockopt instead of canonical non-blocking connect?
Does standard way have some drawbacks or it is just legal desire
to "think different"? :-) The question is very interesting: it is big puzzle
for me what does motivate people to invent such strange combinations
of selct/ioctl/getsockopt (f.e. qmail did another bizarre thing:
getpeername() in the place where you use getsockopt(), so strace
looks like a shizophrenic dialogue to itself: "I am Bob!", ...
"Am I really Bob?" ... "Am I still Bob?" and so on for 3 minutes. :-))
And the second note: the whole sequence is equivalent to plain blocking
connect, only with lots of overhead. In all the OSes standard connect timeout
is of order 2-4 minutes. Yes, Linux-2.2 is unfortunate exception (13 minutes),
but the difference is purely quantitative yet and for any installation
this should be changed to smaller value via sysctl in any case.
Seems, no reasons to worry.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:36 EST