← Back to branch summary

~ubuntu-branches/ubuntu/saucy/resiprocate/saucy-proposed

« back to all changes in this revision

Viewing changes to p2p/TransApi.hxx

  • Committer: Package Import Robot
  • Author(s): Daniel Pocock
  • Date: 2012-05-17 19:29:59 UTC
  • Revision ID: package-import@ubuntu.com-20120517192959-vv00m77isztdy64q
Tags: upstream-1.8.2
Import upstream version 1.8.2

Show diffs side-by-side

added added

removed removed

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