以太坊源码分析---go-ethereum之p2p通信分析(2)

说明:此文章为腾讯云机器自动从本人csdn博客搬迁过来。是本人授权操作。

申明:无本人授权,不可转载本文。如有转载,本人保留追究其法律责任的权利。

龚浩华,QQ 29185807,月牙寂 道长

第一时间获取文章,可以关注本人公众号 月牙寂道长 yueyajidaozhang

上一篇分析了p2p模块的初始化与start。 继续上一篇分析。

先回顾下p2p的初始化

github.com/ethereum/go-ethereum/eth/backend.go中

函数

func New(config *Config) (*Ethereum, error) {

下面是start

那现在进入到p2p模块中

github.com/ethereum/go-ethereum/p2p/server.go中

在p2p模块中,大部分的数据是通过chan来进行传输的。以上有7个chan

上面是关键地方,两个入口。

下面分别介绍

Listen部分

继续跟踪

这里面有slots,是用来做数量限制的。用了一个带缓冲区的chan,先讲token放进去,然后先取出token,接收一个链接,当链接ok了后,将token放回去。

很简单的chan的应用

那么逻辑还是很清晰的,我们继续跟踪

这里面的东西就比较多了。一个一个来

先看下两个函数的原型doEncHandshake和doProtoHandshake

在586行,c := &conn{fd: fd, transport: srv.newTransport(fd), flags: flags, cont: make(chan error)}

我们看下srv的

然后我们回到func (srv *Server) Start() (err error) {

那么就知道了

github.com/ethereum/go-ethereum/p2p/rlpx.go中

真正的处理函数在这里

github.com/ethereum/go-ethereum/p2p/rlpx.go

github.com/ethereum/go-ethereum/p2p/rlpx.go

好的回到func (srv *Server) setupConn(fd net.Conn, flags connFlag, dialDest *discover.Node) {

github.com/ethereum/go-ethereum/p2p/server.go

我们看下

在函数func (srv *Server) setupConn(fd net.Conn, flags connFlag, dialDest *discover.Node) {

if err := srv.checkpoint(c, srv.posthandshake); err != nil {

if err := srv.checkpoint(c, srv.addpeer); err != nil {

分别传递的是两个chan,srv.posthandshak和srv.addpee

好的,到这里listen的处理就完了。下面我们看如何通过chan与run进行配合工作的。

github.com/ethereum/go-ethereum/p2p/server.go中

上面的重点到了,通过chan的传送,把数据传到run中,处理

上面才是重点。Addpeer。

github.com/ethereum/go-ethereum/p2p/peer.go

传入的参数,protocol是srv.Protocols。这个我们在第一篇文章中有说到。

继续跟踪

github.com/ethereum/go-ethereum/p2p/server.go中

继续

github.com/ethereum/go-ethereum/p2p/peer.go

重点三个地方,慢慢来看

很简单的读信息,然后进行处理

继续

上面的重点处理都在default中,这个就是最上层的入口

好的重点来了。跟踪进去,完了,好像看不懂

重点是在p.running

我们回过头去看看

我们知道初始化peer的时候,传送的是srv.Protocols。这个在第一篇文章有介绍了,

回到

这个很简单,定时的pingpong

我们看看最初的run在哪里

github.com/ethereum/go-ethereum/eth/handler.go

ProtocolManager初始化Protocols的时候

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jerry的SAP技术分享

Cloud Foundry Session Affinity(Sticky Session)的实现

会话保持(Session Affinity),有时又称粘滞会话(Sticky Sessions), 是负载均衡领域设计需要着力解决的重要问题之一,也是一个相对比...

1013
来自专栏恰童鞋骚年

操作系统核心原理-3.进程原理(上):进程概要

进程管理、内存管理和文件管理是操作系统的三大核心功能,那么什么是进程呢?顾名思义,进程就是进展中的程序,或者说进程是执行中的程序。当一个程序被加载到内存之后就变...

2092
来自专栏Sorrower的专栏

Mac下安装配置Android Studio并让多版本共存以及配置使用adb

2353
来自专栏惨绿少年

HTTP服务简介

第1章 HTTP服务介绍 1.1 简述用户访网站流程 a 进行域名信息的DNS解析 dig +trace 获得www.oldboyedu.com  ip地址信息...

3070
来自专栏架构师小秘圈

域名劫持

作者:sarleon 来自:freebuf.com 01 原理 DNS决定的是我们的域名将解析到哪一个IP地址的记录,是基于UDP协议的一种应用层协议 这个...

8524
来自专栏Laoqi's Linux运维专列

mariadb galera集群配置

3594
来自专栏伪君子的梦呓

如何备份一些容易看不到的文章

37310
来自专栏散尽浮华

Linux系统是否被植入木马的排查流程梳理

在日常繁琐的运维工作中,对linux服务器进行安全检查是一个非常重要的环节。今天,分享一下如何检查linux系统是否遭受了入侵? 一、是否入侵检查 1)检查系统...

7608
来自专栏QQ音乐技术团队的专栏

全民K歌后台编译优化:从40分钟到30秒

编者注 :全民K歌上线1年半的从0发展到1.5亿,用户越来越多,后台代码库越来越大,编译速度也与日俱慢,编译一下整个工程需要30-40分钟,如何实现秒编至关重要...

3997
来自专栏FreeBuf

运维安全 | 等保视角下的SSH加固之旅

前段时间在搞等保,根据等保的安全要求,需要对公司的服务器进行安全加固,其中就涉及到对SSH Server的加固。正好最近有空,笔者将加固过程的一些经验,总结分享...

3203

扫码关注云+社区

领取腾讯云代金券