You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The old intrerfaces: have no document; input/output parameters are week types; mixed gin-handler and data-api service
New service definition applies protobuf. Details are in tracker/tkrpc/info-tracker.proto
New interfaces:
serviceInfoTracker {
rpcHeartBeat (streamUpdateNodeInfoReq) returns (EmptyRes);
//map to old func Logout LoginrpcUpdateNodeInfo (UpdateNodeInfoReq) returns (EmptyRes);
//map to old func userLogout userLoginrpcUpdateUserInfo (UpdateUserInfoReq) returns (EmptyRes);
//map to old func updateUsersrpcUpdateUserInfos (UpdateUserInfosReq) returns (EmptyRes);
//map to old func: GetUserState , GetUserP2pNodeId//Request:SetUserInfoReq{user_id,node_Id}//old GetUserP2pNodeId use request:SetUserInfoReq{user_id} ; may not work when user login on multi noderpcGetUserInfo (UpdateUserInfoReq) returns (UserInfo);
//Map to old function GetAllUsersrpcGetUserInfos (ListReq) returns (UserInfosRes);
//map old function GetAllObdNodesrpcGetNodes (ListReq) returns (NodeInfosRes);
// map to old ChannelService.updateChannelInforpcUpdateChannelInfo(ChannelInfo)returns(ChannelInfo);
rpcUpdateChannelInfos(UpdateChannelInfosReq)returns(EmptyRes);
//map to old ChannelService.GetChannelStaterpcGetChannelInfo(SimpleFilter)returns(ChannelInfo);
rpcGetChannels(ListReq)returns (NodeInfosRes);
// map old function updateHtlcInforpcUpdateHtlcInfo(HtlcInfo)returns (HtlcInfo);
//map old function getPathrpcHtlcGetPath(HtlcGetPathReq)returns (HtlcGetPathRes);
//map old function GetHtlcCurrStaterpcGetHtlcInfo(GetHtlcInfoReq)returns (HtlcInfo);
}
//obd-user-infomessageUserInfo {
int32id=1;
//user_peer_idstringuser_id=2;
//node_peer_idstringnode_id=3;
// 1 online 2 offlineint32is_online=4;
stringaccess_ip=5;
//unix timestamp in seconds ; google.protobuf.Timestamp will more better,but sql database not support protobuf.Timestamp.int64updated_at=6;
int64created_at=7;
}
......
Strong-typed data structure. Added/updated some comments as document in the proto definition file, and the document is displayed synchronously in proto genrated go-files, and will be automatically integrated in swagger document too, or obd js-sdk which invokes the rpc-service.
(fixed) one user connects to multiple obd-nodes ( tracker? ) which call getUserP2pNodeId from remote trackers. This will not work. Fixed: now an obd only connects one tracker when sync/query data.
(fixed) Tracker side updateUsers does not set userinfo.ObdP2pNodeId. userInfo should sync this field.
(fixed) omnibolt-report-final.pdf refer: OBD uses not maintained dependencies ( ile-rotatelogs, asdine/storm, etc.). Fixed: storm is delete, tracker uses gorm database model now.
(fixed) Tracker/dao/pojo.go UserInfo.ObdNodeId fieldname hard to understand.
(fixed) func (manager *htlcManager) getPath(obdClient *ObdNode, msgData string) (path interface{}, err error) at tracker/service/htlc_service.go lines 40.
the retured paramter path may be a string or a map; When consume returned value, you should use reflect to detect type of the return value at lightclient/connect_tracker.go lines 107, which is a bad desgin
it's hard to understand the the meaning of the var-params at line 225 from the context, you must seek the message source to understand the exact meaning of this variable, which is hard to maintain the source code. Concurrent map access is a problom too, which is now discarded.
(to to)channelInfo will be updated on both sides of tracker and obd-server; When an obd starts, obd's channels-Info data will cover the data from the tracker, the tracker's update will lost. The sync mechanism between obd and tracker causes data error.
(to to) channelInfo's fields on tracker are different to the obd.
When obd commits channelInfo to a tracker, now we have the code to convert:
//infoRequest is the data submit to trackerinfoRequest.PeerIdA=channelInfo.PeerIdAinfoRequest.PeerIdB=channelInfo.PeerIdBinfoRequest.IsAlice=falseifcommitmentTx.Id>0 {
ifcommitmentTx.Owner==channelInfo.PeerIdA {
infoRequest.IsAlice=trueinfoRequest.AmountA=commitmentTx.AmountToRSMCinfoRequest.AmountB=commitmentTx.AmountToCounterparty
} else {
infoRequest.AmountB=commitmentTx.AmountToRSMCinfoRequest.AmountA=commitmentTx.AmountToCounterparty
}
}
We should modify channelInfo's fields to be the same as the tracker. It will be easy when updates the sync mode between the obd and tracker.
channelInfo.IsAlice should be a function, it's a computed field. For example:
(to to) func (manager *htlcManager) getPath(msgData string) (path interface{}, err error) shoud have a document: the main flow,and how to use the returned value.
issue 1: if some err occurs ,we MUST not invoke it (L60). If it noticeTrackerUserLogin just record a audit-log, we can ignore the err and invoke it.
issue 2: obd/service is just a database/data operation module, it MUST not call sendMsgToTracker to send async message; obd/lightclient module is async message center, now 95% async messages are recieved and sent here, all the client-websocket-conn p2p-conn are initialized here; obd/service/htlc_tx_forward.go PayerRequestFindPath invoke "sendMsgToTracker(enum.MsgType_Tracker_GetHtlcPath_351, pathRequest)" have the same probolem.
now i have fixed the two issue, and obd/service.sendMsgToTracker have disbled, and below messages submit by grpc-conn now,no need to sync userInfo/channelInfo/htlcInfo to tracker with complex async message Goroutines. the old msgList:
MsgType_Tracker_UpdateChannelInfo_350
MsgType_Tracker_UserLogin_304
MsgType_Tracker_UserLogout_305
MsgType_Tracker_UpdateHtlcTxState_352
(to to) may be we should design the obd-tracker info sync-mode and security first. Maybe new mechanism won't need the above work.
The text was updated successfully, but these errors were encountered:
issues:
old service-interfce:
The old intrerfaces: have no document; input/output parameters are week types; mixed gin-handler and data-api service
New service definition applies protobuf. Details are in tracker/tkrpc/info-tracker.proto
New interfaces:
Strong-typed data structure. Added/updated some comments as document in the proto definition file, and the document is displayed synchronously in proto genrated go-files, and will be automatically integrated in swagger document too, or obd js-sdk which invokes the rpc-service.
(fixed) one user connects to multiple obd-nodes ( tracker? ) which call getUserP2pNodeId from remote trackers. This will not work. Fixed: now an obd only connects one tracker when sync/query data.
(fixed) Tracker side updateUsers does not set userinfo.ObdP2pNodeId. userInfo should sync this field.
(fixed) omnibolt-report-final.pdf refer: OBD uses not maintained dependencies ( ile-rotatelogs, asdine/storm, etc.). Fixed: storm is delete, tracker uses gorm database model now.
(fixed) Tracker/dao/pojo.go UserInfo.ObdNodeId fieldname hard to understand.
(fixed) func (manager *htlcManager) getPath(obdClient *ObdNode, msgData string) (path interface{}, err error) at tracker/service/htlc_service.go lines 40.
the retured paramter path may be a string or a map; When consume returned value, you should use reflect to detect type of the return value at lightclient/connect_tracker.go lines 107, which is a bad desgin
obd/lightclient/connect_tracker.go
Lines 98 to 114 in 5829315
(fixed) userState mananger, userOnlineOfOtherObdMap .fixed
old code
obd/tracker/service/p2p_service.go
Lines 213 to 245 in 5829315
it's hard to understand the the meaning of the var-params at line 225 from the context, you must seek the message source to understand the exact meaning of this variable, which is hard to maintain the source code. Concurrent map access is a problom too, which is now discarded.
the new code version :
(fixed) Two duplicated function: tracker/service/p2p_service.go sendChannelUnlockInfoToObd SendChannelLockInfoToObd
obd/tracker/service/p2p_service.go
Lines 266 to 300 in 5829315
obd/tracker/service/p2p_service.go
Lines 349 to 385 in 5829315
(to to)channelInfo will be updated on both sides of tracker and obd-server; When an obd starts, obd's channels-Info data will cover the data from the tracker, the tracker's update will lost. The sync mechanism between obd and tracker causes data error.
(to to) channelInfo's fields on tracker are different to the obd.
When obd commits channelInfo to a tracker, now we have the code to convert:
We should modify channelInfo's fields to be the same as the tracker. It will be easy when updates the sync mode between the obd and tracker.
channelInfo.IsAlice should be a function, it's a computed field. For example:
(to to) func (manager *htlcManager) getPath(msgData string) (path interface{}, err error) shoud have a document: the main flow,and how to use the returned value.
obd/tracker/service/htlc_service.go
Lines 40 to 83 in 5829315
(fixed) obd/service/user.go line 60 calls noticeTrackerUserLogin().sendMsgToTracker() .
obd/service/user.go
Lines 20 to 76 in 5829315
The text was updated successfully, but these errors were encountered: