That was an idiotic comparison. It is NOT true that 99% of the time, people watching football get shitfaced.
It *IS* true that 99% of NAT machines are filtering packets and serving as a firewall, rejecting nearly all incoming connections unless perviously configured otherwise.
Guess what? Stop signs don't stop a car either. Oh, and brake pedals? Worthless, they don't stop the car either.
Hehe, I think other people who responded with exactly how many IPs would become available demostrated. 64k? Aww, hell no. Run your own internet under your existing ipv4 IP..;-)
Now, how these can be addressed? Fark if I know. DNS IMHO, wildcard to your own personal DNS in a box servers.
Corrent, it ISN'T secure. But it adds a layer. Layers are good. Think smoke screen. Sure, you can walk around in it. But it's not crystal clear untill you bump into things. It won't stop aimed bullets, but it helps with making it harder to aim.
Joe shmoe user at home has no idea what your talking about.
And you know damned right well ISP's arent going to give each house 144 distinct IPs to use. How are you going to handle addressing of this? DNS? I'd love too see every machine have a distinct DNS name as well as IP. Managing it would be hell on earth for ISPs.
Generally, a NAT/Firewall box is must more specific to it's task, and tends to have less security issues then a more generalized operating system.
Locking down a network box, from a code perspective, is easier then locking down, say, Windows XP, or, yes, even a Linux desktop.
Adding a layer does indeed add more security. That little box in the corner doesn't have my personal data to it. To get to that, you need to break into 2 machines.
That's assuming that port blocking is in place, however, which, in most cases, it is.
NAT is a *layer* of security, but not security itself.
Ok, NAT itself isn't. HOWEVER. MOST people relate NAT with a firewall performing NAT. Which is a level of security.
Nitpicking that a NAT machine is not a security measure fails to take into consideration that most people, NAT assumes some sort of firewalling taking place between the networks.
Negative. They have a patent on serializing code objects to XML and back again, but not simply reading and writing compatible XML documents. It covers objects pretty much exclusively..
How XMPP makes the IO subsystem harder doesn't make much sense too me.
It's a streamed protocol. With SMTP, HTTP, etc, you're in a stateless environment. IM conversations are statefull. It's a constant stream of data. Your client isn't connecting too any random number of servers. It's *ONE* connection.
I guess I simply dont understand why SAX based parsing leads too a more complicated IO system. You get data, you pass it along to be parsed somewhere by a SAX parser.
IF anything, by taking out the logic of dealing with a 'delivery unit', you make the IO system even SIMPLER.
What exactly is the difference between passing messages off to be incrementally parsed versus blindly storing it untill it's ready to actually be fully parsed?
If anything, this leads too a 'bursting' situation, where the processing required too 'spool' the message while waiting for it is nill, and then the bulk of the processing happens AFTER you have the message.
Basically, we're talking SAX versus DOM parsing. And in large scale systems as you've described, DOM isn't typically used, specifically do to the 'here's my message', 'parseparseparse', 'here's your 10 meg DOM tree.
You've not provided any technical reasonings why you need a framing protocol. Nearly ever existing widely used protocol has NO framing protocol associated..
SMTP? NEWP.. HTTP? NEWP..
Let me explain further. The amount of content provided over an HTTP connection doesn't always correlate directly with the size reported in the HTTP headers. Not only THAT, but it doesn't reflect the fact that sure, my document is, say, 10k, but includes links to 2000 external images, turning the once simple 10k file into a 1 meg whopper. And guess what. You don't have ANY idea untill you actually parse the HTML.
The only reason you've stated is 'it's hard'.
There are benifits of parsing data without stanza. It means you can process it real time instead of waiting for the entire message to DO something.
Slashdot Mirror
Any network that required such a device..
Is one crack asses configured network.
And I'd love to see a pure NAT device that NAT's absoutely ever single incoming and outgoing packet. ;-)
That's not a NAT, that's called a router.. *snickers*
...
That was an idiotic comparison. It is NOT true that 99% of the time, people watching football get shitfaced.
It *IS* true that 99% of NAT machines are filtering packets and serving as a firewall, rejecting nearly all incoming connections unless perviously configured otherwise.
Guess what? Stop signs don't stop a car either. Oh, and brake pedals? Worthless, they don't stop the car either.
Hehe, I think other people who responded with exactly how many IPs would become available demostrated. 64k? Aww, hell no. Run your own internet under your existing ipv4 IP.. ;-)
Now, how these can be addressed? Fark if I know. DNS IMHO, wildcard to your own personal DNS in a box servers.
Corrent, it ISN'T secure. But it adds a layer. Layers are good. Think smoke screen. Sure, you can walk around in it. But it's not crystal clear untill you bump into things. It won't stop aimed bullets, but it helps with making it harder to aim.
Joe shmoe user at home has no idea what your talking about.
And you know damned right well ISP's arent going to give each house 144 distinct IPs to use. How are you going to handle addressing of this? DNS? I'd love too see every machine have a distinct DNS name as well as IP. Managing it would be hell on earth for ISPs.
Generally, a NAT/Firewall box is must more specific to it's task, and tends to have less security issues then a more generalized operating system.
Locking down a network box, from a code perspective, is easier then locking down, say, Windows XP, or, yes, even a Linux desktop.
Adding a layer does indeed add more security. That little box in the corner doesn't have my personal data to it. To get to that, you need to break into 2 machines.
That's assuming that port blocking is in place, however, which, in most cases, it is.
NAT is a *layer* of security, but not security itself.
Ok, NAT itself isn't. HOWEVER. MOST people relate NAT with a firewall performing NAT. Which is a level of security.
Nitpicking that a NAT machine is not a security measure fails to take into consideration that most people, NAT assumes some sort of firewalling taking place between the networks.
No need for NAT with ipv6. Makes it easier for clients to be servers.
The most important change will be the fact that, when we finally actually do start transitioning to IPv6...
Hell will have frozen over.
Widespread adoption has been 'any time now' for years now..
Blah.. Just think, ipv6 gets adopted, and suddenly, all those girls who looked at the fat guys will regret saying, 'When hell freezes over'..
And when someone finds a way to inject SQL into one of your queries, who's fault is it?
;-)
You guessed it, also yours..
One of the largest benifits IMHO.
After reading the patent.. SEVERAL times.. I've come to the conclusion that this patent covers every browser on the face of the earth.
Hell, it covers HTTP!
The idea of interacting with an object embedded within a hypertext document could cover something as rudimentary as right clicking on an image..
HOW in GODS NAME could the patent office GRANT this short of stuff?
Negative. They have a patent on serializing code objects to XML and back again, but not simply reading and writing compatible XML documents. It covers objects pretty much exclusively..
How can an XML file format be incompatible with the GPL?
Does that mean we can't link them directly, or include them embedded within a binary?
It's a file format. They going to patent XML?
I'm confused.. I think he only said that for FUD factors, becouse it makes NO sense at all.
Yea, I was really excited until I noticed the resolution.
;-)
Paper like comfort *IF* the text was PRINTED using a dot matrix printer..
There *IS* one HUGE thing that would be a good thing to make it into law.
The ability for the general public to provide data for challenging of patents, up to 6 months after the patent is filed.
But then again, what's there to provide if it's changed from first to invent vs first to file..
*SSShhh!*
You're going to burst his bubble!
Well, he did, he used zlib. And he went to bed. ;-)
The INTERNET tends to route around them, but that's not the issue..
The damned stuffs still stored on hard drives, and served off of machines..
Note that they tend not to come to your house, then goto your ISP, and take your mail spool.
Nosiiree. They take your stuff.
The internet is free. As free as the wind. But it's hard to catch that when the big kid takes your damned bike..
This is relatively older news, really..
Unfortionatly, these features are making the game itself HUGE..
In the beta right now, the client download is like 3 gigs..
But I gotta admit. The end result is simply amazing compared to EQ itself..
How XMPP makes the IO subsystem harder doesn't make much sense too me.
It's a streamed protocol. With SMTP, HTTP, etc, you're in a stateless environment. IM conversations are statefull. It's a constant stream of data. Your client isn't connecting too any random number of servers. It's *ONE* connection.
I guess I simply dont understand why SAX based parsing leads too a more complicated IO system. You get data, you pass it along to be parsed somewhere by a SAX parser.
IF anything, by taking out the logic of dealing with a 'delivery unit', you make the IO system even SIMPLER.
Actually, it's been worked on for years..
I suppose you'd also like to rewrite SMTP and HTTP becouse it's text based..
What exactly is the difference between passing messages off to be incrementally parsed versus blindly storing it untill it's ready to actually be fully parsed?
If anything, this leads too a 'bursting' situation, where the processing required too 'spool' the message while waiting for it is nill, and then the bulk of the processing happens AFTER you have the message.
Basically, we're talking SAX versus DOM parsing. And in large scale systems as you've described, DOM isn't typically used, specifically do to the 'here's my message', 'parseparseparse', 'here's your 10 meg DOM tree.
You've not provided any technical reasonings why you need a framing protocol. Nearly ever existing widely used protocol has NO framing protocol associated..
SMTP? NEWP..
HTTP? NEWP..
Let me explain further. The amount of content provided over an HTTP connection doesn't always correlate directly with the size reported in the HTTP headers. Not only THAT, but it doesn't reflect the fact that sure, my document is, say, 10k, but includes links to 2000 external images, turning the once simple 10k file into a 1 meg whopper. And guess what. You don't have ANY idea untill you actually parse the HTML.
The only reason you've stated is 'it's hard'.
There are benifits of parsing data without stanza. It means you can process it real time instead of waiting for the entire message to DO something.
XMPP isn't comparible to SOAP unless your having an anal conversation. It's an XML routing and presence protocol.
For crying out loud, look at what your talking about before you decide to open your fat trap..