This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/9700] a means to sort addrinfo list


------- Additional Comments From stlman at poczta dot fm  2009-01-04 10:06 -------
(In reply to comment #1)

> And exactly how do you want to use this functionality?

I will stick to XMPP and XEP-0065 because I know it. When two parties want to
establish a direct P2P connection to transfer a file, the sender provides the
receiver with a list of its addresses. The sender can't determine the right
order. The receiver takes this (randomly ordered) list and tries to connect to
download the file. This is OK for a single homed machines with public IPv4. If
there are more addresses than one the receiver must try to connect each of them 
(and possibly encounter timeout once or twice) or implement RFC3484 once again
on its own.

If glibc provides a function (a wrapper for rfc3484_sort) to sort a list of
addresses application programmers take a list they receive, sort it and may
believe that the firs address in the list is most probably the most suitable to try.
   
> You'd have to modify and
> rebuild every single application on your system.

And why is that? If you assign an unused bit the new meaning doesn't break
anything? There are already few of them inside #ifdef __USE_GNU. Where am I
wrong. Has adding AI_IDN broken anything? Why would #define AI_SORT 0x0400?

> The special sorting function would be specific to you and nobody else.

It is vital for everyone who implements an application protocol which involves
passing host addresses. XMPP is just one of them which I have investigated.
BitTorrent seems to be another example.

> If you try to argue that the new sorting rules are generic enough [...]

I don't want any new sorting *rules*. I want rfc3484_sort, or preferably a
wrapper which accepts a list of addrinfo structures, to be a public function
(would sortaddrinfo(struct addrinfo*) be ok?). I simply do not want to
reimplement RFC3484 if it's already been done in libc.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=9700

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]