Modern CPUs have HUNDREDS of registers internally. Context switching is just changing a single byte to specify another set of registers for a different thread.
Your analysis is detailed and insightful, and at one time was a big issue. However, today's sheer clock speeds and superscalar pipelines render it far less of a burden. How fast does your OS switch contexts? every few milliseconds? "iostat" on my 1.0 Ghz Athlon t-bird says 351 cs/sec; 1.0/351 ~= 2 ms execution time per context. This is enough time for even the >>tightest>miniscule compared to the time tight loops have at their disposal. This, coupled with the fact that context switches are so carefully and constantly streamlined to be as efficient as possible, make this context switch--which was an impediment at one time--insignificant now.
If the protocol is set up such that the encrypted packet includes a nonce tied to the last transmission (say, nonce-1), then a server could at least recognize "replay" attacks like yours.
>That is something to consider, but a well >managed Windows system shouldn't have this >problem.
That's like the guy pulling out before climaxing without a condom on. It's like an SUV driver who thinks she can corner as sharply as she wants because she saw in a commercial that her SUV's computer-controlled steering is going to prevent a rollover.
In computer security (as in Project Management), failing to plan is a plan to fail. You can't rely on luck (and this is why you were spared for as long as you were, LUCK). There must be a plan on how to respond to different levels of failures (from this, you can determine the cost and downtime in advance, but that's beside my point).
Failure management is a skill that comes with experience to sysadmins. It's easy to blame irresponsible parties -- Microsoft evidently overlooked this when they raved how NT would need less or cheaper sysadmins than competing UNIX systems.
As for *responsible* parties -- I don't see that the OSS community has pushed the importance of Failure Management as much as it has stressed proper configuration. I've seen lots of encouragement for sysadmins to be paranoid (so that the system doesn't go down in the first place) but I think OSS is short on enouraging good FM techniques.
I find that the signal/slot mechanism an effective and elegant way to enhance C++'s dynamicness. In C++, as with Java, objects can only respond to messages if they or their ancestor classes respond to that message.
So say you have a C++ linked list class called "List"; you can't add any arbitrary object into the list--only objects which inherit from some basic ListElement type [1].
In Java, you can add seemingly arbitrary objects to vectors only because those objects inherit from a common Object class.
Java, C++, pascal -- That's the algol school of languages. Another school bases its OO philosophy on Simula67. Smalltalk, Objective-C, and Python's object models allow any object to respond to any message regardless of their base type (so in Python, I can add any object I want to lists) If the object is passed a message which it does not support, the runtime library or interpreter raises an exception.
QT's signals and slots mechanism extend C++'s dynamicness so that it can do the same thing as Smalltalk, Objective-C, and Python.
[1] templates are just compiler macros; they are complementary to a dynamic, polymorphic language (java is getting them, but so might in the near future). You still can't mix arbitrary types in a given instantiated template object.
--- aside: where can I get toilet paper imprinted with Microsoft source code?
Talmud has been around what, two thousand years now? From my experience it's the oldest hyperlink system known. I wonder if this could be claimed as prior art?
Why do you have to flush the pipeline?
Modern CPUs have HUNDREDS of registers internally. Context switching is just changing a single byte to specify another set of registers for a different thread.
Your analysis is detailed and insightful, and at one time was a big issue. However, today's sheer clock speeds and superscalar pipelines render it far less of a burden. How fast does your OS switch contexts? every few milliseconds? "iostat" on my 1.0 Ghz Athlon t-bird says 351 cs/sec; 1.0/351 ~= 2 ms execution time per context. This is enough time for even the >>tightest>miniscule compared to the time tight loops have at their disposal. This, coupled with the fact that context switches are so carefully and constantly streamlined to be as efficient as possible, make this context switch--which was an impediment at one time--insignificant now.
Roey
If the protocol is set up such that the encrypted packet includes a nonce tied to the last transmission (say, nonce-1), then a server could at least recognize "replay" attacks like yours.
>That is something to consider, but a well >managed Windows system shouldn't have this >problem.
That's like the guy pulling out before climaxing without a condom on. It's like an SUV driver who thinks she can corner as sharply as she wants because she saw in a commercial that her SUV's computer-controlled steering is going to prevent a rollover.
In computer security (as in Project Management), failing to plan is a plan to fail. You can't rely on luck (and this is why you were spared for as long as you were, LUCK). There must be a plan on how to respond to different levels of failures (from this, you can determine the cost and downtime in advance, but that's beside my point).
Failure management is a skill that comes with experience to sysadmins. It's easy to blame irresponsible parties -- Microsoft evidently overlooked this when they raved how NT would need less or cheaper sysadmins than competing UNIX systems.
As for *responsible* parties -- I don't see that the OSS community has pushed the importance of Failure Management as much as it has stressed proper configuration. I've seen lots of encouragement for sysadmins to be paranoid (so that the system doesn't go down in the first place) but I think OSS is short on enouraging good FM techniques.
Roey
I find that the signal/slot mechanism an effective and elegant way to enhance C++'s dynamicness. In C++, as with Java, objects can only respond to messages if they or their ancestor classes respond to that message.
So say you have a C++ linked list class called "List"; you can't add any arbitrary object into the list--only objects which inherit from some basic ListElement type [1].
In Java, you can add seemingly arbitrary objects to vectors only because those objects inherit from a common Object class.
Java, C++, pascal -- That's the algol school of languages. Another school bases its OO philosophy on Simula67. Smalltalk, Objective-C, and Python's object models allow any object to respond to any message regardless of their base type (so in Python, I can add any object I want to lists) If the object is passed a message which it does not support, the runtime library or interpreter raises an exception.
QT's signals and slots mechanism extend C++'s dynamicness so that it can do the same thing as Smalltalk, Objective-C, and Python.
[1] templates are just compiler macros; they are complementary to a dynamic, polymorphic language (java is getting them, but so might in the near future). You still can't mix arbitrary types in a given instantiated template object.
---
aside: where can I get toilet paper imprinted with Microsoft source code?
Roey
1) Java/Javascript allow this to happen, so turn it off
2) use junkbuster (http://www.junkbuster.com) to block ads from being downloaded
3) Turn off image loading.
Talmud has been around what, two thousand years now? From my experience it's the oldest hyperlink system known. I wonder if this could be claimed as prior art?