Use netty development heartbeat detection and reconnection mechanism of planning and design

Heartbeat detection code logic and design ideas

plan 1

1.1 heartbeat mechanism

By ping-pong heartbeat mechanism to ensure two-way communication no matter which side of a network failure, can be detected in time to prevent the other party did not return a short time busy answering false positives caused by 
only N consecutive heartbeat failed only identified link has been hurt and needs to close and re-establish the link link.
when the I / O read or write abnormal heartbeat message occurs, indicating that the link has been interrupted and the need to immediately close the link, if the client needs to re-launch connection. If the server is a need to re-initiate the connection.
If the server, you need to empty the cache of half a pack of information, waiting for clients to reconnect.

1.2 reconnection mechanism

If the link is interrupted, wait time interval, initiated by the client reconnection operation, even if the heavy defeat, after an interval cycle interval initiated reconnect again until reconnection. 
In order to ensure the server can have adequate resources to handle the release of the event, when you first break even need to wait for the client to initiate reconnection interval time before, rather than after the failure to reconnect immediately.
in order to ensure the timely release handle resources, no matter what the scene under heavy even fails, the client must ensure its own choice was released in time, including but not limited to socketchannel socket
reconnect after a failure, the need to print exception stack information, follow-up questions to facilitate the positioning

 Reference netty Definitive Guide

 

 

Scenario 2

1. The client sends a heartbeat packet

2. The server accepts Heartbeat

3.1 IdleStateHandler add custom service handler and wherein every n seconds to write IdleStateHandler detecting a trigger event associated reader

3.2 or add ReadTimeoutHandler not read the initiative to close the connection Throws

3.3 recommends using recommended IdleStateHandler own monitoring and processing (read timeout to adjust the idle time-out event is closed to write your own business and so on according to their needs)

4. The service handler using userEventTriggered () idle_event method of determining event has been triggered and the related service logic

5. add a channel to the client listener reconnection ChannelFutureListene, if the listener listens to a server (channelFuture.isSuccess () event) is disconnected at intervals of 1s will trigger a re-connection operation

Reference https://blog.csdn.net/hzf1993/article/details/82841043 

https://github.com/njniecong/netty_all


Guess you like

Origin www.cnblogs.com/ericnie11/p/12044216.html