The importance of peer to peer communication cannot be played down.
Recently , I was thinking about how to make file transfer more efficient and p2p hit the top of the list.
Assuming you do not want to filter the client traffic at the server side , it remarkedly reduces the load and even cost at the server side if the individual clients can transfer the content directly to their peers.
The major problem with this approach is that , most users nowadays are increasingly getting connected to the internet through NAT's. This prevent's one client to establish a direct connection to the other - since it cannot reach it directly !
I am not very sure of what the solutions are in this space to continue to use p2p , but the following solution looks interesting.
It basically uses
STUN to establish a p2p session : a straightforward application of the rfc in some ways actually ... and I would expect this , or better solutions to be quite widely deployed already.
The basic idea is something like this :
You have three entities : client a , client b and the service provider's STUN server on public internet (which could also be the protocol host).
The actual protocol that the server and client's use to talk to each other could be anything ...
Initially , neither client a nor client b what type of NAT they are behind , or even if they are behind a NAT it is in the first place !
Both clients find out what type of NAT they are behind using STUN (section 8 , 9 and 10 of spec).
Now , over their existing protocol , the client's will exchange the obtained information with each other (if two way communication is to be attempted or only the p2p host will transmit this to the p2p client).
Once this is done , the p2p client will transmit udp datagrams to the p2p host with the 'packet from' set to what the STUN server used and the destination being the internet side of the discovered IP/port for the p2p server host (I am not sure if this is allowed in all/any case - assuming you can do it) ....
And voila ! You have p2p transfer happening over udp.
You will ofcourse need to renegotiate in case the binding lifetime is low , etc ... minor enhancements and essentially implementation details.
Have I implemented this before lecturing about it ? No ....
But it felt like a good idea - thought people who are really in this field (cisco friends , hint hint ;-) ) can comment better.
It is very much possible that this is a solved problem , with the solution being something infinitely better than what I describe above (or maybe this is the solution and I just did not get to that part of the spec/skipped that) - or maybe I am talking zilch and am exhibiting a markedly high degree of ignorance of my networking knowledge (or lack of it).
RTFM's and links welcome !
2 Comments:
Mridul, thanks!
How are you doing? Happy Onam to you too!
I was extremely pleased to find this website. I wanted to thank you for this good knowledge and I definitely enjoying every single small bit of it and I am looking forward to check out new stuff you post.
Post a Comment
<< Home