比特币代码分析4 节点发现机制

当程序第一启动时,它并不知道任何活跃节点的ip地址。为了发现一些全节点的ip地址,他们会查询硬编码在比特币内核或BitCoinJ中的,一个或多个DNS域名,在返回的结果中应该包含一个或多个DNS A记录,里面有一些可接受新连接的全节点的ip地址。
DNS 种子由比特币社区成员维护。其中一部分提供动态DNS种子服务器,它通过扫描比特币网络,自动获取活动节点的ip地址;其他的提供一些静态DNS种子,这需要手动更新,不过他们很有可能提供不活跃节点的ip地址。不管是动态的,还是静态的DNS种子,如果节点在主网上运行在端口号8333,或在测试网络运行在端口号18333,就会被加入到DNS种子。
DNS种子结果没有被授权,一个恶意的DNS种子运营者或网络中间人能返回仅被自己控制的节点的ip地址,在自己的网络中,孤立节点,并给他们假的交易,区块数据。因为这个原因,程序不应该只依赖一个DNS种子。
然而,节点通常会离开网络或者改变ip地址,这样程序在启动时,在需要多次尝试才有可能连接到比特币网络。这了会增加连接到比特币网络的延迟时间,使得用户在发送交易或检查支付状态前,不得不等待一段时间。
为避免这种延迟,BitcoinJ总是使用动态DNS种子,来获取那些被确定为活跃节点的IP地址。比特币处内核也尝试在降低延迟,避免使用不必要的DNS节点中权衡。如果比特币内核在它的节点数据库中有记录,它就会用11秒时间去连接至少其中一个节点,失败后,才使用DNS节点获取ip地址;如果在11秒内成功建立连接,则不在向DNS种子查询。

原文地址:http://blog.51cto.com/13878196/2326031

时间: 2024-10-29 15:58:22

比特币代码分析4 节点发现机制的相关文章

HDFS源码分析(四)-----节点Decommission机制

前言 在Hadoop集群中,按照集群规模来划分,规模可大可小,大的例如百度,据说有4000台规模大小的Hadoop集群,小的话,几十台机器组成的集群也都是存在的.但是不论说是大型的集群以及小规模的集群,都免不了出现节点故障的情况,尤其是超大型的集群,节点故障几乎天天发生,因此如何做到正确,稳妥的故障情况处理,就显得很重要了,这里提供一个在Hadoop集群中可以想到的办法,就是Decommission操作,节点下线操作,一般的情况是故障节点已经是一个dead节点,或是出现异常情况的节点.此时如若不

比特币代码分析11 比特币存储机制

比特币存储机制 比特币存储系统由两部分组成: kv 数据库(levelDB)索引和普通数据文件.普通文件用于存储区块链数据,kv 数据库用于存储区块链元数据.用于存储区块链数据的普通文件以 blk00000.dat , blk00001.dat 文件名格式组成.其中 index 目录存储用于存储区块元数据.普通区块数据文件 为了快速检索区块数据,每个文件的大小是128 M Bytes.区块里的数据(区块头和区块里的所有交易)都会序列成字节码的形式写入 dat 文件中.在序列化的过程中,如果检测到

比特币代码分析1 整体架构

Bitcoin 比特币官方客户端有两个版本:一个是图形界面的版本,通常被称为 Bitcoin(首字母大写),以及一个简洁命令行的版本(称为 bitcoind).命令行可以有两种运作方式:节点,RPC命令.节点是持续运行,RPC命令是一次性运行. 原文地址:http://blog.51cto.com/13878196/2323180

比特币代码分析7 交易校验

每一个收到交易,比特币节点都验证该交易,有效的交易将被传递到各个附近节点,这将确保只有有效的交易才会在网络中传播, 而无效的交易将会在第一个节点处就被废弃.校验选项列表:每一个节点在校验每一笔交易时,都需要对照一个长长的标准列表1.交易语法与数据是否正确2.输入与输出列表都不能空(>=1)3.交易大小 < max_block_base_size(1M)4.0 < 输出值与总量 < 2100万5.输出点中hash!=0,N!=-1(哈希值不能为零.序列号N不能为-1)6.nlockt

EOS代码分析3 EOS存储机制的IPFS分布式文件系统

EOS使用IPFS分布式文件系统作为底层存储.IPFS是一种内容可寻址.点对点.通过http协议传输的分布式文件系统.IPFS采用content-addressable寻址技术,即通过文件内容进行检索而不是通过文件的网络地址.简单来说,就是对文件内容进行hash运算,将hash值作为文件名保存在本地数据库中,所以,只要文件内容不变,则文件名也保持不变.运行IPFS的节点,既是客户端又是服务器.客户端通过发送文件名到服务器,请求下载文件,服务器会根据文件名到数据库中查找对应的文件,查找成功后将文件

比特币代码分析3 命令调用框架

原文地址:http://blog.51cto.com/13878196/2325373

比特币代码分析5 挖矿代码分析

本文描述矿工处理线程,通过本文学习,可以了解矿工挖矿的大致流程.主要包含挖矿费用交易的产生.当前交易池的打包处理,工作量证明等相关内容.流程图(参考网络)如下所示:. 矿工处理函数1.void ThreadBitcoinMiner(void* parg)2.{ vfThreadRunning[3] = true; CheckForShutdown(3); try { bool fRet = BitcoinMiner(); printf("BitcoinMiner returned %s\n\n\

Linux -- 内存控制之oom killer机制及代码分析

近期,线上一些内存占用比較敏感的应用.在訪问峰值的时候,偶尔会被kill掉,导致服务重新启动.发现是Linux的out-of-memory kiiler的机制触发的. http://linux-mm.org/OOM_Killer oom kiiler会在内存紧张的时候,会依次kill内存占用较高的进程,发送Signal 15(SIGTERM).并在/var/log/message中进行记录.里面会记录一些如pid,process name.cpu mask,trace等信息,通过监控能够发现类似

nova boot代码流程分析(一):Claim机制

nova boot创建VM的流程大致为: 1. novaclient发送HTTP请求到nova-api(这里内部细节包括keystone对用户的验证及用户从keystone获取token和endpoints等信息,具体参考<keystone WSGI流程>). 2. nova-api通过rpc调用到nova-conductor. 3. nova-conductor调用rpc进入nova-scheduler进行compute节点的选择,nova-scheduler将compute节点选择的信息的