Slashdot Mirror

And fortunately, a RFC defining the methodology for such a method of transport already exists!

• A few publications
  
  
• RFC 3453: The Use of Forward Error Correction (FEC) in Reliable Multicast
  
  
• Priority Encoding Transmission (with some info on Tornado)
  
  
• Slashdot - EETimes on Digital Fountain
  
  

Are you kidding? From the article: "Steven Spielberg turned Dick's tale "Minority Report" into his darkest flick yet."

Uh... let's recap. In 1993 Spielberg directed a film called Schindler's List. A little darker than Minority Report. I won't mention the content of "Schindler's List" for fear of invoking Godwin's Law, but suffice it to say that a movie featuring mounds of burning bodies and people shot for sport just might be a dark movie.

You may find RFC 1149 useful:
"A Standard for the Transmission of IP Datagrams on Avian Carriers}

I appreciate the good uses that SSH tunnel forwarding can be put to, but extensions to SMTP (RFC 2487), as well as POP3 and IMAP ( RFC 2595 allow secure connections without requiring the tunnel.

These extensions are integrated into most mail clients. Installing a server that supports the secure connection isn't hard either.

I always try to keep it simple. When I start having to troubleshoot three different systems in order to find out why my mail isn't being sent or received, I'm making my system too complex (too complex for the likes of me, anyway :-)

I appreciate the good uses that SSH tunnel forwarding can be put to, but extensions to SMTP (RFC 2487), as well as POP3 and IMAP ( RFC 2595 allow secure connections without requiring the tunnel.

These extensions are integrated into most mail clients. Installing a server that supports the secure connection isn't hard either.

I always try to keep it simple. When I start having to troubleshoot three different systems in order to find out why my mail isn't being sent or received, I'm making my system too complex (too complex for the likes of me, anyway :-)

Official standards may have changed since I worked there in 1998, but I doubt if the culture has changed. Which worked like this: we had a choice of two desktop environments Open Look and CDE. Most old Sun hands used Open Look, but IS was trying to end-of-life it, mainly because they didn't want to support mail clients that directly access the mailbox file, as all the Open Look clients do. Open Look users were fighting this change tooth-and-nail.

When I started, I was told to use the IMAP client that's built into CDE. Which was probably as close to a "standard client" as anything that was then in use. It was only after I got sick of the limitations of this program (especially its lack of directory support) that I switched to the Netscape IMAP client all on my own.

I believe the poster is trying to say that IPv6 was _less_ of a priority before we had NAT. This is incorrect but not offtopic.

One of the most immediately clear downfalls of IPv4 is the (relatively) small address space. If every IP-addressable machine had to have a world-unique IP address, then IPv4 would have fallen well short, and so IPv6 would have been necessary. However, with the advent of NAT, we are able to have m addresses for n nodes on a network, where m < n. As a matter of fact, m is usually 1.

This is why most machines you'll run into on a private network are 192.168.x.x, or one of the other IP ranges set aside for private network use (see RFC 1918). (For extra credit, a show of hands of everyone using address 192.168.0.101 right now).

For more NAT fun, see RFC 1631.

I believe the poster is trying to say that IPv6 was _less_ of a priority before we had NAT. This is incorrect but not offtopic.

One of the most immediately clear downfalls of IPv4 is the (relatively) small address space. If every IP-addressable machine had to have a world-unique IP address, then IPv4 would have fallen well short, and so IPv6 would have been necessary. However, with the advent of NAT, we are able to have m addresses for n nodes on a network, where m < n. As a matter of fact, m is usually 1.

This is why most machines you'll run into on a private network are 192.168.x.x, or one of the other IP ranges set aside for private network use (see RFC 1918). (For extra credit, a show of hands of everyone using address 192.168.0.101 right now).

For more NAT fun, see RFC 1631.

http://www.faqs.org/rfcs/rfc2460.html

IPv6 has many improvements over IPv4 other than just more address space.

• Expanded Addressing Capabilities (multicast, anycast, etc)
• Header Format Simplification
• Flow Labeling Capability
• Authentication and Privacy Capabilities

I checked Windows Update today on a lark

Are you using an update of the Avian Carrier standard? Or is there simply a lack of pidgeons in your area?

If its a new standard, can we see some benchmakrs, and comparisons with the Avain system. Also does it support IPv6?

Thanks

A Standard for the Transmission of IP Datagrams on Avian Carriers .

Bah. They deserve what they get for replacing the standardized pigeon carrier and substituting with parrots.

Then again, using fault-tolerant albatross carrier for extreme weather conditions might have merit...

No one else here seems to be interested, but I think this is outstanding news. Fantasy Flight is an outstanding board game publisher, with great designs at Twilight Imperium, Reiner Knizia's Lord of the Rings cooperative board game, and Tom Jolly's Drakon.

By the way, people on this site may not be familiar with the great innovations that are happening in the board game world recently. Since the mid 90's, the Germans have revolutionized the industry, and there are many more original ideas coming out in board gaming recently compared to the stagnant computer game world. See Keith Amman's "German" Board Game FAQ for more information.

""Give Communism A Try - Free Linux"

Which also has tux doing a Nazi salute and saying "Ya Vol". So, Communism==Nazism? Eh? And misspelt German is not the way to look clever. What a bunch of dumb fucks."

That means they just lost the case thanks to Godwin's law !!! (now bring that to a court)

Actually, I've bolloxed it pretty badly in my earlier post. Correction below.

There's a three bits for "format prefix" for the type of traffic, and eight bits "reserved for future use" and the 64 bits at the end are for the "unique hardware identifier" are not required to match the Mac Address (but often will).

It seems that there will be between 9,007,199,254,740,992 and 2,305,843,009,213,693,952 possible networks (the rfc uses the term aggregates) of 18,446,744,073,709,551,616 hosts each, depending on the what the eight reserved bits are used for.

That's 166,153,499,473,114,484,112,975,882,535,043,072 to 42,535,295,865,117,307,932,921,825,928,971,026,432 possible hosts connected, if every network contains the maximum nuber of hosts.

I must admit that I'm a bit confused by some of the posts I've seen here stating the huge number of addresses that IPv6 prommisses to bring.

I've perused the specification (I'll read it more thoroughly later) and the address format and I'm not getting 340282366920938463463374607431768211456 (128 bits) separate addresses. I'm getting 281474976710656 (48 bits) public (sub)network addresses plus 65536 (16 bits) of site addresses allocated to each of those, followed by a 64bit hardware identifier (MAC address). It appears that IPv6 means 18,446,744,073,709,551,616 IP adresses each linked to a MAC adress, of which 281,474,976,710,656 are reserved for address space at each site.

Admittedly, I'm no expert on this and could be interpeting this wrong. Someone pease clarify how this works.

(Thank you bc, my favorite calculator.)

I must admit that I'm a bit confused by some of the posts I've seen here stating the huge number of addresses that IPv6 prommisses to bring.

I've perused the specification (I'll read it more thoroughly later) and the address format and I'm not getting 340282366920938463463374607431768211456 (128 bits) separate addresses. I'm getting 281474976710656 (48 bits) public (sub)network addresses plus 65536 (16 bits) of site addresses allocated to each of those, followed by a 64bit hardware identifier (MAC address). It appears that IPv6 means 18,446,744,073,709,551,616 IP adresses each linked to a MAC adress, of which 281,474,976,710,656 are reserved for address space at each site.

Admittedly, I'm no expert on this and could be interpeting this wrong. Someone pease clarify how this works.

(Thank you bc, my favorite calculator.)

A long time ago there was a "firm commitment" to move the Internet to OSI standards (shudder...), as mandated by GOSIP, a.k.a. FIPS 146-1. (See this ancient RFC for an overview.)

They were dead serious about it.

They failed.

The point? Government mandate is not a guarantee of success. Granted, OSI and IPv6 are worlds apart, and converting to a protocol which was designed to cause as little disruption as possible is at least technically achievable. But it would be foolish to disregard the technological inertia.

Also, I find that Security Focus has a huge backlog of very useful and interesting information for those concerned with computer security. In that same vein, dbaseiv.net [Google cache, the site seems to be down right now] is shaping up to be a huge repository of computer security knowledge.

The Linux Documentation Project is full of HOWTOs relating to Linux, if you've got a Linux problem that you need to work out (though HOWTOs make for really boring recreational reading).

This is just what I can come up with off the top of my head, I'll probably post a reply to this when I remember more.

Also, I find that Security Focus has a huge backlog of very useful and interesting information for those concerned with computer security. In that same vein, dbaseiv.net [Google cache, the site seems to be down right now] is shaping up to be a huge repository of computer security knowledge.

The Linux Documentation Project is full of HOWTOs relating to Linux, if you've got a Linux problem that you need to work out (though HOWTOs make for really boring recreational reading).

This is just what I can come up with off the top of my head, I'll probably post a reply to this when I remember more.

Also, I find that Security Focus has a huge backlog of very useful and interesting information for those concerned with computer security. In that same vein, dbaseiv.net [Google cache, the site seems to be down right now] is shaping up to be a huge repository of computer security knowledge.

The Linux Documentation Project is full of HOWTOs relating to Linux, if you've got a Linux problem that you need to work out (though HOWTOs make for really boring recreational reading).

This is just what I can come up with off the top of my head, I'll probably post a reply to this when I remember more.

You could always RTFM:

JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness.

The short answer is because all of the planets accreted out of a disc-shaped dust cloud around the sun.

The long answer would take somebody with a better background in planetology than mine. Or a Google Search.

The mention of "156 seconds" was an oversimplified example of the kind of problem. It does happen in real streaming applications, however, especially if playing from a live source where latency constraints don't permit lengthy buffers (most important in bidirectional VoIP apps)

Of course a streaming protocol uses a buffer. That's one reason why you don't want to run it over TCP. TCP provides its own buffer, which would be redundant with the one the higher-level protocol is also creating. Optimally, one fully-informed piece of software can manage all buffers.

Streaming music over TCP (even HTTP) is fine, because the bandwidth needs are so low that suboptimal solutions work. Streaming video is different- not only is the total bandwidth more than 10x higher, but you've got two separate streams of data whose buffer sizes need to be correlated.

Essentially, if the network is stressed enough so that framedrops (underflows of the application-level buffer) ever happen, then TCP will waste time retransmitting old data, while a hand-rolled UDP solution will recover quicker . Today's popular audio-only streaming doesn't usually push enough data to cause framedrop events .

You can experimentally check that UDP is better for streaming video with applications like RealPlayer. Watch some videos with it. Then adjust your firewall to block it's UDP ports (6970+) and try again (or use the HTTP setting from inside realplayer).

I suggest you RTFPDF namely this one.

Which says nothing about hardware (and none of the others I read mentioned any change to hardware)

Also a little reading and you will discover this is just a stop gap measure untill ECN is fully deployed.

And yet more reading will produce this little gem at the bottom :-
With 9,000-byte MTU, Linux, FAST and Scalable TCP all sustained more than 2.53Gbps on a single flow between Sunnyvale and Geneva, apparently limited by the transatlantic link. HSTCP sustained 1.8Gbps in that experiment. We emphasize that these experiments are preliminary and not yet conclusive

perhaps the program uses the DNS "LOC" feature detailed in RFC1876,
although i'm finding that most of the newer installed routers are missing this location information...

perhaps it's using this as well as counting hops.

For the second problem, look at this page, section 7. Can't help you with the first, sadly...

-Brendan

We've had something superior to this for about five years now, it's called NFS, the Novell Files Shared. Get with the times people.

Besides its not just the sizes, its being able to route on them that matters. However I agree for now we have plenty of space in IPv6.

Julian.

Actually, in the future we might use up the entire IPv9 address space. Read RFC 1606.

Here's more info on JSG Boggs and a website about him.

Does this mean that RFC 3251 is just around the corner?

RMN
~~~

16: Why do many experts not think very highly of Herbert Schildt's
books?

A good answer to this question could fill a book by itself. While no book is perfect, Schildt's books, in the opinion of many gurus, seem to positively aim to mislead learners and encourage bad habits. Schildt's beautifully clear writing style only makes things worse by causing many "satisfied" learners to recommend his books to other learners.

Do take a look at the following scathing articles before deciding to buy a Schildt text.

http://www.lysator.liu.se/c/schildt.html
http://herd.plethora.net/~seebs/c/c_tcr.html

T he above reviews are admittedly based on two of Schildt's older books. However, the language they describe has not changed in the intervening period, and several books written at around the same time remain highly regarded.

The following humorous post also illustrates the general feeling towards Schildt and his books.

http://www.qnx.com/~glen/deadbeef/2764.html

Th ere is exactly one and ONLY one C book bearing Schildt's name on its cover that is at all recommended by many C experts - see Q 25.

When you say, "I only accept mail from properly configured mailservers," what you're really saying is, "I only accept mail from mailservers that are configured in the way that I want them to be." There's no spec that says that mail servers shouldn't accept and relay mail. There's no spec that says mail servers must be resolveable by reverse DNS.

These are things that, while they may or may not be wise or even reasonable, you just made up arbitrarily. Which is counter-productive and harmful.

This isn't the wild west. You don't just pick an IP address out of your ass, and twiddle random bits in packets and say "Hi! I'm sending email you must accept it because I'm so COOL!". There's a number of things you have to do, and it's all about being a responsible member of the internet community. As times change, so do the accepted best practices. This is why we don't relay mail for anyone anymore, because it's considered rude to let thugs use your house as a base to rob others.

Oh, blow it out your ass. The whole "if you don't agree with me then you're either stupid or you have an agenda" thing is unbelievably childish. Accept, instead, that I'm simply a guy with a different opinion from yours.

Well, two things. First, spam doesn't drown anybody out. All emails get the exact same attention when you read them. And secondly: huh? You have a... unique interpretation of freedom of speech.

Dude, why aren't you reading what I write? YES. Spam is a problem. It's just that blocking connections for reasons that are only circumstantially and tangentially related to spam is a WORSE problem. I really don't understand why you're not getting this. It's one thing for you to disagree with me. It's another thing entirely for you to completely misunderstand me. Get it?

I get what you're saying, it's just wrong. See, most spam comes from open relays or proxies. People who run those servers are directly contributing to spam. Why should I accept mail from a willing spammer accomplice? It's not THAT hard to lock down open relays. I've even got a box on my network that has to exist that has no anti-relay capabilities (UGH).... So I divert all inbound 25 traffic through a sendmail box first.

If someone isn't willing to do their part to keep email a viable medium for communications, I'm not willing to listen to them. Is it such a hard concept?

As for valid email from proxies/relays: No email should be coming out of a proxy server, open or otherwise. It's a hardware box, no mail queue, designed to cache webpages. Any email coming out of it is spam, period. For relays: While someone may be using the mailserver for legit mail, trust me. Once the spammers find it that box is so slammed with spam it crashes and takes out any real email that would be going through it.

When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

Perhaps the adjective "elderly" requires definition. In physics, mathematics, and astronautics it means over thirty; in the other disciplines, senile decay is sometimes postponed to the forties. There are, of course, glorious exceptions; but as every researcher just out of college knows, scientists of over fifty are good for nothing but board meetings, and should at all costs be kept out of the laboratory!

When, however, the lay public rallies round an idea that is denounced by distinguished but elderly scientists and supports that idea with great fervor and emotion -- the distinguished but elderly scientists are then, after all, probably right.

Any sufficiently advanced technology is indistinguishable from magic.

Science has NOT been able to explain everything.

It's not science's job to "explain everything." Science, unlike religion, is a process rather than a product. No scientist will ever claim that his or her work is complete. (Similarly, no scientist will ever insist that you take his or her work on faith, lest your soul burn for all eternity in some 13th-century Italian dude's idea of a bad Quake level.)

In addition, there are many open problems to evolution.

Again, we're not the ones trying to sell you all the answers to your questions. (They're free, and many of them can be found here.

This will end power shortages. We can just launch solar power plants, and download the power using EoIP.

And if there are problems with centering antennae, we could just use IPoAC.

This will end power shortages. We can just launch solar power plants, and download the power using EoIP.

And if there are problems with centering antennae, we could just use IPoAC.

That's Objective C

What do you mean, not expecting them?

Yeah, it's not like there's an RFC for that or anything.

Wouldn't know majesty if it hit him in the face...

You youngsters don't remember anything. RFC706 "On the Junk Mail Problem" was published in Nov 1975. Spam was already a problem only 4 years after RFC196, which was the original Mail Box Protocol which had no authentication.

To prevent uninformed comments about X:

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

Look here for an explanation of what Unix domain sockets are. They have nothing to do with networking and are the most efficient form of IPC on Linux. As a bonus, you can write code which uses either AF_UNIX sockets or AF_INET (TCP/IP) sockets seamlessly--but AF_UNIX sockets still have nothing to do with networking. Got it?

there are eight other posts in this thread trying to explain that X WINDOWS DOES NOT USE THE NETWORK FOR A LOCAL SERVER.

Do you hear me?

X WINDOWS DOES NOT USE THE NETWORK FOR A LOCAL SERVER.

X WINDOWS DOES NOT USE THE NETWORK FOR A LOCAL SERVER.

this would be a good place to start educating yourself.

when is the new updates comming in on the sub-etha net? I think my clone complies with the RFCs.

No it doesn't! The newest update required RFC3514 compliance to work. You need to download new firmware. Who made your Guide clone?

You're missing something that just about everyone who talks about "the limitations of SMTP" misses: SMTP isn't limited. SMTP has a standard mechanism for introducing extensions such as cryptographically certifying mail servers, and mechanisms already exist to allow for fast, distributed key recovery and verification.

Reading the RFCs is a very good start to understanding how to solve this sort of problem. Giving everyone on the Internet (or at least all of the SMTP-sources) an Identity and then actually attaching a record of trust to those identities would be a wonderful idea, and does NOT require replacing SMTP. In fact, if you do it very, very carefully, it probably doesn't even require writing any (or at least very little) new code.

You can find more information on X.500 Here, here, and here.

While not is regular use, descendants like Fortran 77 are still widely supported. (Both GNU and Microsoft sill make Fortran 77 compilers.)