~certify-web-dev/twisted/certify-staging

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><title>Twisted Documentation: Managing Clients of Perspectives</title><link href="stylesheet.css" type="text/css" rel="stylesheet" /><link href="http://twistedmatrix.com/users/acapnotic/" rel="author" title="Kevin Turner" /></head><body bgcolor="white"><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><div class="content"><h2>Overview<a name="auto0"></a></h2>In all the <code class="API"><a href="http://twistedmatrix.com/documents/8.2.0/api/twisted.spread.pb.IPerspective.html" title="twisted.spread.pb.IPerspective">IPerspective</a></code>

<?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'>

<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/9.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

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

<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.

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"></a></h2>The simplest way to manage persistent avatars is to use a straight-forward

caching mechanism:<pre class="python">

from zope.interface import implements

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

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

</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

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

100

101

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

102

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

else. Here is an example of that:<pre class="python">

103

else. Here is an example of that:

104

105

<pre class="python"> 1

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

class Greeter:

137

greetings = 0

160

else:

161

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

162

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

</pre>It might seem tempting to use this pattern to have an avatar which

163

</pre>

164

165

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

166

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

167

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

168

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

there is a better pattern:<pre class="python">

169

there is a better pattern:

170

171

<pre class="python"> 1

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

199

200

201

202

class SimpleAvatar(pb.Avatar):

203

greetings = 0

109

226

110

227

p.connect()

111

228

return pb.IPerspective, p, p.disconnect

112

</pre>It is possible to use such a pattern to define an arbitrary limit for

113

the number of concurrent connections:<pre class="python">

114

229

</pre>

230

231

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

232

the number of concurrent connections:

233

234

<pre class="python"> 1

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

265

266

115

267

116

268

class SimpleAvatar(pb.Avatar):

117

269

greetings = 0

143

295

raise ValueError("too many connections")

144

296

p.connect()

145

297

return pb.IPerspective, p, p.disconnect

146

</pre><h2>Managing Clients<a name="auto2"></a></h2>So far, all our realms have ignored the <code>mind</code> argument.

298

</pre>

299

300

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

301

302

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

147

303

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

148

304

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

149

305

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

150

306

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

151

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

152

of the <code>mind</code> argument:<pre class="python">

153

307

and authenticated.

308

309

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

310

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

311

312

<pre class="python"> 1

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

154

336

155

337

class SimpleAvatar(pb.Avatar):

156

338

def __init__(self, client):

173

355

if pb.IPerspective not in interfaces: raise NotImplementedError

174

356

p = SimpleAvatar(mind)

175

357

return pb.IPerspective, p, p.logout

176

</pre>In more complicated situations, you might want to cache the avatars

177

and give each one a set of <q>current clients</q> or something similar.</div><a href="index.html">Index</a>Version: 8.2.0</body></html>

b'\\ No newline at end of file'

358

</pre>

359

360

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

361

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

362

363

</div>

364

365

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

366

Version: 9.0.0

367

</body>

368

</html>

b'\\ No newline at end of file'

Older »