Subject: [P2PSIP] Question about how to begin

From: "neil.young" <[email-masked]>
Date: Fri, 16 Oct 2009 15:14:20 +0200

Hi,

I recently finished the development of a CHORD implementation in C#. I 
already use a proprietary binary TCP communication protocol for the 
CHORD messages (findsuccessor, the notify and stabilize routines, the 
ping etc.). In near future I want to proceed to RELOAD, whereas the 
desired implementation does not necessarily has to have full RELOAD 
characteristics as the first result. Especially these items are not 
required initially, so that the first implementation would more be a REL 
instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start 
with best under these circumstances? 

Kind regards

---

From: jc <[email-masked]>
Date: Fri, 16 Oct 2009 14:56:33 -0400

Neil,

Start with enrollment and then move on to security and then ICE. The  
reasoning here is that you MUST have a configuration file to setup  
security and you need the security implementation to implement ICE  
Attach. This is because of where the a Node ID is stored. You will  
need to implement DNS SRV in order to implement enrollment. I used c- 
ares for testing and then implemented DNS SRV myself. I use C++ but  
surely there is DNS SRV support built into .NET?

If your looking for an easy to use and highly scalable STUN/TURN  
server that is up to date have a look at using reTurn in the  
resiprocate svn repository. There is also Numb STUN/TURN server  
however it has been obsoleted by rfc5389 and doesn't look to be worked  
on anymore. As a 2nd option there is the pjnath library as part of the  
pjsip project. You could code a C# wrapper for pjnath and use that on  
your client side for the ICE transports, of course you will have to  
implement TLS and DTLS over these yourself as TLS in pjnath is used as  
it should be in the context of TURN.

Having said that I implemented STUN/TURN and ICE myself to remove  
these dependancies but did start off using pjnath(GPL) on the client  
for ICE and reTurn on the server side. Now I shared a common code base  
between p2p code and managed server code which makes things much  
easier to maintain.

Julian

On Oct 16, 2009, at 9:14 AM, neil.young wrote:

> Hi,
>
> I recently finished the development of a CHORD implementation in C#.  
> I already use a proprietary binary TCP communication protocol for  
> the CHORD messages (findsuccessor, the notify and stabilize  
> routines, the ping etc.). In near future I want to proceed to  
> RELOAD, whereas the desired implementation does not necessarily has  
> to have full RELOAD characteristics as the first result. Especially  
> these items are not required initially, so that the first  
> implementation would more be a REL instead of RELOAD :)
>
> 1) Security
> 2) NAT traversal
> 3) ICE STUN support
> 4) Enrollment server
>
> Implementors, could you give me please some suggestions, where to  
> start with best under these circumstances?
>
> Kind regards
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: "neil.young" <[email-masked]>
Date: Fri, 16 Oct 2009 22:10:26 +0200

Hi Julian,

thanks for your detailed answer. At least one of it sound familiar :) I 
know Benny and his fin pjsip stack. We've already implemented AKA Digest 
Authentication together in the past...

However, the project I'm involved in, is more ore less a demonstrator. 
It doesn't have productive aims up to now, so we are allowed to call it 
RELOAD but let significant parts of RELOAD aside. For instance the 
parts, I've outlined in my initial post. In my limited overview I always 
treated RELOAD as "just the standardized transport for a DHT". I think I 
would be happy to have at least the basic RELOAD transport w/o 
STUN/TURN/ICE/NAT, probably also without TLS, because all of the nodes, 
participating in the overlay, are in trusted environments...

Having this in mind, wouldn't it be better to implement the basic RELOAD 
transport PDUs and means first, and let all the security and 
configuration overhead aside?

jc schrieb:
> need to implement DNS SRV in order to implement enrollment. I used 
> c-ares for testing and then implemented DNS SRV myself. I use C++ but 
>> I already use a proprietary binary TCP communication protocol for the 
>> required initially, so that the first implementation would more be a 
>> REL instead of RELOAD :)
>>
>> 1) Security
>> 2) NAT traversal
>> 3) ICE STUN support
>> 4) Enrollment server
>>
>> [email-masked] <mailto:[email-masked]>

---

From: jc <[email-masked]>
Date: Fri, 16 Oct 2009 17:41:57 -0400

I should have mentioned that one of my DHT algorithms isn't compatible  
with p2psip-base because of the hops system. This DHT implements  
Broadcast and Multicast and thus messages MAY travel well over an 8  
bit hop. A broadcast reaches N where N is equal to the total number of  
nodes in the ring and a multicast reaches N where N is the number of  
nodes participating in that multicast group as subscribed via the  
storage system. So, again this isn't a generic transport for all DHT's.

On Oct 16, 2009, at 4:10 PM, neil.young wrote:

> Hi Julian,
>
> thanks for your detailed answer. At least one of it sound  
> familiar :) I know Benny and his fin pjsip stack. We've already  
> implemented AKA Digest Authentication together in the past...
>
> However, the project I'm involved in, is more ore less a  
> demonstrator. It doesn't have productive aims up to now, so we are  
> allowed to call it RELOAD but let significant parts of RELOAD aside.  
> For instance the parts, I've outlined in my initial post. In my  
> limited overview I always treated RELOAD as "just the standardized  
> transport for a DHT". I think I would be happy to have at least the  
> basic RELOAD transport w/o STUN/TURN/ICE/NAT, probably also without  
> TLS, because all of the nodes, participating in the overlay, are in  
> trusted environments...
>
> Having this in mind, wouldn't it be better to implement the basic  
> RELOAD transport PDUs and means first, and let all the security and  
>> Start with enrollment and then move on to security and then ICE.  
>> The reasoning here is that you MUST have a configuration file to  
>> setup security and you need the security implementation to  
>> implement ICE Attach. This is because of where the a Node ID is  
>> stored. You will need to implement DNS SRV in order to implement  
>> enrollment. I used c-ares for testing and then implemented DNS SRV  
>> myself. I use C++ but surely there is DNS SRV support built  
>> into .NET?
>>
>> however it has been obsoleted by rfc5389 and doesn't look to be  
>> worked on anymore. As a 2nd option there is the pjnath library as  
>> part of the pjsip project. You could code a C# wrapper for pjnath  
>> and use that on your client side for the ICE transports, of course  
>> you will have to implement TLS and DTLS over these yourself as TLS  
>> in pjnath is used as it should be in the context of TURN.
>>
>> these dependancies but did start off using pjnath(GPL) on the  
>> client for ICE and reTurn on the server side. Now I shared a common  
>> code base between p2p code and managed server code which makes  
>> things much easier to maintain.
>>
>> Julian
>>
>>> I recently finished the development of a CHORD implementation in  
>>> C#. I already use a proprietary binary TCP communication protocol  
>>> for the CHORD messages (findsuccessor, the notify and stabilize  
>>> RELOAD, whereas the desired implementation does not necessarily  
>>> has to have full RELOAD characteristics as the first result.  
>>> Especially these items are not required initially, so that the  
>>> first implementation would more be a REL instead of RELOAD :)
>>>
>>> 1) Security
>>> 2) NAT traversal
>>> 3) ICE STUN support
>>> 4) Enrollment server
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Oct 2009 19:41:11 -0600

I might start with

1) get a minimal transport layer going with TCP
2) get a simple message parser going to deal with RELOAD messages
3) get AttachLite running to bring up a connection between two nodes
4) Fake out the bootstrap stuff and bring up  two node where one can  
send a JOIN to other
5) Add in minimal chord implementation to start managing the DHT ring
6) Initially get Chord going with no finger tables, everything just  
routes around the edge
7) add UPDATE and finger table to ring
8) add a basic data model and get it so you can store and retrieve  
some data
9) Go sleep because you have probably been up for 30 hours at this point
10) get DHT so it deal with corner cases of partition, rings with 1  
entry
11) do bootstrap
12) make configuration work
13) get enrollment to work
14) add the other data models
15) get rest of methods working
16) get security working
17) make sure you have several Tylenol's handy and go do ICE
18) invent really cool usage on top of it :-)

---

From: "neil.young" <[email-masked]>
Date: Fri, 23 Oct 2009 08:56:08 +0200

Hi Cullen,

thanks for your comment. Actually I tend to proceed with 9), because I 
already have that CHORD stuff completely, including data storage and 
retrieval, finger stuff and so on :). However, your step by step guide 
does watch the RELOAD path, which I totally left aside up to know. One 
reason: It seems to be rather instable right now; instable in the sense 
of "it is constantly changing". I already had made bad experiences with 
following a draft a couple of years ago. It was the AODV draft from the 
MANET group. So I don't want to spent too much time into things, which 
are changing quite often.

Thanks for the steps. I'll watch that.

Regards

Cullen Jennings schrieb:
> 10) get DHT so it deal with corner cases of partition, rings with 1 entry
> 11) do bootstrap