Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to monitor P2P ports". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

We know that when initializing the original with bytomd init-chain_id mainnet/testnet/solonet, it uses different ports depending on the given chain_id (see config/toml.go#L29):

Mainnet (connect to main network): 46657

Testnet (connect to test network): 46656

Solonet (local separate node): 46658

For me, since I only need to analyze a local running node than the original node, I can use the third chain_id, solonet. In this way, after it is started, it will not be actively connected with other nodes, which can reduce the interference of other nodes to us.

So at startup, my command goes like this:

Cd cmd/bytomd./bytomd init-chain_id solonet./bytomd node

It listens for port 46658 and waits for other nodes to connect.

Connect and have a look.

If we use telnet to connect its port 46658 at this time, we can see that it will send us some garbled codes after successfully connecting, probably as follows:

$telnet localhost 46658Trying 127.0.0.1...Connected to localhost.Escape character is'^]'. /

We may wonder, what exactly is it sending us?

But this question will be answered next time, because first of all, the original node must be able to listen to this port before we can connect. So this time our question is:

How does Beehara listen to this port in the code? The port has been written in config.toml

Earlier, when we initialized Biyuan with. / bytomd init-- chain_id solonet, Biyuan will generate a config.toml configuration file in the local data directory, approximately as follows:

# This is a TOML config file.# For more information, see https://github.com/toml-lang/tomlfast_sync = truedb_backend = "leveldb" api_addr = "0.0.0.0 truedb_backend 9888" chain_id = "solonet" [P2P] laddr = "tcp://0.0.0.0:46658" seeds = ""

The laddr under [P2P] is the address and port that the node listens to.

For laddr = "tcp://0.0.0.0:46658", it means:

Using the tcp protocol

The listening ip is 0.0.0.0, which means listening on all local ip addresses. In this way, the node allows both local access and external host access. If you only want it to listen on a certain ip, modify the configuration file manually

46658, which is the port we focus on in this issue, the port it uses to exchange data with this node and other nodes.

When Bihara was listening on this port, he didn't call net.Listen directly to listen to it as I initially expected. The actual process is more complicated than this, because an object called Switch is designed to manage events related to the outside world, including monitoring, connecting, sending messages, and so on. Switch, on the other hand, is created in SyncManager.

Start up until you enter Switch

So we first need to know how Bihara started in the source code and step by step into the world of Switch.

First of all, when we start the bytomd node, the corresponding entry function is as follows:

Cmd/bytomd/main.go#L54

Func main () {cmd: = cli.PrepareBaseCmd (commands.RootCmd, "TM", os.ExpandEnv (config.DefaultDataDir ()) cmd.Execute ()}

It also runs the following function based on the node parameter passed in:

Cmd/bytomd/commands/run_node.go#L41

Func runNode (cmd * cobra.Command, args [] string) error {/ / Create & start node n: = node.NewNode (config) / /...}

What we need to focus on is the node.NewNode (config) function, because SyncManager is created in it:

Node/node.go#L59

Func NewNode (config * cfg.Config) * Node {/ /... SyncManager, _: = netsync.NewSyncManager (config, chain, txPool, newBlockCh) / /...}

When you create the SyncManager, you create the Switch:

Netsync/handle.go#L42

Func NewSyncManager (config * cfg.Config, chain * core.Chain, txPool * core.TxPool, newBlockCh chan * bc.Hash) (* SyncManager, error) {/ / Manager.sw = p2p.NewSwitch (config.P2P, trustHistoryDB) / /. ProtocolReactor: = NewProtocolReactor (chain, txPool, manager.sw, manager.blockKeeper, manager.fetcher, manager.peers, manager.newPeerCh, manager.txSyncCh, manager.dropPeerCh) manager.sw.AddReactor ("PROTOCOL", protocolReactor) / / Create & add listener p, address: = protocolAndAddress (manager.config.P2P.ListenAddress) l: = p2p.NewDefaultListener (p, address, manager.config.P2P.SkipUPNP, nil) manager.sw.AddListener (l) / /.}

It is important to note that the protocolReactor object created above is used to deal with how the two parties interact when a node connects to the port. It is not directly related to the "listening port" of this problem, but it can also be noted here.

Then a DefaultListener object is created, and the action of listening on the port occurs in it. After the Listener is created, it will be added to the manager.sw (that is, Switch) to interact with external data and events there.

Listening port

There are a lot of things to do in NewDefaultListener, so let's break it into pieces and say:

P2p/listener.go#L52

Func NewDefaultListener (protocol string, lAddr string, skipUPNP bool, logger tlog.Logger) Listener {/ / Local listen IP & port lAddrIP, lAddrPort: = splitHostPort (lAddr) / / Create listener var listener net.Listener var err error for i: = 0; I < tryListenSeconds ITunes + {listener, err = net.Listen (protocol, lAddr) if err = = nil {break} else if i < tryListenSeconds-1 {time.Sleep (time.Second * 1)}} if err! = nil {cmn.PanicCrisis (err)} / /.

The above part is the real listening code. The specified address is monitored through the net.Listen function provided by the Go language. In addition, many attempts were made during monitoring, because it takes a short period of time for a newly used port to be released, so it needs to be tried several times.

Where tryListenSeconds is a constant with a value of 5, that is, it will try for about 5 seconds. If it cannot be bound, it will really fail and an error will be thrown.

Some code is omitted later, which is mainly used to obtain the actual ip and public network ip of the current monitoring, and record them in the log. I wanted to talk about it briefly here, but I found that there was still some trouble, so I planned to leave it at the back to focus on a question.

In fact, this problem is over here, because the "monitoring" has been completed. But there are also some initialization operations that allow Bibi to interact with the node connected to the port, which is also worth talking about here.

Then the last part of the method is:

Dl: = & DefaultListener {listener: listener, intAddr: intAddr, extAddr: extAddr, connections: make (chan net.Conn, numBufferedConnections),} dl.BaseService = * cmn.NewBaseService (logger, "DefaultListener", dl) dl.Start () / / Started upon construction return dl}

Note that connections, which is a buffered channel (numBufferedConnections value of 10), is used to hold connection objects connected to that port. These operations will be performed later in dl.Start ().

Dl.Start () will call the OnStart method corresponding to DefaultListener, as follows:

P2p/listener.go#L114

Func (l * DefaultListener) OnStart () error {l.BaseService.OnStart () go l.listenRoutine () return nil}

The l.listenRoutine is the function that executes the connection into the connections channel mentioned earlier:

P2p/listener.go#L126

Func (l * DefaultListener) listenRoutine () {for {conn, err: = l.listener.Accept () / /. L.connections

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.