I'm writing a chord netowrk on my LAN (the node key is an hash of the IP)
I read many articles about Chord network
but I didn't figure it out:
when a new client want to join the network, it must know another client in the network
or some kind of server to manage a new client joining.
am I right?
Yes, when joining a DHT network, you must know at least one other node in the network you can announce yourself to.
Related
If bloackchain is designed to be decentralized, how a node can know the IP of at least one node of the blockchain in order to start communicating.
For example, if a bloackchain still does not have any node, and you add the first node of the network, when the second node is added, how does that node know the IP of the first node and vice versa?
Nodes can broadcast their presence on a predefined port and in a predefined message format. Other nodes can be listening on this port, so that they "catch" the message from a new node (broadcasting their presence).
Some clients also have a predefined list of trusted nodes that are usually maintained by the network core development team or some other trusted groups, so that the client doesn't have to wait for other nodes to broadcast their presence and can communicate with these trusted nodes right away.
I have a spare router lying around. In our house, we’re using our landlords WiFi and we’re a bit sketched out to allow them to read all our visited websites and whatnot.
So there are basically two ideas.
A) use one of the many VPNs to undermine this
B) (and this would be easier for having guests for example,) setting up a second router to basically mimic a repeater but with a layer of encryption. Would that work?
Could we connect to this second WiFi network, encrypt every data package, so our landlord doesn’t get to read anything?
Thanks for every input/idea!
A) use one of the many VPNs to undermine this
Yes, effectively this is the only way
B)... setting up a second router to basically mimic a repeater but with a layer of encryption.
Point B alone won't give you full privacy without point A. I mean - even with an additional router it's posible to see DNS queries (dnssec is still not common) and target IP addresses.
As Maarten already commented, combination of both (=having a router with VPN connection) would give you ensurance the all the connections are confidential (up to the VPN endpoint)
This may seem a naive question, since the computer networks knowledge from university days has almost vanished throughout the years, but before getting my hands on a book relevant on this topic, I would like to find out what more experienced folks out there know about this.
Basically I would like to be able to connect a client (C) to a remote server (S), sitting in separate LANs, without adding special rules (e.g. port forwarding) to any of the routers in between.
I know that some applications (TeamViewer) use broker servers for connecting a client to a remote machine, but what I don't know is if the whole traffic between them goes through the broker server.
For my use case, I would use such a server only for initial discovery of the peers (more exactly the discovery of S by C), then the traffic would go through a connection directly initiated by C towards S.
Would such an approach be possible?
Thank you!
Unfortunately if the devices reside in networks separated by the Internet your first hurdle concerns RFC1918. In order to connect to a private IP you will have to use some level of NAT. To over come this is to build a VPN connection between the two networks affectively connecting as if each are local to the other. Please note that to avoid any NAT configuration in this scenario requires that the private networks are using different subnets IPs
I'm setting up an Elasticsearch cluster using VMs in AWS.
I know that each node automatically tries to join an existing cluster which have the same cluster name in the same network.
However, I could not understand what the "same network" is.
Trying to understand about the same network, I found the concept of multicast and unicast.
It seems to be the same concept between "same network" and "in the multicast group".
If so, how can I figured out what ip addresses are in the multicast group? and how can I add or remove some IP addresses in the multicast group?
I'm not so familiar with the concepts of network.
What I really want to know is that how can I figured out whether my
nodes are in the same network or not? and how can I configure that.
Thanks in advance.
I am not a networking guy, but I believe they mean as long as they can see each other on a private network. Each node in a cluster wants to communicate internally with the other nodes on port 9300 by default.
So if you have one node on 10.20.10.5 (as an example) and one on 10.20.10.6, they should be able to "see" each other.
Also you can explicitly set the nodes in the cluster in the config file for Elastic.
For example in my elasticsearch.yml, I have something like this under the ### DISCOVERY ### section:
discovery.zen.ping.unicast.hosts: ["elastic-p1.domain.net:9300", "elastic-p2.domain.net:9300"]
I want to create my own Chord implementation for P2P file sharing
I followed an article which explained that every node has it's ID (hash of the IP for example)
my questions are:
how a new client join the network? there must be a server to manage it. right?
how you set for the new client the finger table?
Chord authors have their own implementation published:
http://pdos.csail.mit.edu/chord/#downloads
You can check how they manage those questions.
how a new client join the network?
By advertising its presence to other peers.
there must be a server to manage it. right?
Either a server or a location (URL) where peers can fetch IP addresses of other peers. This location is updated by peers themselves with fresh data.
If you dig deeper in this issue, you'll face the NAT traversal issue.
how you set for the new client the finger table?
By knowing/fetching other peers' id and computing the 'finger' order.