Menu
▾
▴
pidgin-devel
|
From: Mark D. <ma...@ki...> - 2006-08-21 05:12:34
|
People on gaim-commits may already be familiar with this... Previously there were three different methods used to resolve IP addresses in Gaim. We chose a different method at compile time based on your OS. They all used either getaddrinfo() or gethostbyname(). The differences lie in how they achieved non-blockingness. In Unix-land we forked a process to do the lookup, then waited for the process to send us the results. In Windows-land we spawned a thread and did the lookup there. In anything else we used a very bland implementation which blocked the UI. It seemed dumb to me to have three implementations of the same thing, so I got rid of the Unix one and the other one and now we're using only the thread-based lookup. Ethan didn't like this (I think because it uses threads?), but his reasons didn't really convince me. How do other people feel? It's pretty easy to revert my change and go back to having lots of crazy and confusing code, if people want. -Mark |
|
From: Gary K. <gr...@re...> - 2006-08-21 05:26:58
|
Mark Doliner wrote: > People on gaim-commits may already be familiar with this... > > Previously there were three different methods used to resolve IP addresses in > Gaim. We chose a different method at compile time based on your OS. They all > used either getaddrinfo() or gethostbyname(). The differences lie in how they > achieved non-blockingness. > > In Unix-land we forked a process to do the lookup, then waited for the process > to send us the results. In Windows-land we spawned a thread and did the > lookup there. In anything else we used a very bland implementation which > blocked the UI. > > It seemed dumb to me to have three implementations of the same thing, so I got > rid of the Unix one and the other one and now we're using only the > thread-based lookup. > > Ethan didn't like this (I think because it uses threads?), but his reasons > didn't really convince me. How do other people feel? It's pretty easy to > revert my change and go back to having lots of crazy and confusing code, if > people want. > > -Mark Why do we need a thread? Can't we use a watcher or listener in our main loop? -- Gary Kramlich <gr...@re...> |
|
From: Mark D. <ma...@ki...> - 2006-08-21 05:29:17
|
On Mon, 21 Aug 2006 00:26:52 -0500, Gary Kramlich wrote > Mark Doliner wrote: > > People on gaim-commits may already be familiar with this... > > > > Previously there were three different methods used to resolve IP addresses in > > Gaim. We chose a different method at compile time based on your OS. They all > > used either getaddrinfo() or gethostbyname(). The differences lie in how they > > achieved non-blockingness. > > > > In Unix-land we forked a process to do the lookup, then waited for the process > > to send us the results. In Windows-land we spawned a thread and did the > > lookup there. In anything else we used a very bland implementation which > > blocked the UI. > > > > It seemed dumb to me to have three implementations of the same thing, so I got > > rid of the Unix one and the other one and now we're using only the > > thread-based lookup. > > > > Ethan didn't like this (I think because it uses threads?), but his reasons > > didn't really convince me. How do other people feel? It's pretty easy to > > revert my change and go back to having lots of crazy and confusing code, if > > people want. > > > > -Mark > > Why do we need a thread? Can't we use a watcher or listener in our main > loop? We use either getaddrinfo() or gethostbyname(), and they are both blocking. -Mark |
|
From: Gary K. <gr...@re...> - 2006-08-21 05:35:15
|
Mark Doliner wrote:
<snip>
>> Why do we need a thread? Can't we use a watcher or listener in our ma=
in
>> loop?
>=20
> We use either getaddrinfo() or gethostbyname(), and they are both block=
ing.
>=20
> -Mark
I haven't looked at the changes, but I hope, now that it's threaded that
we're using gethostbyname_r or gethostbyname2_r, since the man page says:
The functions gethostbyname() and gethostbyaddr() may return
pointers to static data, which
may be overwritten by later calls. Copying the struct hostent
does not suffice, since it con=E2=80=90
tains pointers; a deep copy is required.
This of course, is implementation specific.
--=20
Gary Kramlich <gr...@re...>
|
|
From: Colin B. <ti...@la...> - 2006-08-21 05:35:26
|
On Aug 20, 2006, at 7:16 PM, Mark Doliner wrote: > Ethan didn't like this (I think because it uses threads?), but his > reasons > didn't really convince me. How do other people feel? It's pretty > easy to > revert my change and go back to having lots of crazy and confusing > code, if > people want. What exactly is his problem with using a thread? Threads are great; they only start to get hairy when you're passing data back and forth from one threadspace to another. But this type of task -- performing a blocking call without blocking the UI -- is the canonical, text book case for threads, and generally results in simple, easy to understand code -- assuming the library you're using is sane, of course ;) -Colin |
|
From: Mark D. <ma...@ki...> - 2006-08-21 05:37:58
|
On Mon, 21 Aug 2006 00:35:11 -0500, Gary Kramlich wrote > Mark Doliner wrote: > > <snip> > > >> Why do we need a thread? Can't we use a watcher or listener in our main > >> loop? > > > > We use either getaddrinfo() or gethostbyname(), and they are both blocking. > > > > -Mark > > I haven't looked at the changes, but I hope, now that it's threaded that > we're using gethostbyname_r or gethostbyname2_r, since the man page says: > > The functions gethostbyname() and gethostbyaddr() may return > pointers to static data, which > may be overwritten by later calls. Copying the struct hostent > does not suffice, since it con‐ > tains pointers; a deep copy is required. > > This of course, is implementation specific. I'm working on that right now, actually. Unfortunately gethostbyname_r() is a GNU extension, which means we shouldn't use it. Which means that we'll have to use gethostbyname() in a blocking manner on systems without addrinfo. Fortunately this should be a relatively small number of systems. -Mark |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 11:44:33
|
Mark Doliner spake unto us the following wisdom: > On Mon, 21 Aug 2006 00:35:11 -0500, Gary Kramlich wrote > > Mark Doliner wrote: > > > We use either getaddrinfo() or gethostbyname(), and they are both blo= cking. > > > > I haven't looked at the changes, but I hope, now that it's threaded that > > we're using gethostbyname_r or gethostbyname2_r, since the man page say= s: > >=20 > > The functions gethostbyname() and gethostbyaddr() may return > > pointers to static data, which may be overwritten by later > > calls. Copying the struct hostent does not suffice, since it > > con=1B$B!>=1B(B tains pointers; a deep copy is required. > >=20 > > This of course, is implementation specific. >=20 > I'm working on that right now, actually. Unfortunately > gethostbyname_r() is a GNU extension, which means we shouldn't use it. > Which means that we'll have to use gethostbyname() in a blocking > manner on systems without addrinfo. Fortunately this should be a > relatively small number of systems. This is what I mentioned on IRC the other day, with respect to using reentrant lookups where available in case some other library chooses to do a lookup. (Viz. the recent gnome-vfs deciding to go threaded, for example.) gethostbyname_r is most certainly *not* GNU-specific, it exists on several systems that I am aware of. Perhaps the GNU implementation diverges in some way with, e.g., the Solaris version, but I expect we can assume they are the same. I'll peruse the man pages later and find out. Regression to blocking lookups on platforms without gethostbyname_r is a very good argument for returning to cooperating processes, if you ask me. :-P Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Daniel A. <dan...@gm...> - 2006-08-21 14:37:32
|
> > Mark Doliner wrote: > I'm working on that right now, actually. Unfortunately gethostbyname_r() is a > GNU extension, which means we shouldn't use it. Which means that we'll have > to use gethostbyname() in a blocking manner on systems without addrinfo. > Fortunately this should be a relatively small number of systems To further complicate things, gethostbyname() is thread-safe on win32, and getaddrinfo() is not available before Windows XP. (Technically, getaddrinfo() has be present since win95, but it was a inline macro until winXP - the mingw headers don't have the macro, so effectively we can't use it). -D |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 11:39:36
|
Colin Barrett spake unto us the following wisdom: > On Aug 20, 2006, at 7:16 PM, Mark Doliner wrote: > > Ethan didn't like this (I think because it uses threads?), but his=20 > > reasons didn't really convince me. How do other people feel? It's > > pretty easy to revert my change and go back to having lots of crazy > > and confusing code, if people want. >=20 > What exactly is his problem with using a thread? Threads are great; =20 > they only start to get hairy when you're passing data back and forth =20 > from one threadspace to another. But this type of task -- performing a = =20 > blocking call without blocking the UI -- is the canonical, text book =20 > case for threads, and generally results in simple, easy to understand =20 > code -- assuming the library you're using is sane, of course ;) Actually, this is the textbook case where people who don't understand threads *think* it's a textbook case for threads. In fact, the _only_ time that threads make sense is when you have a huge amount of shared data that both sides of the divide need to be able to access rapidly. In cases such as this one, where the information to be passed back and forth is very small, cooperating processes are a huge win -- because memory faults in one process are isolated from the other. With the thread scenario, a memory corruption bug in the lookup thread can stomp data in the main process; in the cooperating process scenario, it cannot. In fact, with a careful interface, a complete failure in the lookup process affects only *one* thing in the main procees; a single lookup fails. Windows programmers often think that this sort of thing absolutely requires threads, but that is due to severe limitations in the Windows process model, IPC, and process creation performance. On platforms which have a cheap fork() and robust IPC, multiple processes are a clear win. In this case, Mark's concern is motivated by total code complexity; I disagree that the complexity of having two implementations (both of which are bound to be maintained, as Unix requires one and Windows requires the other, so it's not like there is a real potential for long-term rot or divergence) is too painful. The third, non-forking non-threaded implementation can simply be removed. If there is a platform on which neither fork() nor pthread_create() is supported, a lot of other things Gaim requires probably are not supported either. I remain in opposition to this change, on the principle that it is bad design, but I am not going to get in a long debate over it; if no one else understands or cares that it's bad design, then let it be bad design. In this instance, the complexity of the code in the subservient thread can be kept under control such that the usual concerns about threading behavior can be minimized. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Mark D. <ma...@ki...> - 2006-08-21 17:42:42
|
On Mon, 21 Aug 2006 07:39:32 -0400, Ethan Blanton wrote > Colin Barrett spake unto us the following wisdom: > > On Aug 20, 2006, at 7:16 PM, Mark Doliner wrote: > > > Ethan didn't like this (I think because it uses threads?), but his > > > reasons didn't really convince me. How do other people feel? It's > > > pretty easy to revert my change and go back to having lots of crazy > > > and confusing code, if people want. > > > > What exactly is his problem with using a thread? Threads are great; > > they only start to get hairy when you're passing data back and forth > > from one threadspace to another. But this type of task -- performing a > > blocking call without blocking the UI -- is the canonical, text book > > case for threads, and generally results in simple, easy to understand > > code -- assuming the library you're using is sane, of course ;) > > Actually, this is the textbook case where people who don't understand > threads *think* it's a textbook case for threads. In fact, the > _only_ time that threads make sense is when you have a huge amount > of shared data that both sides of the divide need to be able to > access rapidly. In cases such as this one, where the information to > be passed back and forth is very small, cooperating processes are a > huge win -- because memory faults in one process are isolated from > the other. With the thread scenario, a memory corruption bug in the > lookup thread can stomp data in the main process; in the cooperating > process scenario, it cannot. In fact, with a careful interface, a > complete failure in the lookup process affects only *one* thing in > the main procees; a single lookup fails. Memory faults... like, hardware problems or OS bugs? I kinda feel like we shouldn't really worry about designing Gaim so that it doesn't crash if there are memory faults. Besides, our memory use in the lookup process is orders of magnitude less than our memory use in the rest of Gaim. If we have a memory fault somewhere it's pretty unlikely that it's going to be in the DNS process. Having blocking DNS requests on (!Linux and !Windows) does concern me, though. Hopefully gethostbyname_r() will be usable on non-gnu systems. -Mark |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 19:40:32
|
Mark Doliner spake unto us the following wisdom: > Memory faults... like, hardware problems or OS bugs? I kinda feel like we > shouldn't really worry about designing Gaim so that it doesn't crash if t= here > are memory faults. Besides, our memory use in the lookup process is orde= rs of > magnitude less than our memory use in the rest of Gaim. If we have a mem= ory > fault somewhere it's pretty unlikely that it's going to be in the DNS pro= cess. Memory faults like stack/heap corruption, SIGSEGV, SIGBUS. Obviously I'm not concerned about making Gaim survivable w.r.t. hardware failure. It's just an IM program. ;-) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Richard L. <rl...@wi...> - 2006-08-21 17:50:58
|
On Mon, 2006-08-21 at 12:46 -0500, Mark Doliner wrote: > Memory faults... like, hardware problems or OS bugs? I believe he means page faults... I'm I'm understanding this correctly, the argument is: If Gaim had to page something in for something other than the DNS lookup, the DNS lookup code could continue to run if it was in a separate process. Richard |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 19:41:32
|
Richard Laager spake unto us the following wisdom: > On Mon, 2006-08-21 at 12:46 -0500, Mark Doliner wrote: > > Memory faults... like, hardware problems or OS bugs? >=20 > I believe he means page faults... >=20 > I'm I'm understanding this correctly, the argument is: If Gaim had to > page something in for something other than the DNS lookup, the DNS > lookup code could continue to run if it was in a separate process. This is really not relevant. Besides, if there is enough memory pressure to page out an active portion of one process, it's just as likely that the active portion of another process could be paged out. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Greg H. <gh...@MI...> - 2006-08-21 18:04:46
|
On Aug 21, 2006, at 7:39 AM, Ethan Blanton wrote:
> Actually, this is the textbook case where people who don't understand
> threads *think* it's a textbook case for threads. In fact, the _only_
> time that threads make sense is when you have a huge amount of shared
> data that both sides of the divide need to be able to access rapidly.
> In cases such as this one, where the information to be passed back and
> forth is very small, cooperating processes are a huge win -- because
> memory faults in one process are isolated from the other. With the
> thread scenario, a memory corruption bug in the lookup thread can
> stomp data in the main process; in the cooperating process scenario,
> it cannot. In fact, with a careful interface, a complete failure in
> the lookup process affects only *one* thing in the main procees; a
> single lookup fails.
This argument isn't terribly compelling; it amounts to "good design
uses address space separation when it can, and whenever you need a
separate thread of control, that's an opportunity." But Gaim and
most other large multi-function programs abandoned that design
principle long ago; if it aimed for maximal address space separation,
plugins would be processes, rather than dynamically loaded libraries,
the UI would be in a separate address space from the main control
logic, etc..
If Gaim had a non-blocking way of using hostname resolution (e.g. if
functionality like ares or dyndns were built into operating systems),
no one would think twice about building the lookup functionality into
the same address space as the rest of the code. All we're doing is
making one system library invocation; that doesn't rise to the level
of needing address space separation. It just isn't a "huge win".
A more compelling reason to avoid threads on Unix is that it's more
demanding on the debugger. When I'm using gdb on a program which
makes use of threads, my life is intrinsically a lot more complicated
("you want a backtrace of which thread?") and, more importantly, I
run into a host of gdb or OS bugs which frequently render the
debugger useless and send me back to printf debugging. This isn't
prejudice from years ago; I ran into this situation on a RHEL 4
machine just yesterday working on openssh, and my work on it wasn't
even vaguely related to the code areas it was forking threads for.
The situation on other Unix-type operating systems like Solaris is
even worse, in my experience.
|
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 19:39:13
|
[below]
Greg Hudson spake unto us the following wisdom:
> On Aug 21, 2006, at 7:39 AM, Ethan Blanton wrote:
> >Actually, this is the textbook case where people who don't understand
> >threads *think* it's a textbook case for threads. In fact, the _only_
> >time that threads make sense is when you have a huge amount of shared
> >data that both sides of the divide need to be able to access rapidly.
> >In cases such as this one, where the information to be passed back and
> >forth is very small, cooperating processes are a huge win -- because
> >memory faults in one process are isolated from the other. With the
> >thread scenario, a memory corruption bug in the lookup thread can
> >stomp data in the main process; in the cooperating process scenario,
> >it cannot. In fact, with a careful interface, a complete failure in
> >the lookup process affects only *one* thing in the main procees; a
> >single lookup fails.
>=20
> This argument isn't terribly compelling; it amounts to "good design =20
> uses address space separation when it can, and whenever you need a =20
> separate thread of control, that's an opportunity." But Gaim and =20
> most other large multi-function programs abandoned that design =20
> principle long ago; if it aimed for maximal address space separation, =20
> plugins would be processes, rather than dynamically loaded libraries, =20
> the UI would be in a separate address space from the main control =20
> logic, etc..
I disagree, it is *very* compelling. The argument of "we didn't write
a completely moduler message-passing program, so don't use message
passing at all" just doesn't float. Interestingly, the *original*
core/ui split design was precisely this -- a core process
communicating with a UI process via Unix sockets. Additionally, both
the Tcl and D-Bus APIs allow for extra-process plugins, and I
encourage their use.
> If Gaim had a non-blocking way of using hostname resolution (e.g. if =20
> functionality like ares or dyndns were built into operating systems), =20
> no one would think twice about building the lookup functionality into =20
> the same address space as the rest of the code. All we're doing is =20
> making one system library invocation; that doesn't rise to the level =20
> of needing address space separation. It just isn't a "huge win".
I agree -- if we had an asynchronous lookup code, I would put it
directly into the main process. However, I think you're
underestimating the undesirability of threads.
> A more compelling reason to avoid threads on Unix is that it's more =20
> demanding on the debugger. When I'm using gdb on a program which =20
> makes use of threads, my life is intrinsically a lot more complicated =20
> ("you want a backtrace of which thread?") and, more importantly, I =20
> run into a host of gdb or OS bugs which frequently render the =20
> debugger useless and send me back to printf debugging. This isn't =20
> prejudice from years ago; I ran into this situation on a RHEL 4 =20
> machine just yesterday working on openssh, and my work on it wasn't =20
> even vaguely related to the code areas it was forking threads for. =20
> The situation on other Unix-type operating systems like Solaris is =20
> even worse, in my experience.
This is just icing on the cake made from reasons threads suck, really.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
|
|
From: Sean E. <sea...@gm...> - 2006-08-21 18:45:23
|
On 8/21/06, Ethan Blanton <ebl...@cs...> wrote: > I remain in opposition to this change, on the principle that it is bad > design, but I am not going to get in a long debate over it; if no one > else understands or cares that it's bad design, then let it be bad > design. In this instance, the complexity of the code in the > subservient thread can be kept under control such that the usual > concerns about threading behavior can be minimized. Probably no surprise to anyone, I agree with Ethan. Considering the DNS lookup code is already written, tested, and stable, I see no compelling reason to screw around with it too much now, but I'm not too particularly concerned. Really, we should just extend our SRV lookup code to handle A records asynchronously. -s. |
|
From: Mark D. <ma...@ki...> - 2006-08-22 06:18:37
|
On Mon, 21 Aug 2006 11:45:22 -0700, Sean Egan wrote > On 8/21/06, Ethan Blanton <ebl...@cs...> wrote: > > I remain in opposition to this change, on the principle that it is bad > > design, but I am not going to get in a long debate over it; if no one > > else understands or cares that it's bad design, then let it be bad > > design. In this instance, the complexity of the code in the > > subservient thread can be kept under control such that the usual > > concerns about threading behavior can be minimized. > > Probably no surprise to anyone, I agree with Ethan. > > Considering the DNS lookup code is already written, tested, and > stable, I see no compelling reason to screw around with it too much > now, but I'm not too particularly concerned. > > Really, we should just extend our SRV lookup code to handle A records > asynchronously. > > -s. I reverted those changes in SVN, so we're back to having three large chunks of code that do the same thing. -Mark |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 19:43:54
|
Sean Egan spake unto us the following wisdom: > Considering the DNS lookup code is already written, tested, and > stable, I see no compelling reason to screw around with it too much > now, but I'm not too particularly concerned. >=20 > Really, we should just extend our SRV lookup code to handle A records > asynchronously. This has been discussed before, and there is a good reason we have not. Namely, gethostbyname() [getaddrbyname(), whatever] does _not_ necessarily just do a DNS lookup. Hostnames can be served from /etc/hosts, from NIS, from NetInfo, from LDAP, from WINS, from [...]. We obviously aren't going to write mechanisms for all of these things, so it's best to leave it up to libc. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Sean E. <sea...@gm...> - 2006-08-21 19:57:46
|
On 8/21/06, Ethan Blanton <ebl...@cs...> wrote: > > Really, we should just extend our SRV lookup code to handle A records > > asynchronously. > This has been discussed before, and there is a good reason we have > not. I hadn't meant this seriously. :) -s. |
|
From: <tho...@gm...> - 2006-08-21 20:02:16
|
If you would code http://Cspace.in into Gaim it would be possible to get from each buddy the IP adress which is actual, as the RSA-Key is found in the Kademlia base, You only need to stick the RSA-key in the gaim client to any other Chatname of any other protocol. With this method you can look up in each session the actul IP Adress. And you could do even more, the file transfer mechanism is for each protocol differen, you could, if in the client the Chatname of each protocol is stuck to the Cspace-Rsa-Key, use the Cspace protocol to have UNIQUE filetransfer to each GAIM users. Does this solution solve your problem to get the IP adresses of the users? While AOL and MSN .. etc do not allow directly the IP adress pining of a buddy - jabber i do not know - Cspace can provide them... How is Libc doing it ? Kind regards... -------- Original-Nachricht -------- Datum: Mon, 21 Aug 2006 15:43:52 -0400 Von: Ethan Blanton <ebl...@cs...> An: gai...@li... Betreff: Re: [Gaim-devel] Resolving IP addresses in Gaim > Sean Egan spake unto us the following wisdom: > > Considering the DNS lookup code is already written, tested, and > > stable, I see no compelling reason to screw around with it too much > > now, but I'm not too particularly concerned. > > > > Really, we should just extend our SRV lookup code to handle A records > > asynchronously. > > This has been discussed before, and there is a good reason we have > not. Namely, gethostbyname() [getaddrbyname(), whatever] does _not_ > necessarily just do a DNS lookup. Hostnames can be served from > /etc/hosts, from NIS, from NetInfo, from LDAP, from WINS, from [...]. > We obviously aren't going to write mechanisms for all of these things, > so it's best to leave it up to libc. > > Ethan > > -- > The laws that forbid the carrying of arms are laws [that have no remedy > for evils]. They disarm only those who are neither inclined nor > determined to commit crimes. > -- Cesare Beccaria, "On Crimes and Punishments", 1764 -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl |
|
From: Mark D. <ma...@ki...> - 2006-08-21 21:02:52
|
Nope, this is completely unrelated. We're discussing how to determine the IP address of a given hostname in a non-blocking fashion. We are NOT discussing how to get the IP address of people in our buddylist. -Mark On Mon, 21 Aug 2006 22:02:06 +0200, thomasasta wrote > If you would code http://Cspace.in into Gaim > it would be possible to get from each buddy the IP adress > which is actual, as the RSA-Key is found in the Kademlia base, > You only need to stick the RSA-key in the gaim client to any other > Chatname of any other protocol. With this method you can look up in > each session the actul IP Adress. And you could do even more, the > file transfer mechanism is for each protocol differen, you could, if > in the client the Chatname of each protocol is stuck to the Cspace- > Rsa-Key, use the Cspace protocol to have UNIQUE filetransfer to each > GAIM users. Does this solution solve your problem to get the IP > adresses of the users? While AOL and MSN .. etc do not allow > directly the IP adress pining of a buddy - jabber i do not know - > Cspace can provide them... How is Libc doing it ? Kind regards... > > -------- Original-Nachricht -------- > Datum: Mon, 21 Aug 2006 15:43:52 -0400 > Von: Ethan Blanton <ebl...@cs...> > An: gai...@li... > Betreff: Re: [Gaim-devel] Resolving IP addresses in Gaim > > > Sean Egan spake unto us the following wisdom: > > > Considering the DNS lookup code is already written, tested, and > > > stable, I see no compelling reason to screw around with it too much > > > now, but I'm not too particularly concerned. > > > > > > Really, we should just extend our SRV lookup code to handle A records > > > asynchronously. > > > > This has been discussed before, and there is a good reason we have > > not. Namely, gethostbyname() [getaddrbyname(), whatever] does _not_ > > necessarily just do a DNS lookup. Hostnames can be served from > > /etc/hosts, from NIS, from NetInfo, from LDAP, from WINS, from [...]. > > We obviously aren't going to write mechanisms for all of these things, > > so it's best to leave it up to libc. > > > > Ethan |
|
From: Ethan B. <ebl...@cs...> - 2006-08-21 21:03:13
|
tho...@gm... spake unto us the following wisdom: > If you would code http://Cspace.in into Gaim it would be possible to > get from each buddy the IP adress which is actual, as the RSA-Key is > found in the Kademlia base, You only need to stick the RSA-key in the > gaim client to any other Chatname of any other protocol. With this > method you can look up in each session the actul IP Adress. And you > could do even more, the file transfer mechanism is for each protocol > differen, you could, if in the client the Chatname of each protocol is > stuck to the Cspace-Rsa-Key, use the Cspace protocol to have UNIQUE > filetransfer to each GAIM users. Does this solution solve your problem > to get the IP adresses of the users? While AOL and MSN .. etc do not > allow directly the IP adress pining of a buddy - jabber i do not know > - Cspace can provide them... How is Libc doing it ? Kind regards... While I'm sure you know something, it doesn't appear to be about Gaim, DNS, or the topic at hand. Cspace is not relevant to this discussion. Thanks for playing, Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X