Slashdot Mirror

And Congress can basically tell them, "OK, then, I hope you've figured out how to send your broadcasts by carrier pigeon because in 2006 you won't have any broadcast spectrum that fits your requirements."

Absolutely the *best* programming book I have ever found!

Here is a link to it. It has details on C/C++, complete RFCs, amazing example code, and a huge index!

The biggest problem is that there is only one copy. I tried to make my own copy, but quickly ran out of toner. When I asked one of the authors if there were any plans to make a second copy, he laughed and said, "Maybe on Mars!". I think he is losing his mind from all the corporations trying to stake a claim in his creative works. He really wants to be available to everyone.

P.S. Here is a great article on the history behind this imaginative book.

Learn to use your 104-button mouse. A.K.A. the keyboard.

That one I would have to see to believe. I can get better throughput than that with the IP over Avian Carriers Protocol. Even my very first modem which was only 1200 baud had better throughput than that.

My point was that I used to get 5-6Mb/s downstream and 1-2Mb/s upstream and now get much less for a larger price. As the service became more popular rather than adding capacity they capped the speed. Bandwidth for a large telecommunications provider like AT&T is cheap and they should not degrade my service simply because they have more customers. I realize that not everyone has access to high-speed connections, but I do and I pay for it. I would still rather deal with the abusive nature and predatory tactics of AT&T than go back to dial-up. And therein lies the problem. They know that many of their customers will not return to dial-up, and for many people (like myself) cable is the only option available. So they can pretty much do anything they want and get away with it.

Click the (#3914122) in the header. You'll see he has one Underrated moderation and is currently at Score: 0, so he must've started at -1.

I still think he got the explanation right. ADSL is probably the issue.

Well, maybe he got it "right" in a trivial sense... but not in any useful sense.

Paraphrase of poster: "I have a DSL line where the upstream and downstream speeds are asymmetrical. Whenever I upload, it kills my downstream bandwidth because the ACKs aren't getting through fast enough. What can I do to fix this?"

Paraphrase of teknopurge's reply: "HAHAHAA!!1 The probelm isnt TCP dumbass! teh probem is that U SUXX0RZ cuz u have ADSL!! I M so l33t and have SDSL. Rawk!"

I think it's pretty obvious the poster has ADSL; he basically says so. And sure, SDSL doesn't have this problem. That wasn't the question though... and the problem has everything to do with TCP and its behavior on asymmetrical links... there have even been a few papers on the subject.

Here are some links from the IETF website: (documents also mentioned in the interview)

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses [ietf.org]

Here are some links from the IETF website: (documents also mentioned in the interview)

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses [ietf.org]

Here are some links from the IETF website: (documents also mentioned in the interview)

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses [ietf.org]

As Steve mentioned, "Rendez-vous" (zero configuration network) has been proposed as a IETF standard.

Here are some links from their website:

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses

and a March 2001 Proceedings

As Steve mentioned, "Rendez-vous" (zero configuration network) has been proposed as a IETF standard.

Here are some links from their website:

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses

and a March 2001 Proceedings

As Steve mentioned, "Rendez-vous" (zero configuration network) has been proposed as a IETF standard.

Here are some links from their website:

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses

and a March 2001 Proceedings

As Steve mentioned, "Rendez-vous" (zero configuration network) has been proposed as a IETF standard.

Here are some links from their website:

Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses

and a March 2001 Proceedings

This type of behavior (DNS encoding of geographical location) is already described in RFC 1712.
It is dissapointing to see a system designed to protect innovators being used to stagnate new discoveries.
Money Corrupts.

Hmmmm...."Zeinfeld". Pardon me for asking, but which HTTP author are you? I've met most of you, and like all of you, but quite frankly, at least one of you has a conflict of interest when it comes to opining on BEEP. You're entitled to an opinion, but I think your identity is important data in this case.

As for the IETF being an old boys/girls club...well, yeah. Welcome to politics. I think the IETF has generally been a reasonably equitable old boys club.

As for Marshall Rose, he kinda earned his way into the old boys club. He was co-author on many RFCs, including POP3.

But enough about the politics, let's talk about BEEP on its own merits. Maybe the reference implementations are crappy (I can't speak one way or another on that), but the spec looks pretty solid to me. As I said before, it fits the requirements that we had when we were shopping around for a base protocol for RTSP.

At any rate, I encourage people to do some digging themselves on this. I can't say that my experience is overly deep in this area, and I certainly haven't tried to design a protocol on top of BEEP, but based on what I know, BEEP looks like a pretty good idea.

Hmmmm...."Zeinfeld". Pardon me for asking, but which HTTP author are you? I've met most of you, and like all of you, but quite frankly, at least one of you has a conflict of interest when it comes to opining on BEEP. You're entitled to an opinion, but I think your identity is important data in this case.

As for the IETF being an old boys/girls club...well, yeah. Welcome to politics. I think the IETF has generally been a reasonably equitable old boys club.

As for Marshall Rose, he kinda earned his way into the old boys club. He was co-author on many RFCs, including POP3.

But enough about the politics, let's talk about BEEP on its own merits. Maybe the reference implementations are crappy (I can't speak one way or another on that), but the spec looks pretty solid to me. As I said before, it fits the requirements that we had when we were shopping around for a base protocol for RTSP.

At any rate, I encourage people to do some digging themselves on this. I can't say that my experience is overly deep in this area, and I certainly haven't tried to design a protocol on top of BEEP, but based on what I know, BEEP looks like a pretty good idea.

I've also been disappointed with the lack of uptake on BEEP. It's a very cool concept.

BEEP is Blocks Extensible Exchange Protocol (RFC 3080). More details can be found at here.

When we were designing RTSP, we looked for something like this, and at the time, the options weren't very appealing. We ended up using HTTP as a quasi-base protocol. I think it was the best solution at the time, but had BEEP been available, we'd have used it in a heartbeat.

acknowledged error-free non-duplicated transfer of user data, data fragmentation to conform to discovered path MTU size, sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, optional bundling of multiple user messages into a single SCTP packet, and network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

Implementations are already available or becoming available, on various OSs. Although designed for transporting real-time telephone signalling over IP (as stated in the RFC), it is applicable to anything else with similar requirements.

But does it comply with HTCPCP

But what if it's RFC 2325 compliant?

Didn't you read the RFC?

You need to type in coffee://www.pimprig.com because this is based on http but is a new spec. No wonder you didn't get the results you were looking for.

Unless it's RFC 2324 compliant, I'm not interested.

And, in fact, there's an IM standard under development in the IETF, called SIMPLE, that both AOL and Microsoft support. In fact, Microsoft already has SIMPLE support in the latest version of MSN Messenger

As you suggest, the addressing uses multiple domains (like "chefmonkey@aol.com") to route between systems.

Is that kinda what you're looking for?

And, in fact, there's an IM standard under development in the IETF, called SIMPLE, that both AOL and Microsoft support. In fact, Microsoft already has SIMPLE support in the latest version of MSN Messenger

As you suggest, the addressing uses multiple domains (like "chefmonkey@aol.com") to route between systems.

Is that kinda what you're looking for?

And, in fact, there's an IM standard under development in the IETF, called SIMPLE, that both AOL and Microsoft support. In fact, Microsoft already has SIMPLE support in the latest version of MSN Messenger

As you suggest, the addressing uses multiple domains (like "chefmonkey@aol.com") to route between systems.

Is that kinda what you're looking for?

Here's the usable standard that both AOL and Microsoft have agreed to use in the future. It's still under development, but almost complete. Complete enough, in fact, that MSN Messenger already includes a working implementation.

Quoting an article from ABC News: "AOL recently announced that it has begun testing a SIMPLE-compliant AIM"

The newest version of MSN messenger (the one that ships with Windows XP and can be downloaded for the other MS operating systems) also supports SIMPLE (although they use the obscure term "communications service" to signify it).

It looks to me like interoperablility -- even with the guys you predict will never be interoperable -- is on the way.

Quoting an article from ABC News: "AOL recently announced that it has begun testing a SIMPLE-compliant AIM"

The newest version of MSN messenger (the one that ships with Windows XP and can be downloaded for the other MS operating systems) also supports SIMPLE (although they use the obscure term "communications service" to signify it).

It looks to me like interoperablility -- even with the guys you predict will never be interoperable -- is on the way.

On the other hand, SIMPLE is every bit as interoperable as Jabber, with the added weight of the fact that AOL has agreed to interoperate with other vendors using SIMPLE once it is complete.

• http://www.ietf.org/html.charters/sip-charter.html
• http://www.faqs.org/rfcs/rfc3261.html

The guy is Danny Cohen, who gave us the terms big-endian and little-endian for computer architectures, and also started Myrinet. Imagine a Beowulf clu*SLAP* Ouch!

http://www.ietf.org/rfc/rfc741.txt

is IP, of course. See the IP Storage set of standards-in-development that includes iSCSI (IPS charter here).
Etherhet cabling is much cheaper than all the other stuff out there, and with 10G Ethernet just standardized, it goes faster too.

I hav to rethink this RFC: energy over IP

-1: offtopic

Now, I am stuck with the thousand monkeys we bought clamoring on the keyboards churning out shakespearean sonnets.

Is your network of monkeys RFC-2795-compliant?

• Vendor Neutral
  
• International
  
• Respected by the industry
  
• Respected by a majority of the world's nations.
  

To secure FTP traffic, I highly recommend SafeTP from the folks at Berkeley. SafeTP is an RFC 2228 compliant FTP Security Extension that uses Public Key Crypto to authenticate and secure the link.

SafeTP is supported under Unix / Linux as well as Windows 95/98/ME/NT/2000/etc. Source code for Unix and compiled code for Windows is available free of cost.

This quote from the Berkeley folks may be useful:

How is SafeTP better than existing FTP systems?

First and foremost, SafeTP secures the FTP control channel to ensure the privacy of the user password, thereby providing secure authentication. This in itself is a huge improvement over the traditional FTP protocol, which sends user passwords (and everything else) in the clear (see RFC 959).

SafeTP protects the control and data channels against a number of attacks, including eavesdropping attacks, modification attacks, and replay attacks. SafeTP provides this security through a public-key crypto-system based on the ElGamal, DSA and TripleDES security algorithms, and is implemented as an RFC 2228 security mechanism. The security negotiation is similar to the one used by ssh and SSL - see the X-SafeTP1 protocol specification for details.


SafeTP has several advantages over most existing FTP security systems (such as kerberos or ssh tunnelling):

• Transparent - the windows client automatically and transparently secures FTP connections from within the OS - which means the user can continue using their favorite FTP client, without ever having to think about it again. No need to tweak any settings in their client, no need to setup any tricky proxy or port forwarding software.
• Interoperable - the client software (windows and UNIX) automatically works with both secure and insecure (legacy) servers. The server software always accepts secure connections, and can be configured to allow or disallow insecure connections.
• Data security and integrity configuration - SafeTP always secures the control channel (which includes the username/password login sequence), but the client can be configured to provide privacy, integrity and authentication for the transferred file data as well. The user may also choose to disable data encryption to maximize performance.

We have found SafeTP to be both user friendly and expert friendly. We have been successfully using it now for several years. It works well behind firewalls. The code is both well written and stable.

To secure FTP traffic, I highly recommend SafeTP from the folks at Berkeley. SafeTP is an RFC 2228 compliant FTP Security Extension that uses Public Key Crypto to authenticate and secure the link.

SafeTP is supported under Unix / Linux as well as Windows 95/98/ME/NT/2000/etc. Source code for Unix and compiled code for Windows is available free of cost.

This quote from the Berkeley folks may be useful:

How is SafeTP better than existing FTP systems?

First and foremost, SafeTP secures the FTP control channel to ensure the privacy of the user password, thereby providing secure authentication. This in itself is a huge improvement over the traditional FTP protocol, which sends user passwords (and everything else) in the clear (see RFC 959).

SafeTP protects the control and data channels against a number of attacks, including eavesdropping attacks, modification attacks, and replay attacks. SafeTP provides this security through a public-key crypto-system based on the ElGamal, DSA and TripleDES security algorithms, and is implemented as an RFC 2228 security mechanism. The security negotiation is similar to the one used by ssh and SSL - see the X-SafeTP1 protocol specification for details.


SafeTP has several advantages over most existing FTP security systems (such as kerberos or ssh tunnelling):

• Transparent - the windows client automatically and transparently secures FTP connections from within the OS - which means the user can continue using their favorite FTP client, without ever having to think about it again. No need to tweak any settings in their client, no need to setup any tricky proxy or port forwarding software.
• Interoperable - the client software (windows and UNIX) automatically works with both secure and insecure (legacy) servers. The server software always accepts secure connections, and can be configured to allow or disallow insecure connections.
• Data security and integrity configuration - SafeTP always secures the control channel (which includes the username/password login sequence), but the client can be configured to provide privacy, integrity and authentication for the transferred file data as well. The user may also choose to disable data encryption to maximize performance.

We have found SafeTP to be both user friendly and expert friendly. We have been successfully using it now for several years. It works well behind firewalls. The code is both well written and stable.

To secure FTP traffic, I highly recommend SafeTP from the folks at Berkeley. SafeTP is an RFC 2228 compliant FTP Security Extension that uses Public Key Crypto to authenticate and secure the link.

SafeTP is supported under Unix / Linux as well as Windows 95/98/ME/NT/2000/etc. Source code for Unix and compiled code for Windows is available free of cost.

This quote from the Berkeley folks may be useful:

How is SafeTP better than existing FTP systems?

First and foremost, SafeTP secures the FTP control channel to ensure the privacy of the user password, thereby providing secure authentication. This in itself is a huge improvement over the traditional FTP protocol, which sends user passwords (and everything else) in the clear (see RFC 959).

SafeTP protects the control and data channels against a number of attacks, including eavesdropping attacks, modification attacks, and replay attacks. SafeTP provides this security through a public-key crypto-system based on the ElGamal, DSA and TripleDES security algorithms, and is implemented as an RFC 2228 security mechanism. The security negotiation is similar to the one used by ssh and SSL - see the X-SafeTP1 protocol specification for details.


SafeTP has several advantages over most existing FTP security systems (such as kerberos or ssh tunnelling):

• Transparent - the windows client automatically and transparently secures FTP connections from within the OS - which means the user can continue using their favorite FTP client, without ever having to think about it again. No need to tweak any settings in their client, no need to setup any tricky proxy or port forwarding software.
• Interoperable - the client software (windows and UNIX) automatically works with both secure and insecure (legacy) servers. The server software always accepts secure connections, and can be configured to allow or disallow insecure connections.
• Data security and integrity configuration - SafeTP always secures the control channel (which includes the username/password login sequence), but the client can be configured to provide privacy, integrity and authentication for the transferred file data as well. The user may also choose to disable data encryption to maximize performance.

We have found SafeTP to be both user friendly and expert friendly. We have been successfully using it now for several years. It works well behind firewalls. The code is both well written and stable.

The 'willing-buyer/willing-seller' standard requires that the CARP establish royalty rates for Internet radio based on market transactions between the record labels and the Internet broadcasters. There has only been one such transaction in the marketplace since the law was passed, and that contract was terminated prematurely by the webcaster. Therefore, the CARP did not have enough information on viable contracts from which to make a rate determination.

Up to now there has only been one such transaction (the infamous Yahoo thing). But it doesn't have to be that way! Indie labels and indie broadcasters can agree to whatever terms they like, right? So now is the time to do it, and then play a fuckload of music based on those terms, and then MAKE THAT THE STANDARD when this is inevitably taken to court and reviewed again and again in the next few years.

I suggest the following terms at no charge to you if you're a label or a webcaster: 10% of gross revenues. C'est tout! Put this in a real enforceable contract between (say) Pork records and (say) SomaFM, and then take that to court when the RIAA lies and claims that there has only been one contract between a cartel-member label and a cartel-member broadcaster.

IMHO indie labels / webcasters MUST do this to prevent the compulsory terms from becoming a bit more compulsory. DO IT NOW!

A bunch of people have already expressed that they like this question, but I'm different in that I really like this question.

I think that if Google shutdown (either by massive pigeon die-offs from contracting a buffer overflow exploit in the Avian Carrier Transmission Protocol or copyright violations of some sort) I would be utterly lost and helpless. It's probably my own fault for not exploring alternatives, but in all fairness, how many people have actually had the need to look into alternatives? I consider it my personal index/table of contents to the Internet.

Surfing is fine as a recreational use of the Internet, but to use it as a timely resource of information a centralized index is essential.

Of course, having more than one index lessens the "single-point of failure" risk but begs the question - "Who will become the indexer to index the indicies that are indexing the Internet?"

Linux Mandrake is just the latest in a long line of quirkily christened versions of Linux. Previous versions of Linux have been named Red Hat, Slack Ware, Storm and Coral. In stark contrast to the mundane names such as 98, ME or NT preferred by Microsoft, the crazy names of each Linux release hint at its renegade nature.

My foray into the world of Linux began by downloading a "CD image" from the Linux web site. But don't worry, this isn't software piracy, it's perfectly legal! Linux is shareware, meaning that it can be freely redistributed without fear of a visit by the Business Software Alliance. The free availability of Linux is a major reason for its popularity among cash-strapped students and self-styled anti-capitalist hackers.

Before installing new software, it is always advisable to read the documentation. Unfortunately, an unpleasant surprise was in store for me in the "required configuration" section of the manual. I was shocked to learn that Linux Mandrake only runs on Pentium processors, meaning that my hopes of testing the water with my old Gateway 486 were dashed. Furthermore, a whopping 32 megabytes of memory are required to run Linux! Although the advocates of Linux self-righteously boast the efficiency of their chosen operating system and deride the "bloatware" produced by Microsoft, it appears that their claims are blatantly incorrect. Although my humble 486 will happily run Windows 95, it seems that Linux requires far more powerful, and more expensive, computer hardware. Is this really the sign of a lean, mean operating system? Of course not.

Sadly, not even being able to install Linux is just the first of my many complaints. A brief perusal of the features of Linux Mandrake reveals that Linux is sorely lacking many crucial productivity applications. For example, why isn't the industry standard web browser, Internet Explorer, included with Linux? Despite the best efforts of the experts at the Internet Engineering Task Force to encourage adoption of the Internet Explorer standard, the creators of Linux seem to think that they know better. By refusing to adhere to recognised standards, Linux is simply undermining its own credibility.

Similarly, almost all of the world's most popular and widely used software is completely incompatible with Linux! It may surprise you to learn that your copy of Microsoft Office, Outlook Express, or Lotus Notes will not work under Linux. Those who wish to use their computer for recreational purposes are also out of luck, for almost all of the most popular games are unavailable for Linux. Although a wide range of software is freely available for Linux, these pitiful offerings are mostly unfinished, unreliable and do not bear comparison to their commercial counterparts.

Computer security is also an area that seems to have been overlooked by the developers of Linux. In these times when hacking and viruses are commonplace, it defies belief to learn that no anti-virus software is available for Linux. To add insult to injury, there is no Linux version of the popular ZoneAlarm firewall. By using Linux, you are issuing an open invitation to the hordes of ne'er-do-wells on the Internet.

The shortcomings of Linux are obvious. Without even installing Linux Mandrake, I have exposed several fundamental flaws. Surely it is not too much to expect that, after ten years of development, the creators of Linux would have addressed these problems? The real question that the prospective Linux user must ask himself is, "Why bother?" After all, Microsoft Windows comes free with most PCs and there simply isn't a need to replace it, particularly not with a product of inferior quality.

Although it is always tempting to support the underdog, Windows XP will be the deserved victor in the battle ahead. I recommend that those Adequacy readers who are hoping to upgrade their operating system patiently wait for the release of Windows XP, rather than foolishly wasting their time, effort and money on Linux.

But as long as the hardware is the bit that is the 'same' but the state of the 'versions?' of the hardware is different its a winner. If fact if you had an infinate number of machines all sightly different from each other the processing task would be done (at least on one of the machines) before you even executed the task. Thats a real time saver. Maybe the system could adapt IMPS for finding the correct answer... c.

MMS: Multimedia Messaging System -- this allows you to send email with audio/amr attachments, so you can play them with open source code from public 3GPP technical standards TS 26.071, TS 26.073, TS 26.101 and TS 26.074.

AMR is a truly great vocodec technology, which stands for "Adaptive Multi Rate." Accordingly, it takes less bandwidth and battery time because when the microphone isn't picking up sound (from, e.g., your speech) your phone isn't sending as much information. Just the way it ought to be. Why spend 4 kbps to send comfort noise when 20 bps can do just as well? Execellent code!

This restriction might be overcome by using Electricity over IP combined with 802.11x.

How about Transmission of IP Datagrams on Avian Carriers

Check out Freenet. Although it does have a kind of central server to keep a list of public Freenet nodes, it can work without it, because nodes will announce themselves to the network when they join.

Freenet currently uses its own protocol to connect to other nodes, but one of the hidden strengths of Freenet is that one can write plugins to transfer data using different methods, for example via encrypted messages posted thru anonymous remailers or even CPIP :)

A word of caution: Freenet is under heavy development, and the network performance is.. scetchy at best.

Much as I'm no fan of Microsoft's products or their approach to security(sic), Taking 60 days to get a fix released is not necessarily a bad thing and is pretty standard for vendor-software.

Security fixes which are rushed out often simply open up new holes (or cause other problems). Hence, common practice among Unix vendors is to release an emergency fix or patch, which is available sooner, and to later release an update which is fully tested.

Mitre and @Stake recently proposed a standard vulnerability disclosure RFC setting out apprpriate response times for software vendors (open source and proprietary). Basically, the RFC says "contact the vendor, give them at least 30 days to respond / fix; the vendor is responsible for keeping in touch with the reporter every 30 days; don't announce the vulnerability until there is a fix;

The intent here is to get problems fixed and announced in a manner that ensures that system users have a way to update vulnerable systems. (And personally I'm just fine if vendors also use some of that time to update critical customers, say financial institutions ahead of the rest of us)

In my own practice I usually wait a bit on patches. My immediate approach to a new vulnerability which affects my systems is to disable the vulnerable aspects or apply suggested work-arounds.

As I think many shops using MS are taking patches by the auto-update feature, perhaps propagating internally with SMS; Microsoft has an onus to try to be sure that fixes they put out are in fact correct and without unfound side affects.

Why do the geese need mobile phones when they could more easily have adapted the well known RFC 1149 protocol?

Another good reason to use the Carrier Pigeon Internet Protocol (yeah, correct link, it's *also* on Salon.com - how convenient). The details here.

Transmitting IP Datagrams over Avian Carriers simply has to be a way to avoid these mega corporations getting control over these common, often fiber based transmission techniques.

But I'm sure there will soon be a Pigeonsoft breeding huge amounts of pigeons for the sole purpose of pissing of others. And of course, the technique of training them to carry datagrams will be patented. And if you try to understand how it works, you'll be sued by the PPAA (Pigeon Protocol Association) for "infringing on intellectual property". They will use the PMCA (Pigeon Master Copyright Act) to support this claim in court.

That's the world we're living in.

There is an IETF standard called mobile IP which has been capable of doing this for years. I have used it to roam from Fixed Etherenet to 802.11 to cellular with out losing any of my sessions. The are many implimentations available. Dynamincs is is an open source solution. Cisco has a complete line of solutions. As well as a number of other vendors. So why would you want a proprietary solution like the one from greenpacket.