I wonder what's difference between ethereum and bitcoin p2p section.
I know that ethereum uses wire protocol. And it use receipts message, status message.
Is there any similar process in bitcoin?
This is a question for Google not really here as there are a huge amount of content written about the difference.
Since we're here, this is a video that explains in depth the differences between them:
https://www.youtube.com/watch?v=0s23w5GUAeU
Related
I'm looking for a decentralized database for my Dapp.
I found two helpful solutions orbitdb and gun but I couldn't realize the main difference and which one is more suitable for a social-media-like application that use ethereum smart contract.
I'm the author of gun. I've seen OrbitDB floating around (ha, pardon the pun!) but obviously am not intimately knowledgable about it enough to speak about it. I'll leave that for them to answer. :)
It does look like OrbitDB also uses CRDTs, which means they are probably doing things right/correct. Very few people are using CRDTs, which is sad, but makes GUN pretty unique! Despite the last 4 years I've been trying to evangelize to people that they should use CRDTs, I welcome it.
Maybe a practical way to answer your question, #maroodb , is around GUN's use case for social media:
Yes, GUN is already being used for P2P social media dApps. You can do:
User account systems, including traditional username/password, and password reset (no server, fully P2P).
Published user data, like tweets, etc. that cannot be tampered with by anybody else (signature encryption, but not private).
Private data to the user (cypher encryption).
Secret data between 2 users, like private messages (diffie-hellman).
And we're currently working on making it easier to do group read/write data, which is possible, but no demos yet.
Here are some links that show demos, and other resources, that might be helpful in building your app:
Conceptual understanding of P2P security, done in 1 minute animated cartoon explainers - https://gun.eco/explainers/data/security.html
Short, fast article on how to get started with user accounts for a P2P Twitter - https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8
A 4 minute and 40 line of code interactive coding tutorial, on how to build a super basic P2P Twitter - https://scrimba.com/c/c2gBgt4
Social network idea - https://d.tube/#!/v/marknadal/lanz4e6z (d.tube itself is a P2P youtube)
P2P user account management system - https://d.tube/#!/v/marknadal/gfqglxvd
Super basic Private Message demo in 75 lines of code - https://d.tube/#!/v/marknadal/ganoayt8
Documentation on how to use the security API - https://gun.eco/docs/SEA
And of course, a super friendly chat room of Open Source developers helping each other out build these kind of stuff, https://github.com/amark/gun ! :)
You'll have to ask OrbitDB for their examples/use case for P2P social networking dApps, maybe they know what makes gun different.
Note: A GUN+IPFS adapter will be out soon.
Ethereum is great, but your social network might not scale up if it is implemented primarily as an ethereum smart contract, just as a warning.
We recommend you use Ethereum for any cryptocurrency payments or transactions for your user (not GUN or Orbit).
But we do not recommend building basic social network features (profile info, posts, messages, etc.) using Ethereum.
Likely, 90 to 95% of your app will be GUN or Orbit, and possibly only 3 to 5% smart contracts.
We've made an application where two people can video chat with each other using TokBox, but are running into a lot of technical issues surrounding WebRTC and TokBox itself. I know that Twilio recently launched a Javascript version for their video service, but both TokBox and Twilio seem to be aiming for larger scale publish/subscribe operations. It also isn't as far along as TokBox.
Are there other services out there that can do web video 1 on 1's? Perhaps some that don't use WebRTC and therefore don't have the problems we are facing?
I can't help but to think back to ChatRoulette and similar apps.
If what you need is an application that needs to run within the context of a browser, then WebRTC is your only choice when it comes to the technology to use. There's just nothing else there now that Flash is officially dead.
If you need it to run purely inside a packaged PC/mobile application, then you can use something other than WebRTC, but I don't really see the need for that.
When using real time video technologies, one aspect to look at closely is the quality of the network you are using. The questions I usually ask myself are things like does Skype/Hangouts/FaceTime run any better? If the answer is "yes they do", then the problem is in the implementation you have done/used. If the answer is "no, they are just as bad" then you probably can't do a lot better either.
For alternatives, you can check out the vendors listed in this WebRTC Develoepr Tools Landscape: https://bloggeek.me/webrtc-developer-tools-landscape/
I don't know what you mean with "a lot of technical issues surrounding WebRTC and Tokbox itself", but I do know Tokbox handles millions of 1:1 streaming minutes every day, without issues, and it can even handle sessions with 1 publisher and 3000 subscribers at the same time, so, maybe the technical issues are not there, but in another place...
I've seen many good tcp-based projects in other languages, for example C/C++.
Is there any good one in Node.js? I'm implementing a tcp-based real-time pub/sub system using Node.js, but have some problems when high pressure.
I don't really need those simple tcp server examples or baby-steps tutorials. I need some real projects.
Thanks!
EDIT:
I write a chat-like node.js program to exchange data from clients. It's pretty good when I test it with only few people.
However, when more people, like hundreds people, join in, it starts to loss data. Check out this: How to deal with 'read ETIMEDOUT' in Node.js?.
The answer is good but cannot help on improving the stability.
I don't really expect people who dive into my dirty codes to find my errors. That's why I want some real projects to see how they do.
I believe this reading material might help you.
In his case, he was broadcasting mouse events to several clients. And the amount of data to publish was so great that he had to cluster users by "rooms"
I’m looking at creating a P2P system. During initial research, I’m reading from Peer-to-Peer – Harnessing the Power of Disruptive Technologies. That book states “a fully decentralized approach to instant messaging would not work on today's Internet.” Mostly blaming firewalls and NATs. The copyright is 2001. Is this information old or still correct?
It's still largely correct. Most users still are behind firewalls or home routers that block incoming connections. Those can be opened easier today than in 2001 (using uPnP for example, requiring little user interaction and knowledge) but most commercial end-user-targeting applications - phone (Skype, VoIP), chat (the various Messengers), remote control - are centralized solutions to circumvent firewall problems.
I would say that it is just plain wrong, both now and then. Yes, you will have many nodes that will be firewalled, however, you will also have a significant number who are not. So, if end-to-end encryption is used to protect the traffic from snooping, then you can use non-firewalled clients to act as intermediaries between two firewalled clients that want to chat.
You will need to take care, however, to spread the load around, so that a few unfirewalled clients aren't given too much load.
Skype uses a similar idea. They even allow file transfers through intermediaries, though they limit the through-put so as not to over load the middle-men.
That being said, now in 2010, it is a lot easier to punch holes in firewalls than it was in 2001, as most routers will allow you to automate the opening of ports via UPNP, so you are likely to have a larger pool of unfirewalled clients to work with.
Firewalls and NATs still commonly disrupt direct peer-to-peer communication between home-based PCs (and also between home-based PCs and corporate desktops).
They can be configured to allow particular peer-to-peer protocols, but that remains a stumbling block for most unsavvy users.
I think the original statement is no longer correct. But the field of Decentralized Computing is still in its infancy, with little serious contenders.
Read this interesting post on ZeroTier (thanks to #joehand): The State of NAT Traversal:
NAT is Traversable
In reading the Internet chatter on this subject I've been shocked by how many people don't really understand this, hence the reason this post was written. Lots of people think NAT is a show-stopper for peer to peer communication, but it isn't. More than 90% of NATs can be traversed, with most being traversable in reliable and deterministic ways.
At the end of the day anywhere from 4% (our numbers) to 8% (an older number from Google) of all traffic over a peer to peer network must be relayed to provide reliable service. Providing relaying for that small a number is fairly inexpensive, making reliable and scalable P2P networking that always works quite achievable.
I personally know of Dat Project, a decentralized data sharing toolkit (based on their hypercore protocol for P2P streaming).
From their Dat - Distributed Dataset Synchronization And Versioning paper:
Peer Connections
After the discovery phase, Dat should have a list of
potential data sources to try and contact. Dat uses
either TCP, UTP, or HTTP. UTP is designed to not
take up all available bandwidth on a network (e.g. so
that other people sharing wifi can still use the Inter-
net), and is still based on UDP so works with NAT
traversal techniques like UDP hole punching.
HTTP is supported for compatibility with static file servers and
web browser clients. Note that these are the protocols
we support in the reference Dat implementation, but
the Dat protocol itself is transport agnostic.
Furthermore you can use it with Bittorrent DHT. The paper also contains some references to other technologies that inspired Dat.
For implementation of peer discovery, see: discovery-channel
Then there is also IPFS, or 'The Interplanetary File System' which is currently best positioned to become a standard.
They have extensive documentation on their use of DHT and NAT traversal to achieve decentralized P2P.
The session messenger seem to have solved the issue with a truly decentralized p2p messenger by using a incentivized mixnet to relay and store messages. Its a fork of the Signal messenger with a mixnet added in. https://getsession.org -- whitepaper: https://getsession.org/wp-content/uploads/2020/02/Session-Whitepaper.pdf
It's very old and not correct. I believe there is a product out called Tribler (news article) which enables BitTorrent to function in a fully decentralized way.
If you want to go back a few years (even before that document) you could look at Windows. Windows networking used to function in a fully decentralized way. In some cases it still does.
UPNP is also decentralized in how it determines available devices on your local network.
In order to be decentralized you need to have a way to locate other peers. This can be done proactively by scanning the network (time consuming) or by having some means of the clients announcing that they are available.
The announcements can be simple UDP packets that get broadcast every so often to the subnet which other peers listen for. Another mechanism is broadcasting to IIRC channels (most common for command and control of botnets), etc. You might even use twitter or similar services. Use your imagination here.
Firewalls don't really play a part because they almost always leave open a few ports, such as 80 (http). Obviously you couldn't browse the network if that was closed. Now if the firewall is configured to only allow connections that originated from internal clients, then you'd have a little more work to do. But not much.
NATs are also not a concern for similiar issues.
I want to collect statistics from the spreading of a file in a new bittorrent swarm without actually downloading anything (or as little as possible). I need to know which peer has which pieces (to make file based statistics) knowing the number of seeders and leechers or percentages is not enough. Later when there are many peers I need to download the data to determine what it is. This part can be done with a regular torrent client.
I do not plan to implement the protocol myself so I looked at 2 implementations libtorrent and ktorrent's libbtcore. Neither is capable of collecting data while not downloading there are simply no connected peers when there is nothing to download. Libtorrent is simpler but ktorrent looks better commented.
I see 3 possibilities:
Use some application exactly for this. Are there any?
Modify a torrent implementation to do what I want. Is anyone familiar with them? Where to start?
Implement a small subset of the protocol. Just periodically ask the peers what they have. Is this feasible or would the program need to support almost the full protocol?
What do you recommend?
This is an old question, but perhaps this answer might be useful for others.
Use some application exactly for this. Are there any?
Not that I know of.
Modify a torrent implementation to do what I want. Is anyone familiar with them? Where to start?
I'm only familiar with the BitTornado core (that is used in e.g. ABC). It is written in Python, but it's an architectural mess.
However, you could just take any implementation and start stripping it from unnecessary functionality.
Implement a small subset of the protocol. Just periodically ask the peers what they have. Is this feasible or would the program need to support almost the full protocol?
Note that you cannot "ask" a peer what they have. The other peer informs you whenever it wants about the pieces it has (so it's push instead of pull). After the BitTorrent handshake, a peer may send a bitfield of pieces it has. Afterwards it may send HAVE messages informing you it has acquired a new piece. Also note that peers may lie about the pieces they have. Examples include superseeding peers and freeriding clients like BitThief.
If you want to implement a small subset of the protocol, you'd need at the bare minimum implement the BitTorrent handshake message and preferably the extended handshake message. The latter allows you to receive (and send) uTorrent PEX messages. PEX is useful to quickly discover other peers in the swarm.
For your statistics gathering purposes, you additionally need to support the bitfield and HAVE messages.