~justin-fathomdb/nova/justinsb-openstack-api-volumes

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'><html lang="en" xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Twisted Documentation: Managing Clients of Perspectives</title>

<h1 class="title">Managing Clients of Perspectives</h1>

<div class="toc"><ol><li><a href="#auto0">Overview</a></li><li><a href="#auto1">Managing Avatars</a></li><li><a href="#auto2">Managing Clients</a></li></ol></div>

<h2>Overview<a name="auto0"/></h2>

In all the <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.spread.pb.IPerspective.html" title="twisted.spread.pb.IPerspective">IPerspective</a></code>

we have shown so far, we ignored the <code>mind</code> argument and created

a new <code>Avatar</code> for every connection. This is usually an easy

design choice, and it works well for simple cases.

In more complicated cases, for example an <code>Avatar</code> that

represents a player object which is persistent in the game universe,

we will want connections from the same player to use the same

<code>Avatar</code>.

Another thing which is necessary in more complicated scenarios

is notifying a player asynchronously. While it is possible, of

course, to allow a player to call

<code>perspective_remoteListener(referencable)</code> that would

mean both duplication of code and a higher latency in logging in,

both bad.

In previous sections all realms looked to be identical.

In this one we will show the usefulness of realms in accomplishing

those two objectives.

<h2>Managing Avatars<a name="auto1"/></h2>

The simplest way to manage persistent avatars is to use a straight-forward

caching mechanism:

<pre class="python"> 1

from zope.interface import implements

class SimpleAvatar(pb.Avatar):

greetings = 0

def __init__(self, name):

self.name = name

def perspective_greet(self):

self.greetings += 1

return "<%d>hello %s" % (self.greetings, self.name)

class CachingRealm:

implements(portal.IRealm)

def __init__(self):

self.avatars = {}

def requestAvatar(self, avatarId, mind, *interfaces):

if pb.IPerspective not in interfaces: raise NotImplementedError

if avatarId in self.avatars:

p = self.avatars[avatarId]

else:

p = self.avatars[avatarId] = SimpleAvatar(avatarId)

return pb.IPerspective, p, lambda:None

</pre>

This gives us a perspective which counts the number of greetings it

sent its client. Implementing a caching strategy, as opposed to generating

a realm with the correct avatars already in it, is usually easier. This

makes adding new checkers to the portal, or adding new users to a checker

database, transparent. Otherwise, careful synchronization is needed between

the checker and avatar is needed (much like the synchronization between

UNIX's <code>/etc/shadow</code> and <code>/etc/passwd</code>).

Sometimes, however, an avatar will need enough per-connection state

that it would be easier to generate a new avatar and cache something

else. Here is an example of that:

100

101

<pre class="python"> 1

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

class Greeter:

133

greetings = 0

134

def hello(self):

135

self.greetings += 1

136

return "<%d>hello" % (self.greetings, self.name)

137

138

class SimpleAvatar(pb.Avatar):

139

greetings = 0

140

def __init__(self, name, greeter):

141

self.name = name

142

self.greeter = greeter

143

def perspective_greet(self):

144

return self.greeter.hello()+' '+self.name

145

146

class CachingRealm:

147

implements(portal.IRealm)

148

149

def __init__(self):

150

self.greeters = {}

151

152

153

154

155

p = self.greeters[avatarId]

156

else:

157

p = self.greeters[avatarId] = Greeter()

158

return pb.IPerspective, SimpleAvatar(avatarId, p), lambda:None

159

</pre>

160

161

It might seem tempting to use this pattern to have an avatar which

162

is notified of new connections. However, the problems here are twofold:

163

it would lead to a thin class which needs to forward all of its methods,

164

and it would be impossible to know when disconnections occur. Luckily,

165

there is a better pattern:

166

167

<pre class="python"> 1

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

class SimpleAvatar(pb.Avatar):

199

greetings = 0

200

connections = 0

201

def __init__(self, name):

202

self.name = name

203

def connect(self):

204

self.connections += 1

205

def disconnect(self):

206

self.connections -= 1

207

def perspective_greet(self):

208

self.greetings += 1

209

210

211

class CachingRealm:

212

implements(portal.IRealm)

213

214

def __init__(self):

215

self.avatars = {}

216

217

218

219

220

p = self.avatars[avatarId]

221

else:

222

223

p.connect()

224

return pb.IPerspective, p, p.disconnect

225

</pre>

226

227

It is possible to use such a pattern to define an arbitrary limit for

228

the number of concurrent connections:

229

230

<pre class="python"> 1

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

class SimpleAvatar(pb.Avatar):

265

greetings = 0

266

connections = 0

267

def __init__(self, name):

268

self.name = name

269

def connect(self):

270

self.connections += 1

271

def disconnect(self):

272

self.connections -= 1

273

def perspective_greet(self):

274

self.greetings += 1

275

276

277

class CachingRealm:

278

implements(portal.IRealm)

279

280

281

self.avatars = {}

282

self.max = max

283

284

285

286

287

p = self.avatars[avatarId]

288

else:

289

290

if p.connections >= self.max:

291

raise ValueError("too many connections")

292

p.connect()

293

return pb.IPerspective, p, p.disconnect

294

</pre>

295

296

<h2>Managing Clients<a name="auto2"/></h2>

297

298

So far, all our realms have ignored the <code>mind</code> argument.

299

In the case of PB, the <code>mind</code> is an object supplied by

300

the remote login method -- usually, when it passes over the wire,

301

it becomes a <code>pb.RemoteReference</code>. This object allows

302

sending messages to the client as soon as the connection is established

303

and authenticated.

304

305

Here is a simple remote-clock application which shows the usefulness

306

of the <code>mind</code> argument:

307

308

<pre class="python"> 1

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

class SimpleAvatar(pb.Avatar):

334

def __init__(self, client):

335

self.s = internet.TimerService(1, self.telltime)

336

self.s.startService()

337

self.client = client

338

def telltime(self):

339

self.client.callRemote("notifyTime", time.time())

340

def perspective_setperiod(self, period):

341

self.s.stopService()

342

self.s = internet.TimerService(period, self.telltime)

343

self.s.startService()

344

def logout(self):

345

self.s.stopService()

346

347

class Realm:

348

implements(portal.IRealm)

349

350

351

352

p = SimpleAvatar(mind)

353

return pb.IPerspective, p, p.logout

354

</pre>

355

356

In more complicated situations, you might want to cache the avatars

357

and give each one a set of <q>current clients</q> or something similar.

358

359

</div>

360

361

<a href="index.html">Index</a>

362

Version: 10.0.0

363

</body>

364

</html>

b'\\ No newline at end of file'

Older »