~soren/nova/iptables-security-groups

<?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: UDP Networking</title>

</head>

<h1 class="title">UDP Networking</h1>

<div class="toc"><ol><li><a href="#auto0">Overview</a></li><li><a href="#auto1">DatagramProtocol</a></li><li><a href="#auto2">Connected UDP</a></li><li><a href="#auto3">Multicast UDP</a></li><li><a href="#auto4">Acknowledgements</a></li></ol></div>

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

Unlike TCP, UDP has no notion of connections. A UDP socket can receive

datagrams from any server on the network, and send datagrams to any host

on the network. In addition, datagrams may arrive in any order, never

arrive at all, or be duplicated in transit.

Since there are no multiple connections, we only use a single object,

a protocol, for each UDP socket. We then use the reactor to connect

this protocol to a UDP transport, using the

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.interfaces.IReactorUDP.html" title="twisted.internet.interfaces.IReactorUDP">twisted.internet.interfaces.IReactorUDP</a></code>

reactor API.

<h2>DatagramProtocol<a name="auto1"/></h2>

At the base, the place where you actually implement the protocol

parsing and handling, is the DatagramProtocol class. This class will

usually be decended from <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.protocol.DatagramProtocol.html" title="twisted.internet.protocol.DatagramProtocol">twisted.internet.protocol.DatagramProtocol</a></code>. Most

protocol handlers inherit either from this class or from one of its

convenience children. The DatagramProtocol class receives datagrams, and

can send them out over the network. Received datagrams include the

address they were sent from, and when sending datagrams the address to

send to must be specified.

Here is a simple example:

<pre class="python"> 1

from twisted.internet.protocol import DatagramProtocol

from twisted.internet import reactor

class Echo(DatagramProtocol):

def datagramReceived(self, data, (host, port)):

print "received %r from %s:%d" % (data, host, port)

self.transport.write(data, (host, port))

reactor.listenUDP(9999, Echo())

reactor.run()

</pre>

As you can see, the protocol is registed with the reactor. This means

it may be persisted if it's added to an application, and thus it has

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.protocol.DatagramProtocol.startProtocol.html" title="twisted.internet.protocol.DatagramProtocol.startProtocol">twisted.internet.protocol.DatagramProtocol.startProtocol</a></code>

and <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.protocol.DatagramProtocol.stopProtocol.html" title="twisted.internet.protocol.DatagramProtocol.stopProtocol">twisted.internet.protocol.DatagramProtocol.stopProtocol</a></code>

methods that will get called when the protocol is connected and

disconnected from a UDP socket.

The protocol's <code class="python">transport</code> attribute will

implement the <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.interfaces.IUDPTransport.html" title="twisted.internet.interfaces.IUDPTransport">twisted.internet.interfaces.IUDPTransport</a></code> interface.

Notice that the <code class="python">host</code> argument should be an

IP, not a hostname. If you only have the hostname use <code class="python">reactor.resolve()</code> to resolve the address (see <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.interfaces.IReactorCore.resolve.html" title="twisted.internet.interfaces.IReactorCore.resolve">twisted.internet.interfaces.IReactorCore.resolve</a></code>).

<h2>Connected UDP<a name="auto2"/></h2>

A connected UDP socket is slighly different from a standard one - it

can only send and receive datagrams to/from a single address, but this

does not in any way imply a connection. Datagrams may still arrive in any

order, and the port on the other side may have no one listening. The

benefit of the connected UDP socket is that it it may

provide notification of undelivered packages. This depends on many

factors, almost all of which are out of the control of the application,

but it still presents certain benefits which occassionally make it

useful.

Unlike a regular UDP protocol, we do not need to specify where to

send datagrams to, and are not told where they came from since

they can only come from address the socket is 'connected' to.

<pre class="python"> 1

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

class Helloer(DatagramProtocol):

116

117

def startProtocol(self):

118

self.transport.connect("192.168.1.1", 1234)

119

print "we can only send to %s now" % str((host, port))

120

self.transport.write("hello") # no need for address

121

122

123

124

125

# Possibly invoked if there is no server listening on the

126

# address to which we are sending.

127

def connectionRefused(self):

128

print "No one listening"

129

130

# 0 means any port, we don't care in this case

131

reactor.listenUDP(0, Helloer())

132

reactor.run()

133

</pre>

134

135

Note that <code class="python">connect()</code>, like <code class="python">write()</code> will only accept IP addresses, not

136

unresolved domain names. To obtain the IP of a domain name use <code class="python">reactor.resolve()</code>, e.g.:

137

138

<pre class="python">1

139

140

141

142

143

144

from twisted.internet import reactor

145

146

def gotIP(ip):

147

print "IP of 'example.com' is", ip

148

149

reactor.resolve('example.com').addCallback(gotIP)

150

</pre>

151

152

Connecting to a new address after a previous connection, or

153

making a connected port unconnected are not currently supported,

154

but will likely be supported in the future.

155

156

<h2>Multicast UDP<a name="auto3"/></h2>

157

158

A multicast UDP socket can send and receive datagrams from multiple clients.

159

The interesting and useful feature of the multicast is that a client can

160

contact multiple servers with a single packet, without knowing the specific IP

161

of any of the hosts.

162

163

<div class="py-listing"><pre> 1

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

from twisted.application.internet import MulticastServer

191

192

class MulticastServerUDP(DatagramProtocol):

193

def startProtocol(self):

194

print 'Started Listening'

195

# Join a specific multicast group, which is the IP we will respond to

196

self.transport.joinGroup('224.0.0.1')

197

198

def datagramReceived(self, datagram, address):

199

# The uniqueID check is to ensure we only service requests from

200

# ourselves

201

if datagram == 'UniqueID':

202

print "Server Received:" + repr(datagram)

203

self.transport.write("data", address)

204

205

# Note that the join function is picky about having a unique object

206

# on which to call join. To avoid using startProtocol, the following is

207

# sufficient:

208

#reactor.listenMulticast(8005, MulticastServerUDP()).join('224.0.0.1')

209

210

# Listen for multicast on 224.0.0.1:8005

211

reactor.listenMulticast(8005, MulticastServerUDP())

212

reactor.run()

213

</pre><div class="caption">Source listing - <a href="listings/udp/MulticastServer.py">listings/udp/MulticastServer.py</a></div></div>

214

215

216

The server protocol is very simple, and closely resembles a normal listenUDP

217

implementation. The main difference is that instead of listenUDP,

218

listenMulticast is called with a specified port number. The server must also

219

call joinGroup to specify on which multicast IP address it will service

220

requests. Another item of interest is the contents of the datagram. Many

221

different applications use multicast as a way of device discovery, which leads

222

to an abundance of packets flying around. Checking the payload can ensure

223

that we only service requests from our specific clients.

224

225

226

<div class="py-listing"><pre> 1

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

class MulticastClientUDP(DatagramProtocol):

244

245

def datagramReceived(self, datagram, address):

246

print "Received:" + repr(datagram)

247

248

# Send multicast on 224.0.0.1:8005, on our dynamically allocated port

249

reactor.listenUDP(0, MulticastClientUDP()).write('UniqueID',

250

('224.0.0.1', 8005))

251

reactor.run()

252

</pre><div class="caption">MulticastServer.py - <a href="listings/udp/MulticastClient.py">listings/udp/MulticastClient.py</a></div></div>

253

254

255

This is a mirror implementation of a standard UDP client. The only difference

256

is that the destination IP is the multicast address. This datagram will be

257

distributed to every server listening on 224.0.0.1 and port 8005. Note that

258

the client port is specified as 0, as we have no need to keep track of what

259

port the client is listening on.

260

261

262

<h2>Acknowledgements<a name="auto4"/></h2>

263

264

Thank you to all contributors to this document, including:

265

266

<ul>

267

<li>Kyle Robertson, author of the explanation and examples of multicast</li>

268

</ul>

269

270

</div>

271

272

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

273

Version: 10.0.0

274

</body>

275

</html>

b'\\ No newline at end of file'

Older »