Refactoring NMControl's RPC API

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Refactoring NMControl's RPC API

Post by biolizard89 »

So, I have some scalability concerns about NMControl's RPC API for the d/ namespace.

Right now, if a client wants to know how a domain resolves, it would call one of the following: getIp4, getIp6, getOnion, or getIp2_b32. If the client supports all 4 resolvers, it has to make 4 RPC calls to find out which one the domain supports. As the number of resolvers increases (e.g. adding Freenet, CJDNS, OnionCat, GarliCat, etc.), the number of RPC calls increases.

I propose adding a new RPC call to NMControl, called getAddress. Example usage:

./nmcontrol dns getAddress example.bit Ip4 Ip6 Onion I2p_b32

This syntax causes getIp4, getIp6, getOnion, and getI2p_b32 to be called in sequence, returning the first positive result.

This reduces complexity and latency for clients.

Thoughts?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Refactoring NMControl's RPC API

Post by virtual_master »

biolizard89 wrote:So, I have some scalability concerns about NMControl's RPC API for the d/ namespace.

Right now, if a client wants to know how a domain resolves, it would call one of the following: getIp4, getIp6, getOnion, or getIp2_b32. If the client supports all 4 resolvers, it has to make 4 RPC calls to find out which one the domain supports. As the number of resolvers increases (e.g. adding Freenet, CJDNS, OnionCat, GarliCat, etc.), the number of RPC calls increases.

I propose adding a new RPC call to NMControl, called getAddress. Example usage:

./nmcontrol dns getAddress example.bit Ip4 Ip6 Onion I2p_b32

This syntax causes getIp4, getIp6, getOnion, and getI2p_b32 to be called in sequence, returning the first positive result.

This reduces complexity and latency for clients.

Thoughts?
It sounds good. :)
But would it have any negative implications ?
biolizard89 wrote:adding Freenet, CJDNS, OnionCat, GarliCat, etc.
Thoughts?
I am glad that you want to add so many new features.
Just some ideas and questions.
This super secret layers OnionCat and GarliCat over Tor and I2P wouldn't be an overkill at the moment ? They have 2-30 s ping time.
Wouldn't be RetroShare a more speedy and more scalable alternative ? And it could be integrated in a similar way.
RetroShare if used over IP is very quick and can be used for music or film streaming. And the most people just want to listen some music or watch films without being persecuted by copyright trolls. It can be used over a VPN and in the actual beta can be used as layer over Tor also, so it would work like OnionCat for super-secret communications.
What about an eMule integration ? Wouldn't bring more user and popularity ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Refactoring NMControl's RPC API

Post by biolizard89 »

virtual_master wrote:
biolizard89 wrote:So, I have some scalability concerns about NMControl's RPC API for the d/ namespace.

Right now, if a client wants to know how a domain resolves, it would call one of the following: getIp4, getIp6, getOnion, or getIp2_b32. If the client supports all 4 resolvers, it has to make 4 RPC calls to find out which one the domain supports. As the number of resolvers increases (e.g. adding Freenet, CJDNS, OnionCat, GarliCat, etc.), the number of RPC calls increases.

I propose adding a new RPC call to NMControl, called getAddress. Example usage:

./nmcontrol dns getAddress example.bit Ip4 Ip6 Onion I2p_b32

This syntax causes getIp4, getIp6, getOnion, and getI2p_b32 to be called in sequence, returning the first positive result.

This reduces complexity and latency for clients.

Thoughts?
It sounds good. :)
But would it have any negative implications ?
biolizard89 wrote:adding Freenet, CJDNS, OnionCat, GarliCat, etc.
Thoughts?
I am glad that you want to add so many new features.
Just some ideas and questions.
This super secret layers OnionCat and GarliCat over Tor and I2P wouldn't be an overkill at the moment ? They have 2-30 s ping time.
Wouldn't be RetroShare a more speedy and more scalable alternative ? And it could be integrated in a similar way.
RetroShare if used over IP is very quick and can be used for music or film streaming. And the most people just want to listen some music or watch films without being persecuted by copyright trolls. It can be used over a VPN and in the actual beta can be used as layer over Tor also, so it would work like OnionCat for super-secret communications.
What about a GnuNet integration ? Wouldn't bring more user and popularity ?
No negative implications that I can think of. Clients would still need to know the names of the resolvers, but that's the same as it is currently. I'm bringing it up because I'm hoping other people will find any negative implications I've overlooked. ;)

My understanding is that OnionCat and GarliCat have a long initial latency due to circuit construction (or whatever the I2P equivalent is), but after that the ping is usable. Supposedly people have done voice chat without problems.

In any event anything that operates via an HTTP/HTTPS/SOCKS proxy, or an IPv6 mapping, should be usable without too much effort; it's basically just a matter of adding a few lines of code to NMControl and another few lines of code to the client (e.g. FreeSpeechMe). I'm not very familiar with RetroShare and GnuNet yet, although I'll be doing some work with RetroShare for a school project soon. Are those protocols usable via a proxy or an IPv6 mapping, or is it more complicated?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Refactoring NMControl's RPC API

Post by phelix »

virtual_master wrote:
biolizard89 wrote:So, I have some scalability concerns about NMControl's RPC API for the d/ namespace.

Right now, if a client wants to know how a domain resolves, it would call one of the following: getIp4, getIp6, getOnion, or getIp2_b32. If the client supports all 4 resolvers, it has to make 4 RPC calls to find out which one the domain supports. As the number of resolvers increases (e.g. adding Freenet, CJDNS, OnionCat, GarliCat, etc.), the number of RPC calls increases.

I propose adding a new RPC call to NMControl, called getAddress. Example usage:

./nmcontrol dns getAddress example.bit Ip4 Ip6 Onion I2p_b32

This syntax causes getIp4, getIp6, getOnion, and getI2p_b32 to be called in sequence, returning the first positive result.

This reduces complexity and latency for clients.

Thoughts?
It sounds good. :)
+1
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Refactoring NMControl's RPC API

Post by virtual_master »

biolizard89 wrote: My understanding is that OnionCat and GarliCat have a long initial latency due to circuit construction (or whatever the I2P equivalent is), but after that the ping is usable. Supposedly people have done voice chat without problems.
:) Than it's OK.
biolizard89 wrote: I'm not very familiar with RetroShare and GnuNet yet, although I'll be doing some work with RetroShare for a school project soon. Are those protocols usable via a proxy or an IPv6 mapping, or is it more complicated?
Sorry, I overviewed your question.
I know them also only as user.
Retroshare connections are working via proxy also but not with IPv6 in the actual 0.5.5.c version.
However IPv6 support is planned for version 0.6 which may come out this year.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Refactoring NMControl's RPC API

Post by biolizard89 »

virtual_master wrote:
biolizard89 wrote: My understanding is that OnionCat and GarliCat have a long initial latency due to circuit construction (or whatever the I2P equivalent is), but after that the ping is usable. Supposedly people have done voice chat without problems.
:) Than it's OK.
biolizard89 wrote: I'm not very familiar with RetroShare and GnuNet yet, although I'll be doing some work with RetroShare for a school project soon. Are those protocols usable via a proxy or an IPv6 mapping, or is it more complicated?
Sorry, I overviewed your question.
I know them also only as user.
Retroshare connections are working via proxy also but not with IPv6 in the actual 0.5.5.c version.
However IPv6 support is planned for version 0.6 which may come out this year.
What I'm asking is, do they accept SOCKS/HTTP proxy connections for general TCP/UDP/HTTP usage? Put another way, are they addressing schemes for generic network traffic, or are they network application protocols? IP, .onion, and .b32.i2p are addressing schemes that I can direct traffic to. Are RetroShare and GnuNet like that?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Refactoring NMControl's RPC API

Post by virtual_master »

biolizard89 wrote:
virtual_master wrote:
biolizard89 wrote: My understanding is that OnionCat and GarliCat have a long initial latency due to circuit construction (or whatever the I2P equivalent is), but after that the ping is usable. Supposedly people have done voice chat without problems.
:) Than it's OK.
biolizard89 wrote: I'm not very familiar with RetroShare and GnuNet yet, although I'll be doing some work with RetroShare for a school project soon. Are those protocols usable via a proxy or an IPv6 mapping, or is it more complicated?
Sorry, I overviewed your question.
I know them also only as user.
Retroshare connections are working via proxy also but not with IPv6 in the actual 0.5.5.c version.
However IPv6 support is planned for version 0.6 which may come out this year.
What I'm asking is, do they accept SOCKS/HTTP proxy connections for general TCP/UDP/HTTP usage? Put another way, are they addressing schemes for generic network traffic, or are they network application protocols? IP, .onion, and .b32.i2p are addressing schemes that I can direct traffic to. Are RetroShare and GnuNet like that?
As I wrote I have only user level knowledge for both but from what I have looked now in the documentation I hope my answer will be this time what you expect.

UDP, TCP and HTTP is supported by both Retroshare and GnuNet.
Here you see a short comparison of GnuNet woth otherP2P networks:
https://gnunet.org/compare
Port Forwarding as I understood from the GnuNet documentation is supported.
By Retroshare there is an option in the menu by server options to "Manually Forwarded Port" mod so I guess it is also supported.
Here is a design overview how it is built:
Image

More:
- they are some plugins for Retroshare so if they can connect to it then it must work for Namecoin also
WEB Interface RetroFlux
- As I see somebody already built a web interface for Retroshare:
http://sourceforge.net/projects/retroflux/
Image
Now if a browser can connect to it I cannot see why shouldn't be able a browser with freespeach plugin also. ;)
So connecting from a .bit domain to a RetroShare network.
At least theoretically. But practically there could be always some difficulties like it is the case by the Tor browser. :D
But I am sure you are able to master them. :)

However it is logic if you already have the knowledge for other networks you make them first.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Refactoring NMControl's RPC API

Post by virtual_master »

Another, Django based RetroShare Web interface:
(it seems to be the official one)
https://github.com/drbob/djrs
---------------
And it seems that there is a Gnunet web interface also:
https://gitorious.org/gnunet-webui/
or at least it is in work, i am not sure.
------------
So it seems that the answer on your question, Jeremy, is YES, it is possible to redirect data to them.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Refactoring NMControl's RPC API

Post by biolizard89 »

I will take a look at this when I have a few minutes.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Refactoring NMControl's RPC API

Post by virtual_master »

Researching more about.
GnuNet:
The link what I provided for the webinterface I think it is still a non-realized project and building a webinterface is discouraged(as I read) by the development team to better keep the secretive nature of the network. It is also a high latency network.
Freenet at least already has a web surface and will be easier to implement the access.
So I guess implementing GnuNet would require more effort and I would postpone it. Maybe in cooperation with their developers would be better if they wish it.

eMule/aMule - access to the Kad and eDonkey network:
This would be the most desirable as it has a low latency and much more user base and would bring more popularity for Namecoin.
eMule is only for Windows but
As of August 2013, it is the second most frequently downloaded project on SourceForge, with over 665 million downloads, only behind VLC media player.[3]
from Wikipedia
aMule is a cross-platform version and has also a a webinterface, TCP, UDP support
aMuleWEB
The web interface provided by the aMule core built-in Webserver. It can be Retrieved the LAN or from the Internet, provided that any Internet router is properly configured using port forwarding.
So the integration with Namecoin domains definitely looks easier to be implemented and I think would bring more. What do you think about ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

Post Reply