In a message written on Thu, Mar 01, 2012 at 05:02:30PM -0800, Owen DeLong
wrote:
Then push for better written abstraction libraries. There's no need to
break the current functionality of the underlying system calls and
libc functions which would be needed by any such library anyway.
Agree in
On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong o...@delong.com wrote:
On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
You know, when I wrote 'socket=connect(www.google.com,80,TCP);' I
stopped and thought to myself, I wonder if I should change that to
'connectbyname' instead just to make it
On Mar 2, 2012, at 10:12 AM, William Herrin wrote:
On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong o...@delong.com wrote:
On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
You know, when I wrote 'socket=connect(www.google.com,80,TCP);' I
stopped and thought to myself, I wonder if I should change
GAI/GNI do not return TTL values, but this should not be a problem.
If they were to return anything, it should not be a TTL, but a time()
value, after which the result may no longer be used.
One way to achieve that would be for GAI to return an opaque structure
that contained the IP and
On Feb 29, 2012, at 10:15 PM, Jimmy Hess wrote:
On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison
matt.addi...@lists.evilgeni.us wrote:
gai/gni do not return TTL values on any platforms I'm aware of, the
only way to get TTL currently is to use a non standard resolver (e.g.
lwres). The issue is
On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco jgr...@ns.sol.net wrote:
In the specific case of TTL, the problem is made much worse due to the
way most client code has hidden this data from developers, so that many
developers don't even have any idea that such a thing exists.
I'm not sure
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong o...@delong.com wrote:
The simpler approach and perfectly viable without mucking
up what is already implemented and working:
Don't keep returns from GAI/GNI around longer than it takes
to cycle through your connect() loop immediately after the
On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco jgr...@ns.sol.net wrote:
If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't *work*.
That's not true. If it sprayed water in the manner it was designed to,
then it worked.
On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco jgr...@ns.sol.net wrote:
If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't *work*.
That's not true. =A0If it sprayed water in the manner it was designed to,
then it
On 03/01/2012 06:26 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLongo...@delong.com wrote:
The simpler approach and perfectly viable without mucking
up what is already implemented and working:
Don't keep returns from GAI/GNI around longer than it takes
to cycle through
On 03/01/2012 06:26 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLongo...@delong.com wrote:
The simpler approach and perfectly viable without mucking
up what is already implemented and working:
Don't keep returns from GAI/GNI around longer than it takes
to cycle
On 03/01/2012 07:22 AM, Joe Greco wrote:
It's deeper than just that, though. The whole paradigm is messy, from
the point of view of someone who just wants to get stuff done. The
examples are (almost?) all fatally flawed. The code that actually gets
at least some of it right ends up being too
On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomas m...@mtcc.com wrote:
On 03/01/2012 06:26 AM, William Herrin wrote:
The even simpler approach: create an AF_NAME with a sockaddr struct
that contains a hostname instead of an IPvX address. Then let
connect() figure out the details of caching,
On 03/01/2012 08:57 AM, David Conrad wrote:
Moving it across the kernel boundary solves nothing
Actually, it does. Right now, applications effectively cache the address in
their data space, requiring the application developer to go to quite a bit of
work to deal with the address changing
On 03/01/2012 08:58 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomasm...@mtcc.com wrote:
On 03/01/2012 06:26 AM, William Herrin wrote:
The even simpler approach: create an AF_NAME with a sockaddr struct
that contains a hostname instead of an IPvX address. Then let
On Thu, Mar 1, 2012 at 1:32 PM, Michael Thomas m...@mtcc.com wrote:
On 03/01/2012 08:58 AM, William Herrin wrote:
libc != kernel. I want to move the action into the standard libraries
where [resolve and connect] can be done once and done well.
A little kernel action on top
to parallelize
It's deeper than just that, though. The whole paradigm is messy, from
the point of view of someone who just wants to get stuff done. The
examples are (almost?) all fatally flawed. The code that actually gets
at least some of it right ends up being too complex and too hard for
people to
On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong o...@delong.com wrote:
I think that the modern set of getaddrinfo and connect is actually not that
complicated:
Owen,
If took you 50 lines of code to do
'socket=connect(www.google.com,80,TCP);' and you still managed to
produce a version which, due
In message CAP-guGXLpzai4LrxyJcNn06yQ1jAEu4QeRpVzGRah=+ogly...@mail.gmail.com
, William Herrin writes:
On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong o...@delong.com wrote:
I think that the modern set of getaddrinfo and connect is actually not th=
at complicated:
Owen,
If took you 50 lines
William,
I could have done it in a lot less lines of code, but, it would have been much
less readable.
Not blocking on the connect() call is a little more complex, but, not terribly
so. It does, however, again, make the code quite a bit less readable.
There are libraries available that
On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong o...@delong.com wrote:
You don't have to reinvent what I've done. Neither does every
or any other application programmer.
You are welcome to use any of the many connection
abstraction libraries that are available in open source.
I suggest you make a
On Thu, Mar 01, 2012 at 05:57:11PM -0500, William Herrin wrote:
Which is what everybody basically does. And when it works during the
decidedly non-rigorous testing, they move on to the next problem...
with code that doesn't perform well in the corner cases. Such as when
a host has just been
On Mar 1, 2012, at 2:57 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong o...@delong.com wrote:
You don't have to reinvent what I've done. Neither does every
or any other application programmer.
You are welcome to use any of the many connection
abstraction libraries
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong o...@delong.com wrote:
There's no need to
break the current functionality of the underlying system calls and
libc functions which would be needed by any such library anyway.
Owen,
Point to one sentence written by anybody in this entire thread in
On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong o...@delong.com wrote:
There's no need to
break the current functionality of the underlying system calls and
libc functions which would be needed by any such library anyway.
Owen,
Point to one
On Mar 1, 2012, at 17:10, William Herrin b...@herrin.us wrote:
If took you 50 lines of code to do
'socket=connect(www.google.com,80,TCP);' and you still managed to
produce a version which, due to the timeout on dead addresses, is
worthless for any kind of interactive program like a web
On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong o...@delong.com wrote:
On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong o...@delong.com wrote:
There's no need to
break the current functionality of the underlying system calls and
libc functions which
On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong o...@delong.com wrote:
On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong o...@delong.com wrote:
There's no need to
break the current functionality of the
In message
CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com,
William Herrin writes:
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote:
DNS TTL works. =A0Applications that don't honour it arn't a indication th=
at
it doesn't work.
Mark,
If
On Feb 29, 2012, at 6:18 AM, William Herrin wrote:
On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco jgr...@ns.sol.net wrote:
In message
CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com,
William Herrin writes:
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote:
On 2/29/2012 1:38 PM, Robert Hajime Lanning wrote:
On 02/29/12 10:01, Owen DeLong wrote:
Further, DNS performance issues in the past have led developers of
such applications to take matters into their own hands to try and
improve the performance/behavior of their application in spite of
DNS.
On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco jgr...@ns.sol.net wrote:
In message
CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com,
?William Herrin writes:
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote:
DNS TTL works. =A0Applications that don't
On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco jgr...@ns.sol.net wrote:
In the specific case of TTL, the problem is made much worse due to the
way most client code has hidden this data from developers, so that many
developers don't even have any idea that such a thing exists.
I'm not sure how to
On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison
matt.addi...@lists.evilgeni.us wrote:
gai/gni do not return TTL values on any platforms I'm aware of, the
only way to get TTL currently is to use a non standard resolver (e.g.
lwres). The issue is application developers not calling gai every time
On Feb 27, 2012, at 9:45 PM, Mark Andrews wrote:
getaddrinfo was designed to be extensible as was struct
addrinfo. Part of the problem with TTL is not data sources
used by getaddrinfo have TTL information. Additionally for
many uses you want to reconnect to the
On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews ma...@isc.org wrote:
getaddrinfo was designed to be extensible as was struct
addrinfo. Part of the problem with TTL is not [all] data sources
used by getaddrinfo have TTL information.
Hi Mark,
By the time getaddrinfo
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote:
DNS TTL works. Applications that don't honour it arn't a indication that
it doesn't work.
Mark,
If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't
In message CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com,
William Herrin writes:
On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote:
DNS TTL works. =A0Applications that don't honour it arn't a indication th=
at
it doesn't work.
Mark,
If three
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application does a
gethostbyname once when it starts, grabs the first IP address in the
list and retains it indefinitely. The gethostbyname function doesn't
even pass the TTL to the application. Ntpd
On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
On Mon, Feb 27, 2012 at 3:43 PM, david raistrick dr...@icantclick.org wrote:
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application does a
gethostbyname once when it starts, grabs the first
On Mon, Feb 27, 2012 at 7:07 PM, Owen DeLong o...@delong.com wrote:
On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
Meh. What should be fixed is that connect() should receive a name
instead of an IP address. Having an application deal directly with the
IP address should be the exception
On Mon, Feb 27, 2012 at 4:59 PM, William Herrin b...@herrin.us wrote:
Yes, well, that's why we're still using a layer 4 protocol (TCP) that
can't dynamically rebind to the protocol level below (IP).
This is somewhat irritating, but on the scale of 0 (all is well) to 10
(you want me to do
In message CAP-guGVA4eHv0K=U=x2b-wpydy2rq7ze1di2ahc+dma_huy...@mail.gmail.com,
William Herrin writes:
On Mon, Feb 27, 2012 at 3:43 PM, david raistrick dr...@icantclick.org wro=
te:
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The application
On Feb 27, 2012, at 19:10, Owen DeLong o...@delong.com wrote:
On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
On Mon, Feb 27, 2012 at 3:43 PM, david raistrick dr...@icantclick.org
wrote:
On Mon, 27 Feb 2012, William Herrin wrote:
In some cases this is because of carelessness: The
getaddrinfo was designed to be extensible as was struct
addrinfo. Part of the problem with TTL is not data sources
used by getaddrinfo have TTL information. Additionally for
many uses you want to reconnect to the same server rather
than the same name.
45 matches
Mail list logo
