-
Notifications
You must be signed in to change notification settings - Fork 0
/
DESIGN
57 lines (47 loc) · 1.78 KB
/
DESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Upstream
===================
Currently, RPC is the transimission method bewteen MSP and backend server.
But we use RPC here is ONLY for convience, because the FAE has the stack now.
IMO, I prefer ZMQ.
Bussiness
==========
- Mobile Client request:
- msp receive the mcp request, pack it to rpc request, send it to the backend service
- after backend receive request, give the rpc reponse IMMEDIATELY
- handle the rpc request ONLY the rpc result is error, which means send failure
- the mcp response will be received as another rpc request
- Server Request:
- msp receive the rpc request, pack it to mcp format
- msp send the rpc response IMMEDIATELY,
- then send the mcp request
- After the Moblie-Client send the response, the msp pack the mcp reponse to a new rpc request
- send the request to the backend service
Models
======
- rpc_server
- server informations : adress,port,config, stats, perf_counters ..
- connection informations : use for maintain all the client connections
- rpc_client
- client informations : stats, config, perf_counters ..
- upstream-map : KV mapping for address-rpc_connection structure
- upstreamer_root
- RB_ROOT
- upstream map
- connecting_connection_list
- upstreamer
- connection_list
- to_send_queue : save the request when the connection is not ready to go with
-
- rpc_connection
- connection information : fd, ev, sock_addr, connnecting_time duration_time ..
- buffer
- last seq number
- request-map (transaction map) , only used in client side, because the server side will process the request one by one so we don't need to maintain the request-map
- upstream list_head: each upstream has multiple connection
- connection status : disconnected, connecting, connected
-
- rpc_request
- rpc_response
Server
======
-