So, if it has NOTHING to do with testing, then how do they know non-Intel cpus are compatible?
Tell me where Intel has ever claimed it is their job to certify compatibility of non-Intel CPUs and then I'll admit you *may* have some ground to stand on. Show me where rival companies expect Intel to certify their CPU's as Intel compatible. It is not Intel's job to test compatibility. It **IS** their job to use **THEIR OWN RECOMMENDED FEATURE SET FLAGS, PROVIDED BY THE CPU*** to test feature set support. It is up to the CPU vendor to ensure their CPUs actually support a given CPU feature set **AND** to be compatible. Until such time, I'm forced to say that you're a complete idiot, trolling...
Pull your head from your ass and figure out what the case is about. Your idiotic tangents have nothing to anything.
You sound like, "blah..blah...testing....blah...blah...Intel...bla h..."
Shesh already. Clueless.
Clearly not one who knows sznit about support, a far too common situation.
I've done everything from write test plans to front line support. I know plenty about testing. In fact, I know so much, I know this has ZERO to f'n do with testing. Pull you head from your ass and repeat it already.
LOL! I'm a professional developer...so on and so on...
The fact that your answer is to attack me with and argument that has absoluetely no relationship to the case says plenty.
Simple fact is, this has ZERO to do with testing! Say it with me! "This has ZERO to do with test!" AMD claims compatibility. If AMD does not provide it, then it's AMD's fault, not Intel's. Yet, according to you, the fact that Intel has specifically picked a slow execution path for known compatible CPU's is a matter of testing.
Please, bother to read/learn more about what's going on. Then, bother to learn how to test software. Then, learn why this has zero to do with testing!
Shesh! This has ZERO to do with testing. This has 100% to do with Intel purposely slowing the competition of compatible CPUs AND ignoring their own recommendations of "best practices". Like I said, AMD has an excellent case here!
That argument doesn't hold water. The situation is that Intel purposely runs slower code on any non-Intel CPU. All then need to do is to validate CPU capabilities, as Intel themselves recommend, and run the code based on CPU capabilities. Doing so allows maximum performance on Intel CPUs. It just so happens that on AMD CPU's, it would allow them to run faster too. In situations where AMD is slower, then shame on AMD.
In otherwords, this is a specific case of Intel **specifically** generating code to slow down all non-Intel CPU's. It has ZERO to do with compatibility concerns. In short, Intel has specifically decided to harm the performance reputation of all non-Intel CPUs. AMD has a great case here.
Where I used to live, many years ago, there was a DPS officer with a DPS 'stang. He would commonly light up his tires through parking lots as he illegally circumvented traffic lights so that he could continue speeding 60-70 in 30-45 MPH zones.
I currently know other policemen that illegally drives his motorcycle without insurance because he's a cop.
Cops tend to be one of the biggest breakers of law; only their consider themselves exempt. Cops have one of the highest rates of spousal abuse of any career, however, they have the lowest rate of being punshed. Again, big law breakers and they get away with it becaus of the "blue shield".
For some reason, people think that cops are really awesome guys. Generally speaking, they are as flakly, or more so, than the average joe they protect. Simple fact is, a lot of guys in law enforcement are there because they love having power over people. These are often the same guys that were taunted, teased, and made fun of for being social rejects.
Obviously, my comments do not apply to all cops, but we need to think real hard what we place in the hands of cops.
Once again we find a retard has a web browser and some moderation points. How fucking domb have the moderators become? Don't answer that, we all already know.
You seemed sincere and proved polite to boot. It's my pleasure; even if we fail to see eye at the end of this.;)
Base64 encoding does not happen on HTTP transfers. The only time I've seen base64 encoding used on webservers is when encoding binary data into cookies. There's obviously nothing in the HTTP spec that prevents base64 content encoding, but it would be an extension, and non-standard (not to mention almost completely useless because HTTP has no reason to be 8bit-clean).
You need to take a closer look. HTTP, in of it self, may not be 8-bit clean for a specific MIME type. But, MIME types differ and ecoding can ensue without you even knowing. Encoding can range from base64 to unicode. Simple fact is, you really never know what you're going to download when you use HTTP. That makes for a huge unknown. Remember, content can change file type to file type and even your local can effect what you get. In short, for you to say that base64 encoding does not occur on HTTP connections, is wrong. Period. Simple fact is, it MAY or MAY NOT be base64 encoding, compressed, localized, etc....it greatly depends and deferes from server to server, the server's location and configuration, the file (MIME type) you're downloading, etc. To rule it out is wrong.
Gzip (or deflate) is designed to only add 5 bytes per 32KiB (0.015%).So for large files, especially on unreliable connections, FTP has some clear benefits.
I completely agree here. Simple fact is, if you have a download fail via HTTP (happens ALOT), you are looking at using up to 199% of the origianal download bandwidth with HTTP. That's not only clear, but huge; especially for large files. I've lost count how many times I've had to restart downloads of very large files which pettered out anywhere from 40% - 95% complete via HTTP. With FTP, I stop the download, go to another mirror and resume. With HTTP, I just paid a 40%-90% overhead penalty. This is a common problem with HTTP. And, everyime you change downloads sites, chances are, you have to do a lot of navigation to get to the download, just to start it, to send up large headers all over again, to start an unknown content download, with an unknown result; which may have to start all over again. I can say, my personal best for having to resume large downloads is 6-times before I got the entire ISO. That's hardly a small difference.
This has a large effect on the perception of speed
Not really. Most time and throughput estimates tend to start high and float downward. Realistically, no one will ever the latency and as such, will have zero impact on perception.
(it gets even worse if the FTP server is [mis]configured to wait for an IDENT response before it finishes establishing the connection).
You didn't cry foul when I spoke of misconfiguration for a web site so I guess I can't cry too loud here either. Just the same, services don't use IDENT much; sve perhaps for IRC. Sure it's possible some wacky configuration may create this situation, but I'd be willing to pull a number out of my tailpipe that says a badly confiugred web server which does bad things is many order of magnitude more probable than is a ftp server which has been misconfigured to use IDENT.
I still believe that there's no meaningful overhead difference between FTP and HTTP
Feel free to do so. The simple fact is, when it comes to speed and reliability, FTP is where it's at. If you enjoy falied downloads, unknowns as to what you're actually downloading (up to 200% (unicode/local conversion) overhead + 33% (base64) of the 200%), inability to resume downloads (with costs up to 199% of the total bandwidth), by all means, continue to believe that HTTP is great for downloads. Simple fact is, HTTP is and always has been designed for many, small, synchronous downloads where failure results in clicking the, "reload", button. Realistically, that's where HTTP belo
Opps...and I forgot to add, FTP's login is done only once. The data connections do not authenticate, which is why the ports are specified as part of the transfer start.
That's what I get for typing in a hurry. Encoding = "header overhead", plus the potential for base64/language encoding, depending on the mine type. And that can vary wildly depending on http server configuration and client mime type support. As a measure of oddity potential, it's also possible to actually HTTP-gzip encode a download which is already compressed, which can actually make the download larger. Yes, that would be rare, but my point is, HTTP is largely an unknown because of so many site to site variables. HTTP has rather large headers and only handles a single file at a time. This means with HTTP, it's not unreasonable to expect an exchange of very large headers for each and every file downloaded with HTTP. Sure, you can argue a minimum HTTP header size, but even the smallest is larger than what is required for FTP; including anonymous login. On the other hand, it's not unreasonable at all to expect the headers to be fairly large, especially once you start adding in cookies and/or a put overhead request; which has become increasingly popular these days. Long story short, FTP has a known, fixed overheader. HTTP is bulky and can widly vary from download to download.
The original version of http (1.0) did not support content length. Version 1.1 does. HTTP has a long history of not being reliable (corrupt downloads, etc) because of lacking content length. Version 1.1 does greatly address this http shortcoming but does so by adding yet more header overhead. I would ahve to dig, but I believe HTTP still has some realiability concerns. Which, in turn, means the potential for yet another download.
FTP has always has native support for resuming transfers. HTTP originally did not. Version 1.1 of HTTP does allow for resuming of transfers, but is limited based on the content type and encoding (if any); so it's not always available. Futhermore, a content length is not required, even with HTTP. This is important because a lot of proxies still only support HTTP 1.0. And yes, transpartent proxies can still be in the mix.
Long story short, FTP is better for transfering files. For very small downloads, the HTTP overhead can become significant overhead. For very large files, the overhead can be pushed to background, but you still have reliability concerns (IIRC); which may require restarting the download from the beginning. About the only situation that one can argue that HTTP wins is for downloading very large files over very reliable and very, very high latency connections. In other words, that situation just does not come up in the real world. Worse, if the download is truly large, at best, you will still be on par with FTP.
One could argue that FTP has a slightly higher latency for download startup but actually has a much lower startup bandwidth demand. It is easily possible for an HTTP request to exceed a single MTU worth of data (excluding TCP/IP overhead). FTP, on the otherhand, can be initiated with less than a couple bundred bytes spread out over several packets.
Generally speaking, if speed is what you want, FTP is what you want.
You pethically funny, misinformed, and just out of touch with the real world. Feel free to wrap your self with your lies, or ignorance, and hte rest of us will deal witht the real world.
Feed to actually correct anything I was wrong about. Oh wait! I'm not wrong about anything I said but did that stop you from spreading more misinformation and general crap? Nope!
You would be 100% incorrect. HTTP has a lot of encoding overhead. A login and password is nothing. You might want to learn more about the protocols before you comment further.
Isn't evil? You've obviously never tried to set up a fairly complex networking infrastructure with multiple NATs in the mix.
The day that NAT goes away (or pushed to the minority), the world will be a better place.
As for your other comments, I think you're misinformed. Right now, IPs are a precious resource, thusly, requiring NAT. If IPs were a dime a dozen, you could have as many IPs as you like. That is, the ISPs could no longer justify charging on a per IP basis. And yes, many, many, many do. And yes, many ISPs simply will not provide for more than one per customer unless you are a business user which purchases a subnet. Long story short, that entire business model goes away because it could no longer be justified. That's the simple reality of econmics.
Long story short, I don't think you're nearly as informed on this topic as you've lead your self to believe. If you truly believe NAT has zero economic impact, then you're not equipped to participate in this thread....and my comments completely ignore the poplar method of foriegn ISPs NAT'ing their entire network because IPs are hard to come by. Meaning, you can not host anything. So on and so on...
What do you mean, the abort command "gets queue on your data socket"?!
If I said that, I meant, "the abort command gets queued on your control socket". But then again, I'm out of the original context, so I'm not 100% sure that statement was an error on my part. Said another way, if I only have one socket (one connection), and I attempt to send an abort command after I already have data queued, there may be a fairly long delay before the other side even receives my abort request because there is plenty of data already queued ahead of it. Thusly, if you place the abort command on the control socket, nothing (or little) is queued (in the IP stack) for that socket. That means, the abort command can go out right after the current packet is transmitted by the stack. End result is a MUCH faster and MUCH lower latency control interface.
What do you mean, the abort command "gets queue on your data socket"?!
It doesn't work that way. For starters, you have to explain to the remote end why you stopped sending; which ignores that data is queued. In more technical detail, the sender has already queued, in the network stack, a fair amount of data to be sent to the remote end. If you then, decided to abort and placed an abort command onto the data socket, it will only arrive after all the other already queued data arrives.
When you want to stop receiving, stop sending acks or include the abort-flag in the *next* packet that you're going to send.
FTP does not send ACK's, rather, it uses TCP. At the protocol level, where the data is already queued up, the TCP stack sends ACKs as part of the TCP protocol. FTP smartly so, relies on TCP to do it's part. Thusly, FTP has very low overhead. Most people don't realize that HTTP is fairly high overhead compared to the lean/mean FTP protocol. If bandwidth matters, FTP is still king.
Frankly I can't even imagine how a poor or high-latency link would benefit from using two tcp-connections instead of one. Maybe TCP was much different back then?
I don't think you understood the queueing (buffering) of data that takes place.
Implementing FTP the way it was is both smart (given the resources at the time) and easy to reimplement, assuring broad appeal. It obviously worked because we're still using it today!:)
That only addresses issues where you want to load balance. It does not address more general purpose issues which requires an extra IP address; hmmm, which sounds like it just defeated the entire purpose to have NAT involved in the first place.
Actually, in reality, it almost always is. See, you're creating two classes of users which ignores the whole problem. The simple fact is, there are two classes of users BECAUSE of NAT. Do away with NAT and move to IPv6, and the only difference in class should be bandswidth use.
The purpose for the design is because bandwidth was scarce; with memory following second. Thus, you have a SINGLE control socket. The data connection is not established until data needs to move. Thusly, it's VERY friendly on memory and bandwidth too. Once you need download/upload, it starts a second connection, the data connection. The great idea here is, since bandwidth was so limited, you still have a control connection to use...which is nice if you want to abort your download, etc. This means, you don't waste lots of bandwidth while your abort command gets queue on your data socket. Rather, your control command gets pushed right down, right behind the currently transmitting packet.
The implementation is actually a very good one! It's just that these days, we are so memory and bandwidth rich, no one realizes what was so elegant about the original implementation.
How in the hell did this get modded up to "3, Insightful"? I'm sorry. but please don't mod this guy up as insightful. He's WAY out there and completely ignores the entire point the poster, to which he replies, makes.
NAT IS EVIL. His argument isn't that NAT can have some security value. His point is tht NAT causes FAR more problems than it fixes. NAT is a kludge/hack to work around a problem until IPv6 can take root.
IPv6 has a lot of great additions which will go even father to address security issues. But according to you, no one needs security while at the same time, you imply NAT is great because it boosts security. What???
NAT screws a lot of things up and makes many things down right painful. There is zero reason NOT to move away from NAT and to move to stateful firewalls and IPv6. If you need security, use a dang firewall properly.
NAT causes problems for protocols which have been established for ever (FTP and CORBA) and causes problems for new technologies (video conferencing). NAT also causes social/econmic problems by artifically giving power to ISPs. If you want to provide an externally visible service, sure you can port map, but what happens if you want to provide multiple services? Ahh! But according to you, he's clueless. I think it's you that is clueless here. Simple fact is, if you want to provide mutliple services on the same external port, you are screwed. But, according to you, this is a good thing. Please, leave your candy land behind and join the rest of the networking world. NAT causes far more problems than it solves. NAT is not good. Sure, it solved a problem for us when we were running out of addresses, but it was intended to be used as a stop gap! NAT was never intended to usurp IPv6; which has happened by the likes of many short sighted and close minded network designers such as you.
Anyone that want's to continue to live in a NAT world and goes out of their way to not support IPv6 is really pretty clueless about the impact it has on the world....and I'm ignoring that ugly beast known as UPnP...which only exists because of the hack known as NAT.
Slashdot Mirror
What an idiot.
So, if it has NOTHING to do with testing, then how do they know non-Intel cpus are compatible?
Tell me where Intel has ever claimed it is their job to certify compatibility of non-Intel CPUs and then I'll admit you *may* have some ground to stand on. Show me where rival companies expect Intel to certify their CPU's as Intel compatible. It is not Intel's job to test compatibility. It **IS** their job to use **THEIR OWN RECOMMENDED FEATURE SET FLAGS, PROVIDED BY THE CPU*** to test feature set support. It is up to the CPU vendor to ensure their CPUs actually support a given CPU feature set **AND** to be compatible. Until such time, I'm forced to say that you're a complete idiot, trolling...
Pathetic, dumbass troll...
Pethetic at best.
a h..."
Pull your head from your ass and figure out what the case is about. Your idiotic tangents have nothing to anything.
You sound like, "blah..blah...testing....blah...blah...Intel...bl
Shesh already. Clueless.
Clearly not one who knows sznit about support, a far too common situation.
I've done everything from write test plans to front line support. I know plenty about testing. In fact, I know so much, I know this has ZERO to f'n do with testing. Pull you head from your ass and repeat it already.
Shesh!
Pethetic.
LOL! I'm a professional developer...so on and so on...
The fact that your answer is to attack me with and argument that has absoluetely no relationship to the case says plenty.
Simple fact is, this has ZERO to do with testing! Say it with me! "This has ZERO to do with test!" AMD claims compatibility. If AMD does not provide it, then it's AMD's fault, not Intel's. Yet, according to you, the fact that Intel has specifically picked a slow execution path for known compatible CPU's is a matter of testing.
Please, bother to read/learn more about what's going on. Then, bother to learn how to test software. Then, learn why this has zero to do with testing!
Shesh! This has ZERO to do with testing. This has 100% to do with Intel purposely slowing the competition of compatible CPUs AND ignoring their own recommendations of "best practices". Like I said, AMD has an excellent case here!
That argument doesn't hold water. The situation is that Intel purposely runs slower code on any non-Intel CPU. All then need to do is to validate CPU capabilities, as Intel themselves recommend, and run the code based on CPU capabilities. Doing so allows maximum performance on Intel CPUs. It just so happens that on AMD CPU's, it would allow them to run faster too. In situations where AMD is slower, then shame on AMD.
In otherwords, this is a specific case of Intel **specifically** generating code to slow down all non-Intel CPU's. It has ZERO to do with compatibility concerns. In short, Intel has specifically decided to harm the performance reputation of all non-Intel CPUs. AMD has a great case here.
Pethetic.
Where I used to live, many years ago, there was a DPS officer with a DPS 'stang. He would commonly light up his tires through parking lots as he illegally circumvented traffic lights so that he could continue speeding 60-70 in 30-45 MPH zones.
I currently know other policemen that illegally drives his motorcycle without insurance because he's a cop.
Cops tend to be one of the biggest breakers of law; only their consider themselves exempt. Cops have one of the highest rates of spousal abuse of any career, however, they have the lowest rate of being punshed. Again, big law breakers and they get away with it becaus of the "blue shield".
For some reason, people think that cops are really awesome guys. Generally speaking, they are as flakly, or more so, than the average joe they protect. Simple fact is, a lot of guys in law enforcement are there because they love having power over people. These are often the same guys that were taunted, teased, and made fun of for being social rejects.
Obviously, my comments do not apply to all cops, but we need to think real hard what we place in the hands of cops.
Fair enough. I still claim FTP is better and faster for transfering files. I do conceed you've made some excellent points.
Fair enough.
Thanks for a civil discussion, something rather rare here these days.
Once again we find a retard has a web browser and some moderation points. How fucking domb have the moderators become? Don't answer that, we all already know.
Fucking idiots.
Thank you for the response.
;)
You seemed sincere and proved polite to boot. It's my pleasure; even if we fail to see eye at the end of this.
Base64 encoding does not happen on HTTP transfers. The only time I've seen base64 encoding used on webservers is when encoding binary data into cookies. There's obviously nothing in the HTTP spec that prevents base64 content encoding, but it would be an extension, and non-standard (not to mention almost completely useless because HTTP has no reason to be 8bit-clean).
You need to take a closer look. HTTP, in of it self, may not be 8-bit clean for a specific MIME type. But, MIME types differ and ecoding can ensue without you even knowing. Encoding can range from base64 to unicode. Simple fact is, you really never know what you're going to download when you use HTTP. That makes for a huge unknown. Remember, content can change file type to file type and even your local can effect what you get. In short, for you to say that base64 encoding does not occur on HTTP connections, is wrong. Period. Simple fact is, it MAY or MAY NOT be base64 encoding, compressed, localized, etc....it greatly depends and deferes from server to server, the server's location and configuration, the file (MIME type) you're downloading, etc. To rule it out is wrong.
Gzip (or deflate) is designed to only add 5 bytes per 32KiB (0.015%).So for large files, especially on unreliable connections, FTP has some clear benefits.
I completely agree here. Simple fact is, if you have a download fail via HTTP (happens ALOT), you are looking at using up to 199% of the origianal download bandwidth with HTTP. That's not only clear, but huge; especially for large files. I've lost count how many times I've had to restart downloads of very large files which pettered out anywhere from 40% - 95% complete via HTTP. With FTP, I stop the download, go to another mirror and resume. With HTTP, I just paid a 40%-90% overhead penalty. This is a common problem with HTTP. And, everyime you change downloads sites, chances are, you have to do a lot of navigation to get to the download, just to start it, to send up large headers all over again, to start an unknown content download, with an unknown result; which may have to start all over again. I can say, my personal best for having to resume large downloads is 6-times before I got the entire ISO. That's hardly a small difference.
This has a large effect on the perception of speed
Not really. Most time and throughput estimates tend to start high and float downward. Realistically, no one will ever the latency and as such, will have zero impact on perception.
(it gets even worse if the FTP server is [mis]configured to wait for an IDENT response before it finishes establishing the connection).
You didn't cry foul when I spoke of misconfiguration for a web site so I guess I can't cry too loud here either. Just the same, services don't use IDENT much; sve perhaps for IRC. Sure it's possible some wacky configuration may create this situation, but I'd be willing to pull a number out of my tailpipe that says a badly confiugred web server which does bad things is many order of magnitude more probable than is a ftp server which has been misconfigured to use IDENT.
I still believe that there's no meaningful overhead difference between FTP and HTTP
Feel free to do so. The simple fact is, when it comes to speed and reliability, FTP is where it's at. If you enjoy falied downloads, unknowns as to what you're actually downloading (up to 200% (unicode/local conversion) overhead + 33% (base64) of the 200%), inability to resume downloads (with costs up to 199% of the total bandwidth), by all means, continue to believe that HTTP is great for downloads. Simple fact is, HTTP is and always has been designed for many, small, synchronous downloads where failure results in clicking the, "reload", button. Realistically, that's where HTTP belo
Opps...and I forgot to add, FTP's login is done only once. The data connections do not authenticate, which is why the ports are specified as part of the transfer start.
That's what I get for typing in a hurry. Encoding = "header overhead", plus the potential for base64/language encoding, depending on the mine type. And that can vary wildly depending on http server configuration and client mime type support. As a measure of oddity potential, it's also possible to actually HTTP-gzip encode a download which is already compressed, which can actually make the download larger. Yes, that would be rare, but my point is, HTTP is largely an unknown because of so many site to site variables. HTTP has rather large headers and only handles a single file at a time. This means with HTTP, it's not unreasonable to expect an exchange of very large headers for each and every file downloaded with HTTP. Sure, you can argue a minimum HTTP header size, but even the smallest is larger than what is required for FTP; including anonymous login. On the other hand, it's not unreasonable at all to expect the headers to be fairly large, especially once you start adding in cookies and/or a put overhead request; which has become increasingly popular these days. Long story short, FTP has a known, fixed overheader. HTTP is bulky and can widly vary from download to download.
The original version of http (1.0) did not support content length. Version 1.1 does. HTTP has a long history of not being reliable (corrupt downloads, etc) because of lacking content length. Version 1.1 does greatly address this http shortcoming but does so by adding yet more header overhead. I would ahve to dig, but I believe HTTP still has some realiability concerns. Which, in turn, means the potential for yet another download.
FTP has always has native support for resuming transfers. HTTP originally did not. Version 1.1 of HTTP does allow for resuming of transfers, but is limited based on the content type and encoding (if any); so it's not always available. Futhermore, a content length is not required, even with HTTP. This is important because a lot of proxies still only support HTTP 1.0. And yes, transpartent proxies can still be in the mix.
Long story short, FTP is better for transfering files. For very small downloads, the HTTP overhead can become significant overhead. For very large files, the overhead can be pushed to background, but you still have reliability concerns (IIRC); which may require restarting the download from the beginning. About the only situation that one can argue that HTTP wins is for downloading very large files over very reliable and very, very high latency connections. In other words, that situation just does not come up in the real world. Worse, if the download is truly large, at best, you will still be on par with FTP.
One could argue that FTP has a slightly higher latency for download startup but actually has a much lower startup bandwidth demand. It is easily possible for an HTTP request to exceed a single MTU worth of data (excluding TCP/IP overhead). FTP, on the otherhand, can be initiated with less than a couple bundred bytes spread out over
several packets.
Generally speaking, if speed is what you want, FTP is what you want.
You get a cookie for actually knowing what you're talking about. Around here, that's rare! Congrats! :)
LOL!
You pethically funny, misinformed, and just out of touch with the real world. Feel free to wrap your self with your lies, or ignorance, and hte rest of us will deal witht the real world.
Feed to actually correct anything I was wrong about. Oh wait! I'm not wrong about anything I said but did that stop you from spreading more misinformation and general crap? Nope!
You would be 100% incorrect. HTTP has a lot of encoding overhead. A login and password is nothing. You might want to learn more about the protocols before you comment further.
Isn't evil? You've obviously never tried to set up a fairly complex networking infrastructure with multiple NATs in the mix.
...and my comments completely ignore the poplar method of foriegn ISPs NAT'ing their entire network because IPs are hard to come by. Meaning, you can not host anything. So on and so on...
The day that NAT goes away (or pushed to the minority), the world will be a better place.
As for your other comments, I think you're misinformed. Right now, IPs are a precious resource, thusly, requiring NAT. If IPs were a dime a dozen, you could have as many IPs as you like. That is, the ISPs could no longer justify charging on a per IP basis. And yes, many, many, many do. And yes, many ISPs simply will not provide for more than one per customer unless you are a business user which purchases a subnet. Long story short, that entire business model goes away because it could no longer be justified. That's the simple reality of econmics.
Long story short, I don't think you're nearly as informed on this topic as you've lead your self to believe. If you truly believe NAT has zero economic impact, then you're not equipped to participate in this thread.
What do you mean, the abort command "gets queue on your data socket"?!
:)
If I said that, I meant, "the abort command gets queued on your control socket". But then again, I'm out of the original context, so I'm not 100% sure that statement was an error on my part. Said another way, if I only have one socket (one connection), and I attempt to send an abort command after I already have data queued, there may be a fairly long delay before the other side even receives my abort request because there is plenty of data already queued ahead of it. Thusly, if you place the abort command on the control socket, nothing (or little) is queued (in the IP stack) for that socket. That means, the abort command can go out right after the current packet is transmitted by the stack. End result is a MUCH faster and MUCH lower latency control interface.
What do you mean, the abort command "gets queue on your data socket"?!
It doesn't work that way. For starters, you have to explain to the remote end why you stopped sending; which ignores that data is queued. In more technical detail, the sender has already queued, in the network stack, a fair amount of data to be sent to the remote end. If you then, decided to abort and placed an abort command onto the data socket, it will only arrive after all the other already queued data arrives.
When you want to stop receiving, stop sending acks or include the abort-flag in the *next* packet that you're going to send.
FTP does not send ACK's, rather, it uses TCP. At the protocol level, where the data is already queued up, the TCP stack sends ACKs as part of the TCP protocol. FTP smartly so, relies on TCP to do it's part. Thusly, FTP has very low overhead. Most people don't realize that HTTP is fairly high overhead compared to the lean/mean FTP protocol. If bandwidth matters, FTP is still king.
Frankly I can't even imagine how a poor or high-latency link would benefit from using two tcp-connections instead of one. Maybe TCP was much different back then?
I don't think you understood the queueing (buffering) of data that takes place.
Implementing FTP the way it was is both smart (given the resources at the time) and easy to reimplement, assuring broad appeal. It obviously worked because we're still using it today!
Thanks for the clarification. I understand where you're coming from now.
Also, I noticed that I said, "several". That shoud actually read, "a couple".
Fair enough. Thanks!
Thanks for the clarification. I understand where you're coming from now.
Also, I noticed that I said, "several". That shoud actually read, "a couple".
Fair enough. Thanks!
Wow! The mods have proved that they are absolute idiots! My post was topical and exact. Offtopic?! How stupid are these moderators these day?!?!
What morons!
That only addresses issues where you want to load balance. It does not address more general purpose issues which requires an extra IP address; hmmm, which sounds like it just defeated the entire purpose to have NAT involved in the first place.
That's hardly a showstopper.
Actually, in reality, it almost always is. See, you're creating two classes of users which ignores the whole problem. The simple fact is, there are two classes of users BECAUSE of NAT. Do away with NAT and move to IPv6, and the only difference in class should be bandswidth use.
Actually, it's not that wasteful at all.
The purpose for the design is because bandwidth was scarce; with memory following second. Thus, you have a SINGLE control socket. The data connection is not established until data needs to move. Thusly, it's VERY friendly on memory and bandwidth too. Once you need download/upload, it starts a second connection, the data connection. The great idea here is, since bandwidth was so limited, you still have a control connection to use...which is nice if you want to abort your download, etc. This means, you don't waste lots of bandwidth while your abort command gets queue on your data socket. Rather, your control command gets pushed right down, right behind the currently transmitting packet.
The implementation is actually a very good one! It's just that these days, we are so memory and bandwidth rich, no one realizes what was so elegant about the original implementation.
How in the hell did this get modded up to "3, Insightful"? I'm sorry. but please don't mod this guy up as insightful. He's WAY out there and completely ignores the entire point the poster, to which he replies, makes.
...and I'm ignoring that ugly beast known as UPnP...which only exists because of the hack known as NAT.
NAT IS EVIL. His argument isn't that NAT can have some security value. His point is tht NAT causes FAR more problems than it fixes. NAT is a kludge/hack to work around a problem until IPv6 can take root.
IPv6 has a lot of great additions which will go even father to address security issues. But according to you, no one needs security while at the same time, you imply NAT is great because it boosts security. What???
NAT screws a lot of things up and makes many things down right painful. There is zero reason NOT to move away from NAT and to move to stateful firewalls and IPv6. If you need security, use a dang firewall properly.
NAT causes problems for protocols which have been established for ever (FTP and CORBA) and causes problems for new technologies (video conferencing). NAT also causes social/econmic problems by artifically giving power to ISPs. If you want to provide an externally visible service, sure you can port map, but what happens if you want to provide multiple services? Ahh! But according to you, he's clueless. I think it's you that is clueless here. Simple fact is, if you want to provide mutliple services on the same external port, you are screwed. But, according to you, this is a good thing. Please, leave your candy land behind and join the rest of the networking world. NAT causes far more problems than it solves. NAT is not good. Sure, it solved a problem for us when we were running out of addresses, but it was intended to be used as a stop gap! NAT was never intended to usurp IPv6; which has happened by the likes of many short sighted and close minded network designers such as you.
Anyone that want's to continue to live in a NAT world and goes out of their way to not support IPv6 is really pretty clueless about the impact it has on the world.
Which is exactly why the grandparent poster is either clueless or completely missed the boat about this entire thread.
LOL! Wish I had the mod points to spend. Good one.