[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Hanging Networks V2
From:       Thiago Macieira <thiagom () mail ! com>
Date:       2001-01-20 0:06:12
[Download RAW message or body]

Ingo Krabbe wrote:
> The only possibility to work around this condition is, how far I can see,
to
> timeout the ::connect system call via an ::alarm signal.

When KSocket is used, the connection is placed in non-blocking mode
and a select() call is done, with timeouts. KSocket defaults to 30
seconds timeouts.

> Please discuss the problem with me, if there are any problems in such a
> solution. The advantage of this solution is clearly that there are quite
view
> pieces of code which have to be timed out. There is exactly one connect
call
> in kdelibs-, and one call in kdesupport-module. I don't know yet if there
are
> any other calls to connect.

Actually, the only calls to ::connect should be in the socket classes.
That way, we can make sure things work as we want. As I said, KSocket
checks for timeouts.

The other ::connect calls might not. The http ioslave has two
different time outs (proxied and non-proxied connects), while kio_ftp
has no such thing.

However, before every connection is attempted, name resolution is
attempted. It's far more important to fix those than the timeouts.

> I will try to write a intelligent connect which times out and retries as
> configured by the system (like the resolver). I will send this function to
> you after the next weekend I think ...

I'd like to have a look, if possible. But it would be better if you
did that upon my work. We wouldn't be wasting efforts.
http://loki.nw.com.br/development/kde-ipv6-20010118.diff

--
  Thiago Macieira - UFOT Registry number: 1001
 thiagom@mail.com talha@geocities.com
   ICQ UIN: 1967141  PGP: 0x8F2978D5 and 0xEA9037A5
     Registered Linux user #65028

142/379. My mom says two heads are better than one. Isn't that the
Borg philosophy, too? -- Naomi Wildman, "Bliss"

[prev in list] [next in list] [prev in thread] [next in thread]