Slashdot Mirror

SHA-1 Hash Algorithm and Source Code

I'd go for NetBSD myself, but whatever OS you use it really won't do any good unless you use HTCPCP - that protocal was really designed for this kind of application...

It's true that there were other protocols like TCP invented at around the same time. It's also true that TCP had flaws, some of which have been fixed, and some of which haven't.

To the extent that TCP violated "principles" those principles are debatable. TCP did make some design compromises - such as to use the same field for both an endpoint identifier and a locator - which seem shortsighted today but which also made TCP much eaiser to deploy at the time it was invented. In any engineering effort, it is rarely feasible to do everything "right". Compromise is nearly always necessary.

HTTP is another example of a protocol that is riddled with design flaws, but was close enough to "right" and easy enough to implement and deploy that it succeeded. Competing protocols did exist and they failed because they either weren't "right" enough or were too hard to deploy.

The reason you don't see IPv6 used these days has little to do with the design of TCP. You don't see IPv6 these days for two reasons: one is that there is a significant investment in IPv4, particularly for established services such as email and the web. These services work well enough on IPv4 (with or without NATs), and there's such a huge investment in IPv4 infrastructure for them, that they'll be the last services to migrate to IPv6. The other reason you don't see IPv6 used much these days is that the greatest markets for IPv6 are precisely in those areas where IPv4 is insufficient - because of a shortage of IPv4 address space, or because the need to use NATs has made the IPv4 network unable to efficiently support certain kinds of applications. IPv6 usage will at least initially be in different markets and for different applications than IPv4 usage - which means if you're looking for IPv6 to be used in the ways that IPv4 is used now, you won't see much of it for awhile. IPv6 is being used, but not in that way.

Now perhaps the flaw you were referring to is the lack of ID/locator separation and the implication is that IPv4 hosts cannot communicate with IPv6 hosts. I believe HIP will solve that problem. I also believe that by the time HIP does solve that problem, it will be largely a non-problem, as nearly everything will support IPv6 by then anyway. But HIP will be useful for other reasons.

Unlike ad hoc Web forums, USENET is based on an
IETF standards. See:
http://www.ietf.org/rfc/rfc0977.txt?number=977
http://www.ietf.org/rfc/rfc0850.txt?number=850

Unlike the web, USENET articles include a
subject, date, and author as part of the
formalism and are intrinsically threaded.

Unlike forums, news articles have their own
URL (news://...) so can be linked to.

Unlike mailing lists, newsgroup articles
reside on servers so they do not encumber
your mail box. You go to them, they do not
come to you.

Almost all email readers come with a news reader.

Finally, although public forums are subject to
spam, the spam problem will be solved eventually,
it is possible to set up moderated newsgroups,
and, one of the least used possibilities of
the internet, private newsgroups make for an
excellent means to collaborative project
management.

GoogeGroups is good. Some posts here point out
that the default reply operation does not
include the quoted post being replied to. But
the 'show options > reply' method of creating
a reply *does* quote the post being replied to.

I consider the lack of that in the default
reply to be design flaw but not a condemnation
of either GoogleGroups or USENET.

Cheers,
Dennis Allard

Unlike ad hoc Web forums, USENET is based on an
IETF standards. See:
http://www.ietf.org/rfc/rfc0977.txt?number=977
http://www.ietf.org/rfc/rfc0850.txt?number=850

Unlike the web, USENET articles include a
subject, date, and author as part of the
formalism and are intrinsically threaded.

Unlike forums, news articles have their own
URL (news://...) so can be linked to.

Unlike mailing lists, newsgroup articles
reside on servers so they do not encumber
your mail box. You go to them, they do not
come to you.

Almost all email readers come with a news reader.

Finally, although public forums are subject to
spam, the spam problem will be solved eventually,
it is possible to set up moderated newsgroups,
and, one of the least used possibilities of
the internet, private newsgroups make for an
excellent means to collaborative project
management.

GoogeGroups is good. Some posts here point out
that the default reply operation does not
include the quoted post being replied to. But
the 'show options > reply' method of creating
a reply *does* quote the post being replied to.

I consider the lack of that in the default
reply to be design flaw but not a condemnation
of either GoogleGroups or USENET.

Cheers,
Dennis Allard

SHA-1 Hash Algorithm and Source Code.

So I'll bite. Your post doesn't deserve +5 insightful, but rather than use my Mod points, I will let you know why and add some thoughts.

Take a look at this RFC, note that it's how Outlook does their calendaring (and that the RFC's authors work at Lotus (IBM) and MS). What were you saying about Microsoft being afraid to commit to an open standard? How many other internet standards are authored or co-authored by Microsoft employees? How many are accepted as standards by committees with Microsoft employees sitting on them? XML, etc.

There are lots of standards that "Microsoft" not only commits to, but also authors. There are some closed standards organizations (mostly hardware) also. Standards are just as much of a double edged sword (for interoperability sake) as everyone doing their own thing.

On one hand, if everyone works off of a standard, then the minimal subset of implementation of that standard is adopted, and there's a common platform for interoperability. On the other hand, if people implement competing applications without agreeing on a standard, or by extending the standard in new and unapproved ways (think HTML), then the market will determine which application is best fit. If Microsoft was not the best fit software to run on computers (note that this is a broad definition of fitness as determined by the market forces in general), then why would Dell and Gateway install it on just about all their desktop and laptop products? Why would consumers pick Windows over Linspire, or Knoppix?

Regardless of what you think about the stability of Windows, Linux, etc. The truth is that there are many reasons that Windows is on top on the desktop market. But the fundamental most important one is that it runs 99% of the software from all of the Microsoft Windows and DOS operating systems that came before. If you're looking for freeware, shareware, commercial software, or even open source software, chances are, it all runs on Windows. That's what Bill Gates is talking about when he talks about interoperability. It's commitment to running the garbage that's already out there in the market. Someone (who works at MS) once told me that there are something on the order of 500 global variables which tweak the way that IE behaves to account for bugs in other people's software.

This is a major problem for Microsoft in the future: How do they release a new version of Windows without breaking that? How do they release a Windows which doesn't let users log in as administrator or administrators log in like normal users? How do they break the cycle of bad programmers making bad assumptions that the circumstances involving the way the OS used to work were going to be true forever? Commitment to interoperability means being willing to suffer for the mistakes of others.

If this means by comparison that OSS has poor interoperability, then that's what it means. It's not elegant software design to add kludges here and kludges there to special case it so that other people's poorly designed code still works, but commitment to keeping older software working without rewriting it is what keeps Microsoft in business. And commitment to interoperating and extending older software with new software will make-or-break Microsoft's future deals also.

There's an even larger picture being missed here;

When iCalendar support is built into everything, it'll be very easy for public groups to see each other's meetings, and for individuals to participate.

I easily lose track of when the Seattle XP programmers, Seattle Perl programmers, Seattle Python programmers, Seattle Robotics Society, Seattle Cosmic, Seattle Wireless, Seattle Java, Seattle C++, Seattle Wikipedia, Seattle FreeBSD Users group, Greater Seattle Linux Users Group, Seattle Bloggers, East side Bloggers, Seattle Futurists, etc., etc., etc., ...I easily lose track of what's going on when. With automatic calendaring, when we can subscribe to calendars as simply as we subscribe to RSS feeds- we're going to see a surge in awareness of what groups are meeting when, and how to meet up with them.

Right now, I can only track 1 group at a time. "Is Seattle Python meeting this weekend?" "No?" "Guess there's nobody to see this weekend."

But, as you can see from my short list above (compared to how much activity is actually going on,) there's actually a whole lot going on that I might be interested in visiting.

As Automatic Calendaring picks up, the public will recognize the power of its ability to communicate and organize.

Previously, this is something that only people who could afford secretaries could experience.

Not a bug a feature... to generate message Ids that are traceable back to originating machine...

Not a feature an idea that perhaps seemed OK at the time... to generate unique message IDs based on an existing type of unique identifier that happened, in the original format defined for it, to use an IEEE 802 MAC address, presumably because those are intended to be unique to a piece of hardware, so the rest of the UUID merely has to be a value that will never be used again on a system where that MAC address is used to generate UUIDs.

The current Internet-Draft for a URN namespace for UUIDs mentions another scheme to generate UUIDs in that format that don't use a hardware MAC address but that won't collide with UUIDs generated from MAC addresses for hardware (by turning on the bit that would be the multicast bit in an 802 MAC address).

I've written a basic HTTP daemon. I've debugged Apache setups using telnet to port 80. I've read the RFC. The first line of an HTTP request contains the method, the request URI, and the HTTP version, which at present is either "HTTP/1.0" or "HTTP/1.1".

First off, tell me. Which standards does PGP [or SSH and SSL for that matter] follow? They ALL started off as homebrew projects.

http://www.ietf.org/html.charters/openpgp-charter. html

Many times, a project gets started, then a standard follows and other implementations begin to appear. Javascript started off as Netscape's project. Then the ECMA scripting standard got finalized afterwards. That doesn't mean we should just all ignore the standard. Open standards are one of the few pieces of leverage small companies and open source authors have against big corporations like Microsoft.

"First off, tell me. Which standards does PGP follow?"

RFC 2440? It means that you can send messages to PGP, GnuPG, and Hushmail users without them needing additional software. It means your message gets decrypted and checked automatically in KMail and TheBat, and by existing plugins for Outlook, Outlook Express, Eudora, Evolution, Mutt, Thunderbird, and Apple Mail.

OpenPGP may have been created from PGP rather than the other way around, but you can't deny that it's the standard for encrypted and signed email messages.

The irony, of course, being that SIP has MORE THAN ONCE been suggested as a replacement open IM protocol...

The irony, of course, being that SIP has MORE THAN ONCE been suggested as a replacement open IM protocol...

I thought so, however I don't know what's happening with IDN ...

I thought so, however I don't know what's happening with IDN ...

DNS is binary; does that make it proprietary? Not at all. It is a published open standard in RFC 883 and later documents. Other examples include ASN.1/BER as used in SNMP. It's not whether it is binary or text that matters; it's whether it is openly documented and unencumbered by intellectual property claims (a separate issue some of XML has).

The decision of binary vs. text for a format should be the result of specific needs. XML is verbose. XML can be compressed for transmission purposes, but it still has to be uncompressed to its verbose form for parsing. If speed in parsing is necessary (it might be as I have noticed quite many XML based progams are rather slow), a binary format can have things like length prefixes and continuation tags, instead of having to detect and verify collection of characters whose position is unknown. A parser that does not recognize a given tag, or does not need to process it, in a binary format can simply skip it by jumping the specified number of bytes. Binary format is very optimal for machine processing.

The usual argument for a text format spans the range of permitting humans to create the content for most things directly in an editor like vi or emacs (no wars here, I listed my favorite last), or reading that content directly, such as to diagnose the real cause of misunderstood errors. XML is too utterly complex for human creation or interpretation to be effective on a direct basis. There may be some argument that it can still be effective for diagnostic purposes (I have in fact needed to do so many times). Given that it is the powerful tools of XML that are used as the basis for the benefit of XML and promoting it, then what does it really matter what format is underneath as long as it is open and unencumbered?.

A binary format for XML will absolutely not kill XML. DNS is obviously not dead (and you'll love it even more when IPv6 rolls into your network). What a binary format might do is weed out some of the weaker programmers who are sticking their fingers a bit too deep into the inner workings of some applications and tools.

Beyond basing a standard for managing stateful telecommunications sessions on a protocol for stateless bulk data transport, the most blatant silliness in the SIP standard was the original "Alert-Info" header. The Alert-Info header allowed the calling party to specify the ring tone/sound by listing a URL that the receiving device would automatically attempt to fetch and play without waiting on the recipient user to allow/disallow it.

Others:
List of Evil SIP ideas

Oh, and never updating the SIP version string despite syntax changes in the standard is evil.

The NAT problem got resolved by UDP encapsulation ("NAT-T" = NAT traversal, after years of being a draft finally published 5 days ago as RFC) got implemented by most vpn software during the past two years (= too late).

Hybrid auth means: peer A ("the server") authenticates itself to peer B ("the client") through asymmetric methods (like an RSA keypair and a X.509v3 cert). Peer B chooses a random symmetric session key and encrypts it for A, this sets up an encrypted tunnel. Inside this tunnel, B authenticates itself to A using simpler techniques like challenge-response or even clear passwords. Allmost all personalized TLS/SSL protected services (https, pop3s, imaps, ...) work this way: Servers has a cert, client has a password. Easy to admin, easy to deploy, easy to rollout.

But with IPsec/IKE/ISAKMP you have to choose between shared secrets (bah!) or rolling out keypairs to all peers. And like all other protocols requiring all peers to be part of a PKI (PGP, S/MIME, SSL+certs on both sides) this slowed down propagation strongly.

There is an IETF draft "A Hybrid Authentication Mode for IKE" which is adopted my more and more implementations right now (= far too late). Cisco is now pushing it because of the failure of their own "group password scheme" (of course they name it differently: "Mutual Group Authentication").

Man, why did they wait so long?

/graf0z.

Pigeons! So you managed to sucessfully implement RFC 1149?
http://www.ietf.org/rfc/rfc1149.txt?number=1149
Congrats to you!

I think the IETF's web site is http://www.ietf.org.

Spam lingo for this phenomenon is "backscatter" or "outscatter" (I prefer the last one, as the bounces are not actually sent "back", but to an innocent third party). Spam Links as a link collection to get you up to date at:

http://spamlinks.net/filter-bounce.htm

A nice solution is Bounce Address Tag Validation (BATV), described at:

http://www.ietf.org/internet-drafts/draft-levine-m ass-batv-00.txt

Abstract:

The envelope of Internet mail contains an RFC2821.MailFrom command, which may supply an address to be used as the recipient of transmission and delivery notices about the original message. Existing Internet mail permits unauthorized use of addresses in the MailFrom command, causing notices to be sent to unwitting and unwilling recipients. Bounce Address Tag Validation (BATV) defines an extensible mechanism for validating the MailFrom address. It also defines an initial use of that mechanism which requires no administrative overhead and no global implementation.

Wouldn't they use pigeons?

how would you diff a file with a binary image encapsulated in it?

Quite easily. For example, you can include binary images in HTML documents using a data URL. You can diff the document with no problem and you will get sane results.

...it should be fairly easy to write some sort of Perl front-end for CVS...

My point was that for practically everyone, treating them as binary files is the best solution, in which case they really aren't any better than Microsoft Office files.

Be careful with OpenPGP in Jabber. The in-band key distribution is horribly flawed (to the extent the specification was withdrawn), although it's fine if you distribute the PGP keys some other way. There is a new specification for encrypted messaging from the IETF (RFC3923), but it's really ugly, and I certainly don't plan on implementing it in my client any time soon. I don't know if other client developers intend to or not.

"Atom over XMPP" is supported by PubSub.com and is the subject of an Internet Draft. See: http://www.ietf.org/internet-drafts/draft-saintand re-atompub-notify-01.txt

We offer a free FireFox/IE sidebar for receiving "Atom over XMPP" on our website at: http://www.pubsub.com/sidebar_firefox.php

bob wyman

Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.

This is a well known and "solved" issue...

bob wyman

"Speaking of country code TLDs, anyone know for sure when .eu will become available?"

The EU isn't a country, it doesn't have a country code, and it won't be recognised by ICANN. All of the territory of the EU overlaps other countries, therefore it will not become a country code. ICANN is keeping the .eu domain reserved for this purpose, but doesn't plan to create a country-specific domain for a non-country.

Disclaimer: everything I know I learned from wikipedia! ;-)

At the moment, EU sites are using *.eu.int

Codes to look for are ISO_3166-1 and rfc1394

My dad tried their system to promote a fledgling e-commerce site for his wife's business. In two weeks, they reported about 400 clicks. Thing is, his web host reported only about 300 hits on his home page.

His web host can't tell him how many visitors he had. Things like caching, reloads, browser bugs, network errors, etc, get in the way.

Google gave him this totally bogus, highly-technical explanation about referrer logs and that he may not be able to accurately track how many visitors were coming from them.

That sounds like a perfectly reasonable response. If you have time, you can read the HTTP 1.1 specification and draw your own conclusions. Assuming you have understood everything correctly, they will be the same as Google's.

Keys pressed are not connected to sending the email.

Wow. You are just a serious fucking moron out to pick a fight wherever you can find one.

For one, I can use a simple telnet application to send email, simply by connecting to the SMTP port, and saying "HELO". Every character I type is directly transmitted. THE KEYS PRESSED ARE DIRECTLY CONNECTED TO SENDING THE EMAIL.

Now, somehow, because there's a character buffer in my email program, you think it's not wiretaping?

Because there's a packet buffer in my router, you think it's not wiretaping?

Because there's a fiberoptic connection, you think it's not wiretaping?

Because there's a pigeon who physically carries a bunch of packets for an early part of the journey, you think it's not wiretaping?

By your definition, it's only wiretaping if it physically happens PRECISELY AT THE STATE BORDER. Not one angstrom to the left or to the right.

Or, if I'm going to be generous to your crazy argument, then it's only wiretaping if it literally happens to a wire which geographically crosses over a state border, uninterrupted by any mediating or signal-enhancing device. In other words, one strand of physical wire. Uh, no. Nothing works that way any more. Not even phones - there are fewer and fewer POTS anymore.

From RFC3257 - Stream Control Transmission Protocol Applicability Statement"

SCTP is also connection-oriented and provides all the transport services that TCP provides. Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements. Note, for applications conscious about processing cost, there might be a difference in processing cost associated with running SCTP with only a single ordered stream and one address pair in comparison to running TCP.

So you're right, SCTP can perform an equivalent of TCP's functionality, although with additional features, and therefore additional complexity. Of course, increased complexity usually decreases performance. As performance was one of the major goals of this speed test, SCTP would probably have not have been appropriate.

Ideally, I think we need a whole new *physical* layer Internet, separate from the existing Internet or Internet2 and devoid of participation by any and all governmental agents and anybody else who is significantly on the government payroll (defense contractors, etc.). Something like a wireless (or perhaps wired, where suitable), fully privately-owned mesh network on which only community-approved (based on the agreement of a certain number of surrounding and already-participating node-owners, much like with WASTE, except in meatspace) private nodes may communicate, over which all traffic is encrypted, possibly multiple times, possibly in hardware...

Yeah. First of all, wireless would be extremely bad, because it makes eavesdropping a snap. Even with encryption, it MAY be possible to conduct traffic analysis under certain preconditions. Second: the RF spectrum is the property of the state, which licenses its use to private parties. If you want to sidestep governments with wireless technology, it will always be illegal.

Having said this, you're right too: Not that long ago, we didn't rely on commercial internet service providers to connect our computers. We used UUCP or other custom made solutions that ran on the good ole POTS.

Imagine some kind of "UUCP Reloaded", using wireless spectrum! That would be great.

There's also MANET, which seeks to provide mobile ad hoc networking (a.k.a. mobile routing). That is also a good step in the right direction.

Time to switch to XMPP (AKA Jabber) and its
End-to-end encryption extension.

But the problem here is that this RFC is being preached to be implemented on NATting devices, like firewalls. So, I wouldn't imagine any "big" firewall vendor to implement another model for P2P :-)

And BTW, m$ have just implemented that for WinXP & Win2K machines!

midcom-p2p.sf.net has an implementation called natcheck which might be handy. Note that you can even connect via TCP sometimes; Bryan Ford is writing a paper about that. See also draft-ford-midcom-p2p-03.txt, RFC3489 (STUN), and my site, alumnus.caltech.edu/~dank/peer-nat.html.

You can set up per-user domain keys, and take the private key with you (as long as you can add your own DNS records). You could also set up multiple keypairs, one for each of your devices. See section 6.4 (Roving Users) of the DomainKeys spec. This is one of its advantages over SPF.

But your hosting company SHOULD allow you to use their SMTP server over an SSL connection, as long as you authenticate.

A million monkeys might eventually write Shakespeare, but how would they recognise it once they had?

They'd use RFC 2795, the Infinite Monkey Protocol Suite of course

"A million monkeys might eventually write Shakespeare, but how would they recognise it once they had?"

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.

Interesting to see that amongst the list of protocols on the page (including Appletalk, ATM and HTTP), Microsoft is also kindly allowing us to licence the valuable discard protocol. The protocol that accepts data and immediately loses it.

So Microsoft did invent that concept then.

Keep in mind that even though the core protocols haven't changed that much, actual TCP/IP deployments have drastically changed since the early 80s. Efficient packet forwarding algorithms (which are necessary in Gigabit networks and beyond) are certainly subject to patents today.

As might efficient packet discarding algorithms, as per their listing the Discard Protocol as one of the protocols you can license from them.

That strongly suggests to me, at least, that they just enumerated protocols Microsoft implements but didn't invent solely by themselves (or didn't invent at all), and threw them into the list, perhaps on the theory that it's better that other organizations and individuals spend time figuring out what stuff might be covered by patents owned by Microsoft than that they spend time figuring out what public protocols actually are covered, in part or in whole, by some Microsoft patent.

..because M$ wasn't even the publishers of most of the protocols.

For example, take the "Character Generator Protocol" http://www.ietf.org/rfc/rfc0864.txt, which was posted by Mr. Postel on May 1983 without any restrictions for usage and/or modification.

And AFAIK Postel never did work for Microsoft and never sold his rights to them.

I didn't take a look at the other protocols yet, i i guess it's the same story for most, if not all, of them...

Not the Quote of the Day Protocol as well!
We are all doomed now.

One of the major annoyances my company is finding during our internal Thunderbird testing is this freakish behavior:

1) user gets email.

2) user replies to email, text wraps correctly.

3) user forwards email and the text does not wrap at all, but instead runs off the screen horizontally causing annoying readability issues.

Does anyone know why this is? It still appears to be in Thunderbird 0.9. I'm confused as to if it is a bug or by design. If it's a bug, it's kind of a big one. If it's by design, it's kind of a poor design and there should be an option or preference to have "reply" and "forward" act consistently.

Otherwise, Thunderbird ROCKS -- nice work Thunderbird developers. It's fast, free and just getting better and better with each release.

~jeff

p.s. Inline spell check would be nice

You cannot fix social problems with legislation. Spam will never end as long as there will be fools who buy products advertised by unsolicited commercial e-mail. Period.

actually the problem is that proxies can store whatever they want, there is no 'rules' for them to obey.

The 'rules' are described in RFC 2616, the HTTP 1.1 specification.

whatever meta-tags you write in html-header, most proxies cache pages and images anyway.

Like I said, <meta> elements are unreliable as proxies don't usually parse HTML. They virtually always pay attention to HTTP headers though.

There is also work under way to approach this sort of issue using a new protocol called DCCP. DCCP sits on top of IP rather than UDP or TCP so is at a lower level. DCCP stands for Dynamic Congestion Control Protocol and has some reasonably interesting people behind it. Here are some links referencing it: http://www.icir.org/kohler/dcp/ http://www.ietf.org/html.charters/dccp-charter.htm l I'm actually looking to do a PhD in research on DCCP shortly so this discussion is quite interesting!

I'd rather add a thin error checking addition and ask for a retransmission for the occasional dropped packets.

Congratulations, you have just re-invented TCP with selective acknowledgments (a.k.a. SACK, RFC 2018, published in October 1996).

For more discussion on this topic, see also: http://www.icir.org/floyd/sacks.html.

TCP uses packet loss (NOT round trip times - where did that come from?) to signal congestion, and thus to implement congestion control. This does not work well in a typical wireless (802.11X, 802.16, etc) environment, where packet losses are to be expected. TCP also does not co-exist well with lots of UDP streaming.

So, there IS a need for a TCP replacement. However, the one being developed in the IETF is DCCP. Basically, the idea is separating congestion control and packet loss replacement.

Maymounkov and company say that they are preparing RFC's (which implies that they intend to submit this to the ITEF), but have not yet done so. So, maybe if they do, and if they offer an unencumbered license, their technology could be used, but it is way too soon to tell.

TCP uses packet loss (NOT round trip times - where did that come from?) to signal congestion, and thus to implement congestion control. This does not work well in a typical wireless (802.11X, 802.16, etc) environment, where packet losses are to be expected. TCP also does not co-exist well with lots of UDP streaming.

So, there IS a need for a TCP replacement. However, the one being developed in the IETF is DCCP. Basically, the idea is separating congestion control and packet loss replacement.

Maymounkov and company say that they are preparing RFC's (which implies that they intend to submit this to the ITEF), but have not yet done so. So, maybe if they do, and if they offer an unencumbered license, their technology could be used, but it is way too soon to tell.

So others can have fun slashdotting other technologies, here are some websites. There are probably others, but this should keep those who do really want to move away from TCP happy.

• Actual sourcecode to transmit binaries by multicast
  
• IETF Reliable Multicast Transport - Charter + RFCs
  
• Introduction to Multicasting (a little old, doesn't cover things like IGMPv3)
  
• Lightweight Reliable Multicast Protocol
  
• Microsoft's Reliable Multicast
  
• SUN's Reliable Multicast system
  
• Navy Research Laboratory implementation
  
• Scalable Reliable Multicast
  
• Cooperative Reliable Multicast
  
• Reliable Multicast for Wireless environments
  
• Selectively Reliable Multicast