Refactoring NMControl's RPC API
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Refactoring NMControl's RPC API
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?
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?
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Refactoring NMControl's RPC API
It sounds good.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?
But would it have any negative implications ?
I am glad that you want to add so many new features.biolizard89 wrote:adding Freenet, CJDNS, OnionCat, GarliCat, etc.
Thoughts?
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
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
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Refactoring NMControl's RPC API
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.virtual_master wrote:It sounds good.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?
But would it have any negative implications ?
I am glad that you want to add so many new features.biolizard89 wrote:adding Freenet, CJDNS, OnionCat, GarliCat, etc.
Thoughts?
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 ?
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?
Re: Refactoring NMControl's RPC API
+1virtual_master wrote:It sounds good.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?
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Refactoring NMControl's RPC API
Than it's OK.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.
Sorry, I overviewed your question.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?
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
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
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Refactoring NMControl's RPC API
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?virtual_master wrote:Than it's OK.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.Sorry, I overviewed your question.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?
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.
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Refactoring NMControl's RPC API
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.biolizard89 wrote: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?virtual_master wrote:Than it's OK.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.Sorry, I overviewed your question.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?
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.
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:
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/
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.
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
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
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Refactoring NMControl's RPC API
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.
(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
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
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Refactoring NMControl's RPC API
I will take a look at this when I have a few minutes.
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Refactoring NMControl's RPC API
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
aMule is a cross-platform version and has also a a webinterface, TCP, UDP support
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
from WikipediaAs of August 2013, it is the second most frequently downloaded project on SourceForge, with over 665 million downloads, only behind VLC media player.[3]
aMule is a cross-platform version and has also a a webinterface, TCP, UDP support
So the integration with Namecoin domains definitely looks easier to be implemented and I think would bring more. What do you think about ?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.
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
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