From: Bill Davidsen <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 17:47:24 -0500
> David Miller wrote:
> > From: Herbert Xu <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 11:12:32 +1100
> >
> >> [INET]: Export non-blocking flags to proto connect call
> >>
> >> Previously we made connect(2) block on I
David Miller wrote:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution. This is
good in general but not desirable for non-blocking sockets.
To fix this pr
Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
> If IPSEC takes a long time to resolve, and we don't block, the
> connect() can hard fail (we will just keep dropping the outgoing SYN
> packet send attempts, eventually hitting the retry limit) in cases
> where if we did block it would not
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 15:31:53 +0100
> as far as I've understood Herbert's patch, at least TCP connect can be fixed
> so that non blocking connect() will neither fail nor block, but just use the
> first or second retransmission of the SYN packet to complete
Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:
> You keep ignoring the fact that, as Herbert and I discussed, not
> blocking for IPSEC resolution will make some connect() cases fail that
> would otherwise not fail.
>
> There are two sides to this issue, and we need to consider them
>
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 13:30:20 +0100
> IMHO this is what developers expect, and is also consistent with the
> fact that POSIX does not define O_NONBLOCK behaviour for local
> files.
You keep ignoring the fact that, as Herbert and I discussed, not
blocking fo
Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
> > Because you just will put enough RAM modules into you server when
> > setting up a scalable system.
>
> This suggestion is avoiding the important semantic issue, and
> won't lead to a real discussion of the core problem.
When writing
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 12:35:05 +0100
> Because you just will put enough RAM modules into you server when
> setting up a scalable system.
This suggestion is avoiding the important semantic issue, and
won't lead to a real discussion of the core problem.
--
To
Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller:
> And that's why this is a grey area. Why is waiting for memory
> allocation on a O_NONBLOCK socket OK but waiting for IPSEC route
> resolution is not?
Because you just will put enough RAM modules into you server when setting up a
scal
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 11:56:48 +0100
> Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
>
> > > I think the words "shall fail" and "immediately" are quite clear.
> >
> > They are, but the context in which they apply is vague.
>
> "socket is conne
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
> > I think the words "shall fail" and "immediately" are quite clear.
>
> They are, but the context in which they apply is vague.
"socket is connection-mode" => SOCK_STREAM
> I can equally generate examples where the non-blocking behavi
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 09:49:01 +0100
> "If the connection cannot be established immediately and O_NONBLOCK is set
> for
> the file descriptor for the socket, connect() shall fail and set errno to
> [EINPROGRESS], but the connection request shall not be abo
Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:
> POSIX says nothing about the semantics of route resolution.
Of course not. Applications must not care about what happens at the transport
layer.
> Non-blocking doesn't mean "cannot sleep no matter what".
... and as O_CREAT on open()
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 19:39:07 +0100
> I'd strongly suggest doing so. AFAIK, behaviour of connect() on nonblocking
> sockets is quite well defined in POSIX.
You are entitled to your opinion.
POSIX says nothing about the semantics of route resolution.
Non-b
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
>
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour of
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
> Actually, consider even a case like DNS. Let's say the timeout
> is set to 2 seconds or something and you have 3 DNS servers
> listed, on different IPSEC destinations, in your resolv.conf
>
> Each IPSEC route that isn't currently resolve
On Wed, Dec 05, 2007 at 01:55:58AM -0800, David Miller wrote:
>
> If it hits sysctl_tcp_syn_retries SYN attempts, the connect will hard
> fail.
Right. Let's just forget about this until we have a queueing system :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:39:27 +1100
> On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
> >
> > TCP has some built-in assumptions about characteristics of
> > interent links and what constitutes a timeout which is "too long"
> > and should thus re
On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
>
> TCP has some built-in assumptions about characteristics of
> interent links and what constitutes a timeout which is "too long"
> and should thus result in a full connection failure.
>
> IPSEC changes this because of IPSEC route res
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:16:07 +1100
> Right. This is definitely bad for protocols without a retransmission
> mechanism.
>
> However, is the 0 setting ever useful for TCP and in particular, TCP's
> connect(2) call? Perhaps we can just make that one always dro
On Tue, Dec 04, 2007 at 11:12:00PM -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 17:51:32 +1100
>
> > Does anybody actually need the 0 setting? What would we break if
> > the default became 1?
>
> I bet there are UDP apps out there that would break if w
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 17:51:32 +1100
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I bet there are UDP apps out there that would break if we
didn't do this.
Actually, consider even a case like DNS. Let's say the t
On Tue, Dec 04, 2007 at 10:30:23PM -0800, David Miller wrote:
>
> We made an explicit decision not to do things this way.
Thanks for pointing this out.
> Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> setting, and this is across the board. If xfrm_larval_drop is zero,
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
> [INET]: Export non-blocking flags to proto connect call
>
> Previously we made connect(2) block on IPsec SA resolution. This is
> good in general but not desirable for non-blocking sockets.
>
> To fix this properly we'd
From: Simon Arlott <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 18:53:19 +
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block
On Tue, Dec 04, 2007 at 06:53:19PM +, Simon Arlott wrote:
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block, even when usin
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
non-blocking sockets:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
27 matches
Mail list logo
