I'm writing a web application using Ethereum at the moment and realize only now that I have to specific a web3.provider's IP address to tap into the blockchain.
If I have to specify an IP address, how are web apps. (dApps) considered decentralized?
I recognize the data may be ... but the utility of the dApp itself is null if the user doesn't have a frontend tap.
So my question is, from a technical perspective, how do I dynamically grab an IP address to an Ethereum node w/o using some sort of centralized DNS platform?
ENS (the Ethereum Name Service) appears to work similarly to centralized DNS platforms as you need a resolver to get the resource.
What you need to know is that you should not connect your dapp to an IP. You and ever other user will are supposed to connect to a different node. So, it is the user who will connect to a node. The user will be connect to a local or remote node of his/here choice. For you as a developer, when you will be sure that any user connected to a healthy node, he will be using the same version of the dapp.
Note: local nodes can be Geth and Parity nodes connected to main-net. And remote nodes can be the nodes that MetaMask connects to (MetaMask uses infura.io).
Note: If you will force your users to connect to a specific IP, you cannot call your app 'decentralized'.
Related
I have a confusion. When i try to access the services like mysql that are externally hosted or outside the cluster, what will be the source address of the packet that are sent to mysql. To make it simple while creating user in mysql for the api to access it, how do i create it?
For example:
CREATE USER 'newuser'#'IP or HOSTNAME' IDENTIFIED BY 'user_password';
What should be the IP? the pod IP or the host IP?
Is there any way through which if the pod is spawn in any node but it can authenticate against mysql?
Thank You
When accessing services outside the kubernetes cluster the source IP will be the regular IP of the node, the application is running on.
So there is no difference if you run the application directly on the node ("metal") or inside a container.
Kubernetes will select an appropriate node to schedule the container (pod) to, so this might change during the lifetime.
If you want to increase the security you should investigate TLS with mutual authentication in addition to the password. The source IP is not the best course of action for dynamic environments like cloud or kubernetes.
I have a MySQL database running on my raspberry pi.
To access it I use dynamic DNS (duckdns) when I am outside of my network, but I would like to access it with same dynamic domain name when I am inside my network. However it is not working and I always get connection refused.
I would like somehow enable it so I do not have to change in app.config MySQL server address from my dynamic domain to localhost when I am inside my local network.
You'll need a gateway router that supports NAT hairpinning. Many consumer-grade units (and some supposedly commercial-grade equipment) doesn't support this. Either yours doesn't, or you need to find an option to enable it.
When you try to connect to the public IP address from inside the network, the router probably assumes that you want to connect to the router itself.
My cable modem's built-in router at home understands how to do this. When I access my server from the laptop, and connect to the public IP from inside, the router (inside the cable modem) does a transformation on the packets so that my server sees my connection coming from the router's IP address, not my laptop's IP address.
This is what has to happen, because when the server responds, it will respond to the machine that connected to it. If it responded to the laptop's address, the laptop would reject the traffic, since it would be coming from ther server's internal IP, which is not the IP address I connected to. So, it responds to the router, which does a second transform on the packet address, replacing the server's internal IP with the external IP. Remembering the session from previous traffic, the router then sends the packet back to the laptop.
Ultimately this setup can't possibly work for you without the complicity of your router, which may not have that capability.
Some routers, however, have a DNS proxy that will allow you to create static entries. My former DSL modem could not hairpin NAT connections, but it had a way to create DNS entries that would be used to respond to internal DNS queries for a specific host... with a different IP than the one that DNS otherwise provided. That's an alternative workaround if the router supports it.
I have deployed a hadoop cluster on google compute engine. I then run a machine learning algorithm (Cloudera's Oryx) on the master node of the hadoop cluster. The output of this algorithm is accessed via an HTTP REST API. Thus I need to access the output either by a web browser, or via REST commands. However, I cannot resolve the address for the output of the master node which takes the form http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091.
I have allowed http traffic and allowed access to ports 80 and 8091 on the network. But I cannot resolve the address given. Note this http address is NOT the IP address of the master node instance.
I have followed along with examples for accessing IP addresses of compute instances. However, I cannot find examples of accessing a single node of a hadoop cluster on GCE, that follows this form http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091. Any help would be appreciated. Thank you.
The reason you're seeing this is that the "HOSTNAME.c.PROJECT.internal" name is only resolvable from within the GCE network of that same instance itself; these domain names are not globally visible. So, if you were to SSH into your master node first, and then try to curl http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091 then you should successfully retrieve the contents, whereas trying to access from your personal browser will just fail to resolve that hostname into any IP address.
So unfortunately, the quickest way for you to retrieve those contents is indeed to use the external IP address of your GCE instance. If you've already opened port 8091 on the network, simply use gcutil getinstance CLUSTER_NAME-m and look for the entry specifying external IP address; then plug that in as your URL: http://[external ip address]:8091.
If you turned up the cluster using bdutil, a more involved but nicer way to access your cluster is by running the bdutil socksproxy command. This opens a dynamic-port-forwarding SSH tunnel to your master node as a SOCKS5 proxy, so that you can then configure your browser to use localhost:1080 as your proxy server, make sure to enable remote DNS resolution, and then visit your browser using the normal http://CLUSTER_NAME-m.c.PROJECT_NAME.internal:8091 URL.
We have developed a client app and a server app. The client communicates with the server using the http protocol and sends some data to be processed by the server.
Our structure allow us to have the server installed anywhere. I can be on the same client network or even on the cloud.
When the server is hosted on the cloud, it makes sense asking the user for the server address (since it can change if the user wishes to) but it does not make sense when the server is on the same network that the client. Besides that, we are currently asking users to configure the server ip/name in order to connect to the server.
To avoid this (asking users for the address) I have developed a discovery service based on UDP. The client broadcasts a message that the server answer with its address. It does work on some cases, but it does not when the user has some kind of firewall, proxy or even an anti virus.
I have read a lot about discovery services, and the one that a like most is Bonjour.
So, the question is: what is the best way of discovering a server's IP when the server is on the same network that the client without being blocked by firewalls, proxies, etc?
You can keep your service purely local (in the intranet) and build on top of what you are using now by implementing hole punching. You can get past firewalls, but Im really not sure about AV software policies.
Or you can establish a well-known http-based discovery service in the internet.
A server comes alive, sends its (local) ip address to the discovery service (keeps sending keep-alives)
On startup, the client queries that discovery service, identifies the local subnet he is in, and gets back the local ip address of the server.
That of course creates a single point of failure in your system in that if the discovery service kicks the bucket, your clients cannot find servers. You can remedy that by replicating the service and/or introducing fallback mechanisms (like the purely local discovery you have), which you probably want to do anyway. The only problem you might have is the subnet identification, if computers in local subnets dont share external IP addresses (then it depends on what a local subnet is for you).
i am creating an application with client-server architecture in java. What i am trying to achieve is a simple client-server architecture connected via LAN with a ethernet switch, the server is having a server module of application running and also having MySQL database, the clients do their processing and submit results on server database, database also used for authentication.
the Server would be the only machine in network that will be connected to WAN through any ISP, the IP address of server machine cannot be guaranteed to be static, in this condition how the clients may connect to the server database? As the IP address of server is fluid..
One more doubt is that i've to authenticate the clients also on the basis of there IP addresses (or it may also be physical MAC address, if simple to implement), i've a table in database that the server admin can update and stores the IP addresses of valid clients, now on connecting via LAN what will be the IP addresses allocated to the machines to be stored in database and will they be static? i've googled for this but did not found relevant answers...
I hope i am clear with my question .I am sorry if the question is not related to stackoverflow,but it contains programming with database and networking too.
Thanks.
As I see it you have a few separate problems:
1. The IP addresses on the client machine are probably NOT static - a very high proportion of users are allocated dynamic addresses by their ISPs
2. There is no way to reliably connect to your Server as it has no static IP address.
The first problem can be solved by using the MAC address as you suggest (although this is easy to spoof if an attacker wants to) or some locally stored access keys.
The second is much more difficult (and really the reason why we have static IP addresses) - you need to use a VPN or some kind of forwarding service which does have a fixed IP afaik.