fconfigure

[vit...@gmail.com]

Is this a bug/feature?:

I created a little communication application (being on Windows at the
time). There was a part in the code where I was doing [fconfigure
sock] to get the sock configuration for debugging purposes. Everything
was working just fine. Then I switched to Linux and my connections was
just crawling (up to 3 seconds to respond to a request). I spent some
time debugging the code, finally getting to the [fconfigure sock]
code. I disabled it and my application started working as fast as it
was on Windows.

Why is it taking so long to get a response from [fconfigure sock] on
Linux?

[Darren New]

vit...@gmail.com wrote:
> Why is it taking so long to get a response from [fconfigure sock] on
> Linux?

I'm guessing maybe a reverse-DNS slowness?

--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."

[Alexandre Ferrieux]

On Apr 9, 5:11 am, vit...@gmail.com wrote:
>
> Why is it taking so long to get a response from [fconfigure sock] on
> Linux?

I agree with Darren, it looks like a reverse DNS delay. The fact that
it's on Linux is an accident, it's rather a difference in the network
environment.

Now what exactly are you looking for in [fconfigure]'s output ?
If it's -peername (on a server socket) *and* you don't insist on
getting DNS names, then please notice that the [socket -server]
callback already provides the IP and port of the remote client, in
numeric form (no reverse DNS, no delay). If you're after -sockname (on
a client socket), the you can say [fconfigure -sockname]. It will
still try a reverse DNS on the local host's name, but hopefully this
one is resolved locally and should be fast.

-Alex

[vit...@gmail.com]

On Apr 9, 1:44 am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:

Thanks Alex,

I was testing the settings of the connections to see if my custom
fconfigure settings change after fileevent takes over and what the new
settings are. I didn't really need that code for normal operations
just for debugging.

[Alexandre Ferrieux]

A fileevent is just a callback, and does nothing by itself on the
channel's setting. If it changes, it is through the action of explicit
client code.

-Alex