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
configuration overhead aside?
jc schrieb:
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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
