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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
// Much of the reload protocol should be hidden from app level users of the
// transaction layer. Methods are opqaue to the tranport layer, but a certain
// amount of interaction will be required.
// 1. A mechanism to correleate requests and responses
// 2. Enough information to populate a Via list
// It is unclear how much more information should be required by the transaction
// layer API.
//this approach exposes a limited message concept which will contrcut transation
//ids...similar to how resip populates a tid when a via header is
//created. Subclasses(store_q, fetch_q, etc) will infer a destination list whenever possible.
//Dignature operations are hidden; signature check methods are expsoed where
//apropriate.
class MessageFactory() // some sort sort of factory sigleton for pasing data from the
// wire and forming a new message of the correc type
// (like FetchReq for example)
{
public:
static ReloadMeassage* parseData( Data msg );
}
// Show me what the elements of a DestinationList look like given they are a
// variant record
class Message
{
public:
DestinationList destinationList();
ViaList viaList(); //is this useful or just diagnostic? (CJ - have to use it )
TransactionId transactionId(); //populated at const. time(for requests)
MessageContents contents();
virtual Data encode();
};
//note that signature is not exposed
class MessageContents
{
public:
virtual u_int16 messageCode() const=0; //should we req. subclassing?
virtual Data payload();
private:
};
// needs classes simular to this for all the message types
class FetchReq : public Message // Should we derive off Message or
// MEssageContents ????
{
public:
}
class FetchAns : public Message
{
public:
}
//base class for MessageContents which can hint at routing?
//shared ptr. for poly. list? Ownership should be clear.
class StoreReq : public MessageContents
{
public:
typedef std::list<StoreKindData*> StoreList();
ResourceID resource();
StoreList storeList();
};
//variants here?
class StoreKindData
{
KindId kindId();
Generation generation();
};
//data model classes
/* Basic operation--2 phase
Contrsuct StoreQ.
call reloadTrans->makeRequest(StoreQ);
custom modification if necessary, store tid
call reloadTrans->send(req)
ownership?
Sepcifying a per-operation/per-kind sink will avoid unecessary demux cod ein the
app.
*/
//from rutil...
class FifoHandler
{
public:
void post(Message m);
};
void dhtSipRegister()
{
//setup stuff...dht
ReloadTransaction reloadTrans;
StoreQ s = reloadTrans->makeStoreQ(unhashedId, kind);
//install payload into s
//per-request handler model
reloadTrans->send(s, handler);
}
//1 per data model?
class StoreQHandler
{
void onFailure(..);
void onSuccess(StoreQResponse);
};
// Each peer in th dht is providing a service to store data; there are light
// validation rules, but it seems that the data can be treated as opaque. The
// main issue is that the kind-id must be supported. I'm not sure if generation
// calcuations should involve the app at all.
//one of these is installed for each kind/dm supported. There will be a subclass
//for each DM. We can use static_cast for the calls or do templates w/ no
//subclassing. Signature checking is done by the sig. service and hidden from
//the app.
class ValidateCRUD
{
};
class ValidateDictionary : public ValidateCRUD
{
typedef vector<pair<Data, DictEntry>> Dictionary;
bool isValid(const Resourse& r, const Dictionary& d, Generation gen);
};
// storage services are also installed onse per kind/DM
class CRUDService
{
};
class DictionaryService
{
Generation update(const Resourse& r, const Dictionary& d);
//not sure about generation here....
Generation delete(const Resourse& r);
};
class ServiceMap
{
public:
void registerKind();
map<KindId, Validate>;
};
class ConnectRequest
{
//peer id
//protocol
};
//under the hood mechanisms that need to be fleshed out
// signature validation/signing service
/* How do we wire this into resip?
- Fetch-Q for location mapped into 3263 style dns lookup
- transactionState will convey that this is dht to the transportSelector
- TS will try various alternatives
*/
|
