>>> you create trusted network of anonymous >>How cany you both trusted and anonymous >You trust those who you are proxying for.
Just to explain a bit more - every node would serve as a client and a proxy server.
As a client it would have at least one proxy node that it would use to communicate with the network on other side of the proxy. Client obviously cannot have an anonymity with the proxy, hense it must have a trust with proxy.
Consider the example - I have a number of friends (F) I trust. These friends have their own friends (FF) that I am neither trust nor is aware of . So F nodes will be serving as proxies for all communications happening between me and FF nodes. I will not know FF's identities, they will not know mine, but this all will work only if -I trust F- and -FF trust F-. See ?
IIP2 is in the works which aims to include a completely different architecture. It will most likely be totally peer-to-peer (as in no distinction between clients, proxies, and servers; all nodes will share all roles) and incorporate a lexical routing system (addresses derived from channel or user names and routed accordingly). [snip]
It's all good, but you have to realize that there is no anonymity without proxying, and there no proxying solution without scalabilty problems. As simple as that.
IIP 'security protocol' seems to be pretty amamteurish piece of design. I might be excessively picky, but here are some points anyway:
* Excessive use of pubkey cryptography (two DH exchanges ? How about regular Master/Derived key approach ?)
* Home-brewed replay protection (see SSL/ESP for design ideas). In particular, having no explicit sequence ID in the packet may potentially allow for the replay or packet reuse.
* No packet hashing to allow discarding malformed packets without decryption (see SSL/ESP for design ideas).
* Unproven key rotation algorithm, which seems more of 'obscurity through security' thing than anything else.
* No sign of declared on the main page Perfect Forward Secrecy (PFS) in the published specs.
* Complete intolerance to minimal payload twitches (bitflips), ie heavy inter-packet dependency.
The bottom line is the protocol is very rare and can use a lot of much needed peer review.
The fine print is WHAT IS WRONG WITH SSL ?! SSL already has all the goodies (replay, rekey, authentication, etc) and it's stable and proven. It's not like IIP-CS allows to work over unreliable media or something, it's still layered over sessioned, reliable transport (TCP)... So why to reinvent the wheel ?
I've worked in VPN and P2P space for past few years and have been poking around the similar ideas for quite some time.
The basic idea is very simple - you create trusted network of anonymous -proxies- and if node sees the traffic coming from the peer it's just unable to tell if it belongs the peer or some proxied node behind it. Hense the anonymity is built into the infrastructure.
While looking at this, I got as far as putting together formal design document and protocol spec, and passed them around for the "peer review". The common problem everyone pointed out was the fact that this approach will not scale. It might be fine for IRC traffic, but it cannot and should not be applied to bulk data transfers. This is something InvisibleNet still has to realize.
It's good that they have a momentum, which may (or may not) allow them to overcome principal problems of the architecure.
What strikes me with p2p being applied to the multiplayer, it's its impracticality. Say you have N nodes. With client-server model, you'd need N connections with more-or-less acceptable data replication ratio. Now imagine p2p approach, two options here:
- fully-meshed network. Totally useless. It's not only N*(N-1)/2 connections, but also a need to replicate state of the game for each peer... this is very lame. Let's leave this option out of the picture.
- partially-meshed network, including hierarchical topologies. This is less wastful in terms of data flow and connection count, but this would mean that some nodes will be serving as proxies (or routers if you will). Such proxying node goes down - bam - all its dependent nodes are out of the game. That's not to mention that traffic_relaying=LAG. The only pro I can think of is to lessen the load on the central servers (in this case - top-level nodes that are connected directly to each other). Still I dont clearly see how this out-weights benefits of canonical client-server.
Now, having said that, I see only two interpretations to "P2P" term in the context of the multiplayer gaming:
- it implies some sort of multicast/broadcast based architecture and based on existing Ethernet/IP support. This will obviously be limited to the LAN parties. Interesting - sure, innovative - no, practical - not really.
- it's a distributed architectre that is somewhat self-organizing and provides optimal data traversal time for any two given nodes in the game. It's still not redundant (ie no loops in graf terms), but relies heavily on relaying and hierarchies. Interesting - oh, yeah, innovative - you freaking bet, practical - uhm.. perhaps, if they will be able to figure it out:)
Hense the conclusion - p2p in gaming is either not what it seems or it's a marketing hype. Sorry:)
:I think they are limiting it to 4 players because the game is so resource intensive. Anything above 4 players would be a strain on the system.
Bah! That reminds me an explanation I got from the auto technician on why my alarm remote did not work farther than from 30 feet. "Because it implements security sooooo complicated, that CPU drains the battery power in a wink". Get real.
Listen, having masters in computer graphics, I respect Mr. Carmack no less than you do. But that's not the reason to trust him on networking issues.
Problem w/ scalability and security put existing P2P developments into the class of experimental endeveours. And applying P2P to more-or-less scalable gaming environment is waaay far from the reality. It's no doubt is cool, but it's in its childhood. If to guess, that would be the primary reason Carmack limits multiplayer to 4 nodes, not because of the 'strain on the system'.
1. you resume is no good. i stopped reading after i ran into 'managed' in the last (present) job description. i forced to read it through - it's no good, you wont get a job w/ resume like this *ever*.
2. you write really well, your reply was an easy and interesting read. perhaps you should consider making living of it:)
Having worked in the subject area for some time, I can assure you that running VoIP and even video conferencing sessions over IPsec/AES tunnels results in the delay less than 1 ms on the P2-350 machines (serving as gateways on both ends).
I agree that lag may potentially become a problem as number of VoIP sessions grows, but, hey, that's what you need a hardware crypto gadgets.
* it's transport layer protocol, not an IP one. By default it runs on top of TCP, while majority of VOIP protocols do not require TCP's reliability. Needless to say that this is voids no good by any means.
* it requires reliable carrier for key establishment/renegotiation. Hence dropped and out-of-order packets will effectively break session. This means that you cant just stick SSL between V and IP layers.
You still can run SSL over unreliable layer (such as UDP or IP itself), but this will require certain protocol 'fixup' effort, which might end up be no less effort than building VoIP security from the scratch.
The simpliest solution along the lines of your suggestion would be to use IPsec and classical VPNs. Throw in IKE and you get yourself PKI-based system. It'd be somewhat pain in the arse to configure, but as a quick and dirty solution is will suffice.
They obviously haven't heard of Akamai yet
on
RIAA Smacked by DoS
·
· Score: 1
Distributed network of proxy servers specifically designed to withstand (D)DoS. FBI own servers use it, and now it looks like Akamai will be getting even more business. Good job, kids.
"The NOCC's proactive stance and unique view ensures a seamless response to network conditions - enabling Akamai to deliver rich Web content, regardless of network traffic volume."
TCP, for example, has many properties that make it undesireable for networked games.
I hear ya, but in practice it's the Nagle algorithm that renders TCP unusable for 80% of real-time gaming applications. There is a fine balance between free TCP 'sessionness' and the overhead of re-implementing and using sessions with custom over-UDP (or over-IP) protocol.
The last time I looked at it, BEEP had nice feature of automatically relating packets being sent and forth via some sort of packet ID numbers. This automatically allowed for sessions and, what's more important, it supported asynchronious request-reply paradigm. This is very common thing one need to implement when dealing w/ more-or-less complex cli-srv architecture. Server might not only be queueing client's requests, but may also comlpete them out of the order (think of RPC, for example). BEEP provides built-in support for this behavioural pattern.
Not being a huge fan of XML, I still find BEEP initiative pretty interesting, but somewhat too generic and artificial when it comes to adopting it to real-life applications.
.. they will find full 6 billion and much more. Most likely it will get financed as a defence program, and given current state of affairs and changed internal priorities, I'm sure money will be there on time.
Radio, audio and video tapes were in fact not a big danger to the sales of the quality originals. They were analog, thus copying (especially with consumer devices) depricated the quality quite a bit (remember dolby-b/c and dbx ?). Plus there were a legal 'incentives' as well as financial (cost of the tapes and second VCR, for instance) and logistical (you have to spend 2 hours of your own time to copy a movie that you may or may not watch in the future) ones for not to copy.
The 'quality' aspect is obviously not the case with digital copying, when the copy is always as good as the original. From financial/logistical perspective - well - you are all set if you can read this post, right ? It means that the copyright law is all that remains.
So, get real, Quill. This time they are freaking scared for the reason !
They are intentionally asking for something completely ridiculous, so that later on they could 'back down' and 'settle for less' - for instance, not *any* AD conversion, but only 'computer assisted' (or whatever the name it will get assigned). This is pretty common practice in any negotiations.
Slashdot Mirror
>>> you create trusted network of anonymous
>>How cany you both trusted and anonymous
>You trust those who you are proxying for.
Just to explain a bit more - every node would serve as a client and a proxy server.
As a client it would have at least one proxy node that it would use to communicate with the network on other side of the proxy. Client obviously cannot have an anonymity with the proxy, hense it must have a trust with proxy.
Consider the example - I have a number of friends (F) I trust. These friends have their own friends (FF) that I am neither trust nor is aware of . So F nodes will be serving as proxies for all communications happening between me and FF nodes. I will not know FF's identities, they will not know mine, but this all will work only if -I trust F- and -FF trust F-. See ?
IIP2 is in the works which aims to include a completely different architecture. It will most likely be totally peer-to-peer (as in no distinction between clients, proxies, and servers; all nodes will share all roles) and incorporate a lexical routing system (addresses derived from channel or user names and routed accordingly).
[snip]
It's all good, but you have to realize that there is no anonymity without proxying, and there no proxying solution without scalabilty problems. As simple as that.
>> you create trusted network of anonymous
>How cany you both trusted and anonymous
You trust those who you are proxying for.
IIP 'security protocol' seems to be pretty amamteurish piece of design. I might be excessively picky, but here are some points anyway:
... So why to reinvent the wheel ?
* Excessive use of pubkey cryptography (two DH exchanges ? How about regular Master/Derived key approach ?)
* Home-brewed replay protection (see SSL/ESP for design ideas). In particular, having no explicit sequence ID in the packet may potentially allow for the replay or packet reuse.
* No packet hashing to allow discarding malformed packets without decryption (see SSL/ESP for design ideas).
* Unproven key rotation algorithm, which seems more of 'obscurity through security' thing than anything else.
* No sign of declared on the main page Perfect Forward Secrecy (PFS) in the published specs.
* Complete intolerance to minimal payload twitches (bitflips), ie heavy inter-packet dependency.
The bottom line is the protocol is very rare and can use a lot of much needed peer review.
The fine print is WHAT IS WRONG WITH SSL ?! SSL already has all the goodies (replay, rekey, authentication, etc) and it's stable and proven. It's not like IIP-CS allows to work over unreliable media or something, it's still layered over sessioned, reliable transport (TCP)
I've worked in VPN and P2P space for past few years and have been poking around the similar ideas for quite some time.
The basic idea is very simple - you create trusted network of anonymous -proxies- and if node sees the traffic coming from the peer it's just unable to tell if it belongs the peer or some proxied node behind it. Hense the anonymity is built into the infrastructure.
While looking at this, I got as far as putting together formal design document and protocol spec, and passed them around for the "peer review". The common problem everyone pointed out was the fact that this approach will not scale. It might be fine for IRC traffic, but it cannot and should not be applied to bulk data transfers. This is something InvisibleNet still has to realize.
It's good that they have a momentum, which may (or may not) allow them to overcome principal problems of the architecure.
What strikes me with p2p being applied to the multiplayer, it's its impracticality. Say you have N nodes. With client-server model, you'd need N connections with more-or-less acceptable data replication ratio. Now imagine p2p approach, two options here:
... this is very lame. Let's leave this option out of the picture.
.. perhaps, if they will be able to figure it out :)
:)
- fully-meshed network. Totally useless. It's not only N*(N-1)/2 connections, but also a need to replicate state of the game for each peer
- partially-meshed network, including hierarchical topologies. This is less wastful in terms of data flow and connection count, but this would mean that some nodes will be serving as proxies (or routers if you will). Such proxying node goes down - bam - all its dependent nodes are out of the game. That's not to mention that traffic_relaying=LAG. The only pro I can think of is to lessen the load on the central servers (in this case - top-level nodes that are connected directly to each other). Still I dont clearly see how this out-weights benefits of canonical client-server.
Now, having said that, I see only two interpretations to "P2P" term in the context of the multiplayer gaming:
- it implies some sort of multicast/broadcast based architecture and based on existing Ethernet/IP support. This will obviously be limited to the LAN parties. Interesting - sure, innovative - no, practical - not really.
- it's a distributed architectre that is somewhat self-organizing and provides optimal data traversal time for any two given nodes in the game. It's still not redundant (ie no loops in graf terms), but relies heavily on relaying and hierarchies. Interesting - oh, yeah, innovative - you freaking bet, practical - uhm
Hense the conclusion - p2p in gaming is either not what it seems or it's a marketing hype. Sorry
:I think they are limiting it to 4 players because the game is so resource intensive. Anything above 4 players would be a strain on the system.
Bah! That reminds me an explanation I got from the auto technician on why my alarm remote did not work farther than from 30 feet. "Because it implements security sooooo complicated, that CPU drains the battery power in a wink". Get real.
Listen, having masters in computer graphics, I respect Mr. Carmack no less than you do. But that's not the reason to trust him on networking issues.
Problem w/ scalability and security put existing P2P developments into the class of experimental endeveours. And applying P2P to more-or-less scalable gaming environment is waaay far from the reality. It's no doubt is cool, but it's in its childhood. If to guess, that would be the primary reason Carmack limits multiplayer to 4 nodes, not because of the 'strain on the system'.
I have two things to say to you:
:)
1. you resume is no good. i stopped reading after i ran into 'managed' in the last (present) job description. i forced to read it through - it's no good, you wont get a job w/ resume like this *ever*.
2. you write really well, your reply was an easy and interesting read. perhaps you should consider making living of it
Having worked in the subject area for some time, I can assure you that running VoIP and even video conferencing sessions over IPsec/AES tunnels results in the delay less than 1 ms on the P2-350 machines (serving as gateways on both ends).
I agree that lag may potentially become a problem as number of VoIP sessions grows, but, hey, that's what you need a hardware crypto gadgets.
Few of them being:
* it's transport layer protocol, not an IP one. By default it runs on top of TCP, while majority of VOIP protocols do not require TCP's reliability. Needless to say that this is voids no good by any means.
* it requires reliable carrier for key establishment/renegotiation. Hence dropped and out-of-order packets will effectively break session. This means that you cant just stick SSL between V and IP layers.
You still can run SSL over unreliable layer (such as UDP or IP itself), but this will require certain protocol 'fixup' effort, which might end up be no less effort than building VoIP security from the scratch.
The simpliest solution along the lines of your suggestion would be to use IPsec and classical VPNs. Throw in IKE and you get yourself PKI-based system. It'd be somewhat pain in the arse to configure, but as a quick and dirty solution is will suffice.
Couldn't said it better myself :)
Distributed network of proxy servers specifically designed to withstand (D)DoS. FBI own servers use it, and now it looks like Akamai will be getting even more business. Good job, kids.
."
"The NOCC's proactive stance and unique view ensures a seamless response to network conditions - enabling Akamai to deliver rich Web content, regardless of network traffic volume
I hear ya, but in practice it's the Nagle algorithm that renders TCP unusable for 80% of real-time gaming applications. There is a fine balance between free TCP 'sessionness' and the overhead of re-implementing and using sessions with custom over-UDP (or over-IP) protocol.
The last time I looked at it, BEEP had nice feature of automatically relating packets being sent and forth via some sort of packet ID numbers. This automatically allowed for sessions and, what's more important, it supported asynchronious request-reply paradigm. This is very common thing one need to implement when dealing w/ more-or-less complex cli-srv architecture. Server might not only be queueing client's requests, but may also comlpete them out of the order (think of RPC, for example). BEEP provides built-in support for this behavioural pattern.
Not being a huge fan of XML, I still find BEEP initiative pretty interesting, but somewhat too generic and artificial when it comes to adopting it to real-life applications.
.. they will find full 6 billion and much more. Most likely it will get financed as a defence program, and given current state of affairs and changed internal priorities, I'm sure money will be there on time.
Too late, John Nash is already halfway through ;-)
Radio, audio and video tapes were in fact not a big danger to the sales of the quality originals. They were analog, thus copying (especially with consumer devices) depricated the quality quite a bit (remember dolby-b/c and dbx ?). Plus there were a legal 'incentives' as well as financial (cost of the tapes and second VCR, for instance) and logistical (you have to spend 2 hours of your own time to copy a movie that you may or may not watch in the future) ones for not to copy.
The 'quality' aspect is obviously not the case with digital copying, when the copy is always as good as the original. From financial/logistical perspective - well - you are all set if you can read this post, right ? It means that the copyright law is all that remains.
So, get real, Quill. This time they are freaking scared for the reason !
.. we offer wired model with transmitter implanted into any part of the body by customers choice (some restrictions apply).
Imagine blank pre-formatted brain with just a lilo in an MBR :)
it does not spread itself around **automatically** :)
- "one can use telescope to look at the sun only twice in a lifetime - with the left eye and with the right eye".
:)
I'm all for science experiments, but you've gotta know the limit, buddy
and skills. Then I'm sure it'll work out into reasonable hourly rate.
I agree that moderating this crap up is even worse than posting it.
They are intentionally asking for something completely ridiculous, so that later on they could 'back down' and 'settle for less' - for instance, not *any* AD conversion, but only 'computer assisted' (or whatever the name it will get assigned). This is pretty common practice in any negotiations.
not funny, not smart and without any point