~dkuhlman/python-training-materials/Materials

<code class="docutils literal">write</code> something, and then <code class="docutils literal">read</code> for a reply. Without a <code class="docutils literal">flush</code> in

210

there, you may wait forever for the reply, because the request may still be in

211

your output buffer.

212

Now we come to the major stumbling block of sockets - <code class="docutils literal">send</code> and <code class="docutils literal">recv</code> operate

213

on the network buffers. They do not necessarily handle all the bytes you hand

214

them (or expect from them), because their major focus is handling the network

215

buffers. In general, they return when the associated network buffers have been

216

filled (<code class="docutils literal">send</code>) or emptied (<code class="docutils literal">recv</code>). They then tell you how many bytes they

217

handled. It is your responsibility to call them again until your message has

218

been completely dealt with.

219

When a <code class="docutils literal">recv</code> returns 0 bytes, it means the other side has closed (or is in

220

the process of closing) the connection. You will not receive any more data on

221

this connection. Ever. You may be able to send data successfully; I’ll talk

222

more about this later.

223

A protocol like HTTP uses a socket for only one transfer. The client sends a

224

request, then reads a reply. That’s it. The socket is discarded. This means that

225

a client can detect the end of the reply by receiving 0 bytes.

226

But if you plan to reuse your socket for further transfers, you need to realize

227

that there is no <abbr title="End of Transfer">EOT</abbr> on a socket. I repeat: if a socket

228

<code class="docutils literal">send</code> or <code class="docutils literal">recv</code> returns after handling 0 bytes, the connection has been

229

broken. If the connection has not been broken, you may wait on a <code class="docutils literal">recv</code>

230

forever, because the socket will not tell you that there’s nothing more to

231

read (for now). Now if you think about that a bit, you’ll come to realize a

232

fundamental truth of sockets: messages must either be fixed length (yuck), or

233

be delimited (shrug), or indicate how long they are (much better), or end by

234

shutting down the connection. The choice is entirely yours, (but some ways are

235

righter than others).

236

Assuming you don’t want to end the connection, the simplest solution is a fixed

237

length message:

238

<div class="highlight-python"><div class="highlight"><pre>class mysocket:

239

'''demonstration class only

240

- coded for clarity, not efficiency

241

'''

242

243

def __init__(self, sock=None):

244

if sock is None:

245

self.sock = socket.socket(

246

247

else:

248

self.sock = sock

249

250

def connect(self, host, port):

251

self.sock.connect((host, port))

252

253

def mysend(self, msg):

254

totalsent = 0

255

while totalsent < MSGLEN:

256

sent = self.sock.send(msg[totalsent:])

257

if sent == 0:

258

raise RuntimeError("socket connection broken")

259

totalsent = totalsent + sent

260

261

def myreceive(self):

262

chunks = []

263

bytes_recd = 0

264

while bytes_recd < MSGLEN:

265

chunk = self.sock.recv(min(MSGLEN - bytes_recd, 2048))

266

if chunk == '':

267

raise RuntimeError("socket connection broken")

268

chunks.append(chunk)

269

bytes_recd = bytes_recd + len(chunk)

270

return ''.join(chunks)

271

</pre></div>

272

</div>

273

The sending code here is usable for almost any messaging scheme - in Python you

274

send strings, and you can use <code class="docutils literal">len()</code> to determine its length (even if it has

275

embedded <code class="docutils literal">\0</code> characters). It’s mostly the receiving code that gets more

276

complex. (And in C, it’s not much worse, except you can’t use <code class="docutils literal">strlen</code> if the

277

message has embedded <code class="docutils literal">\0</code>s.)

278

The easiest enhancement is to make the first character of the message an

279

indicator of message type, and have the type determine the length. Now you have

280

two <code class="docutils literal">recv</code>s - the first to get (at least) that first character so you can

281

look up the length, and the second in a loop to get the rest. If you decide to

282

go the delimited route, you’ll be receiving in some arbitrary chunk size, (4096

283

or 8192 is frequently a good match for network buffer sizes), and scanning what

284

you’ve received for a delimiter.

285

One complication to be aware of: if your conversational protocol allows multiple

286

messages to be sent back to back (without some kind of reply), and you pass

287

<code class="docutils literal">recv</code> an arbitrary chunk size, you may end up reading the start of a

288

following message. You’ll need to put that aside and hold onto it, until it’s

289

needed.

290

Prefixing the message with its length (say, as 5 numeric characters) gets more

291

complex, because (believe it or not), you may not get all 5 characters in one

292

<code class="docutils literal">recv</code>. In playing around, you’ll get away with it; but in high network loads,

293

your code will very quickly break unless you use two <code class="docutils literal">recv</code> loops - the first

294

to determine the length, the second to get the data part of the message. Nasty.

295

This is also when you’ll discover that <code class="docutils literal">send</code> does not always manage to get

296

rid of everything in one pass. And despite having read this, you will eventually

297

get bit by it!

298

In the interests of space, building your character, (and preserving my

299

competitive position), these enhancements are left as an exercise for the

300

reader. Lets move on to cleaning up.

301

302

<h3>Binary Data<a class="headerlink" href="#binary-data" title="Permalink to this headline">¶</a></h3>

303

It is perfectly possible to send binary data over a socket. The major problem is

304

that not all machines use the same formats for binary data. For example, a

305

Motorola chip will represent a 16 bit integer with the value 1 as the two hex

306

bytes 00 01. Intel and DEC, however, are byte-reversed - that same 1 is 01 00.

307

Socket libraries have calls for converting 16 and 32 bit integers - <code class="docutils literal">ntohl,

308

htonl, ntohs, htons</code> where “n” means network and “h” means host, “s” means

309

short and “l” means long. Where network order is host order, these do

310

nothing, but where the machine is byte-reversed, these swap the bytes around

311

appropriately.

312

In these days of 32 bit machines, the ascii representation of binary data is

313

frequently smaller than the binary representation. That’s because a surprising

314

amount of the time, all those longs have the value 0, or maybe 1. The string “0”

315

would be two bytes, while binary is four. Of course, this doesn’t fit well with

316

fixed-length messages. Decisions, decisions.

317

</div>

318

</div>

319

320

<h2>Disconnecting<a class="headerlink" href="#disconnecting" title="Permalink to this headline">¶</a></h2>

321

Strictly speaking, you’re supposed to use <code class="docutils literal">shutdown</code> on a socket before you

322

<code class="docutils literal">close</code> it. The <code class="docutils literal">shutdown</code> is an advisory to the socket at the other end.

323

Depending on the argument you pass it, it can mean “I’m not going to send

324

anymore, but I’ll still listen”, or “I’m not listening, good riddance!”. Most

325

socket libraries, however, are so used to programmers neglecting to use this

326

piece of etiquette that normally a <code class="docutils literal">close</code> is the same as <code class="docutils literal">shutdown();

327

close()</code>. So in most situations, an explicit <code class="docutils literal">shutdown</code> is not needed.

328

One way to use <code class="docutils literal">shutdown</code> effectively is in an HTTP-like exchange. The client

329

sends a request and then does a <code class="docutils literal">shutdown(1)</code>. This tells the server “This

330

client is done sending, but can still receive.” The server can detect “EOF” by

331

a receive of 0 bytes. It can assume it has the complete request. The server

332

sends a reply. If the <code class="docutils literal">send</code> completes successfully then, indeed, the client

333

was still receiving.

334

Python takes the automatic shutdown a step further, and says that when a socket

335

is garbage collected, it will automatically do a <code class="docutils literal">close</code> if it’s needed. But

336

relying on this is a very bad habit. If your socket just disappears without

337

doing a <code class="docutils literal">close</code>, the socket at the other end may hang indefinitely, thinking

338

you’re just being slow. Please <code class="docutils literal">close</code> your sockets when you’re done.

339

340

<h3>When Sockets Die<a class="headerlink" href="#when-sockets-die" title="Permalink to this headline">¶</a></h3>

341

Probably the worst thing about using blocking sockets is what happens when the

342

other side comes down hard (without doing a <code class="docutils literal">close</code>). Your socket is likely to

343

hang. SOCKSTREAM is a reliable protocol, and it will wait a long, long time

344

before giving up on a connection. If you’re using threads, the entire thread is

345

essentially dead. There’s not much you can do about it. As long as you aren’t

346

doing something dumb, like holding a lock while doing a blocking read, the

347

thread isn’t really consuming much in the way of resources. Do not try to kill

348

the thread - part of the reason that threads are more efficient than processes

349

is that they avoid the overhead associated with the automatic recycling of

350

resources. In other words, if you do manage to kill the thread, your whole

351

process is likely to be screwed up.

352

</div>

353

</div>

354

355

<h2>Non-blocking Sockets<a class="headerlink" href="#non-blocking-sockets" title="Permalink to this headline">¶</a></h2>

356

If you’ve understood the preceding, you already know most of what you need to

357

know about the mechanics of using sockets. You’ll still use the same calls, in

358

much the same ways. It’s just that, if you do it right, your app will be almost

359

inside-out.

360

In Python, you use <code class="docutils literal">socket.setblocking(0)</code> to make it non-blocking. In C, it’s

361

more complex, (for one thing, you’ll need to choose between the BSD flavor

362

<code class="docutils literal">O_NONBLOCK</code> and the almost indistinguishable Posix flavor <code class="docutils literal">O_NDELAY</code>, which

363

is completely different from <code class="docutils literal">TCP_NODELAY</code>), but it’s the exact same idea. You

364

do this after creating the socket, but before using it. (Actually, if you’re

365

nuts, you can switch back and forth.)

366

The major mechanical difference is that <code class="docutils literal">send</code>, <code class="docutils literal">recv</code>, <code class="docutils literal">connect</code> and

367

<code class="docutils literal">accept</code> can return without having done anything. You have (of course) a

368

number of choices. You can check return code and error codes and generally drive

369

yourself crazy. If you don’t believe me, try it sometime. Your app will grow

370

large, buggy and suck CPU. So let’s skip the brain-dead solutions and do it

371

right.

372

Use <code class="docutils literal">select</code>.

373

In C, coding <code class="docutils literal">select</code> is fairly complex. In Python, it’s a piece of cake, but

374

it’s close enough to the C version that if you understand <code class="docutils literal">select</code> in Python,

375

you’ll have little trouble with it in C:

376

<div class="highlight-python"><div class="highlight"><pre>ready_to_read, ready_to_write, in_error = \

377

select.select(

378

potential_readers,

379

potential_writers,

380

potential_errs,

381

timeout)

382

</pre></div>

383

</div>

384

You pass <code class="docutils literal">select</code> three lists: the first contains all sockets that you might

385

want to try reading; the second all the sockets you might want to try writing

386

to, and the last (normally left empty) those that you want to check for errors.

387

You should note that a socket can go into more than one list. The <code class="docutils literal">select</code>

388

call is blocking, but you can give it a timeout. This is generally a sensible

389

thing to do - give it a nice long timeout (say a minute) unless you have good

390

reason to do otherwise.

391

In return, you will get three lists. They contain the sockets that are actually

392

readable, writable and in error. Each of these lists is a subset (possibly

393

empty) of the corresponding list you passed in.

394

If a socket is in the output readable list, you can be

395

as-close-to-certain-as-we-ever-get-in-this-business that a <code class="docutils literal">recv</code> on that

396

socket will return something. Same idea for the writable list. You’ll be able

397

to send something. Maybe not all you want to, but something is better than

398

nothing. (Actually, any reasonably healthy socket will return as writable - it

399

just means outbound network buffer space is available.)

400

If you have a “server” socket, put it in the potential_readers list. If it comes

401

out in the readable list, your <code class="docutils literal">accept</code> will (almost certainly) work. If you

402

have created a new socket to <code class="docutils literal">connect</code> to someone else, put it in the

403

potential_writers list. If it shows up in the writable list, you have a decent

404

chance that it has connected.

405

One very nasty problem with <code class="docutils literal">select</code>: if somewhere in those input lists of

406

sockets is one which has died a nasty death, the <code class="docutils literal">select</code> will fail. You then

407

need to loop through every single damn socket in all those lists and do a

408

<code class="docutils literal">select([sock],[],[],0)</code> until you find the bad one. That timeout of 0 means

409

it won’t take long, but it’s ugly.

410

Actually, <code class="docutils literal">select</code> can be handy even with blocking sockets. It’s one way of

411

determining whether you will block - the socket returns as readable when there’s

412

something in the buffers. However, this still doesn’t help with the problem of

413

determining whether the other end is done, or just busy with something else.

414

Portability alert: On Unix, <code class="docutils literal">select</code> works both with the sockets and

415

files. Don’t try this on Windows. On Windows, <code class="docutils literal">select</code> works with sockets

416

only. Also note that in C, many of the more advanced socket options are done

417

differently on Windows. In fact, on Windows I usually use threads (which work

418

very, very well) with my sockets. Face it, if you want any kind of performance,

419

your code will look very different on Windows than on Unix.

420

421

<h3>Performance<a class="headerlink" href="#performance" title="Permalink to this headline">¶</a></h3>

422

There’s no question that the fastest sockets code uses non-blocking sockets and

423

select to multiplex them. You can put together something that will saturate a

424

LAN connection without putting any strain on the CPU. The trouble is that an app

425

written this way can’t do much of anything else - it needs to be ready to

426

shuffle bytes around at all times.

427

Assuming that your app is actually supposed to do something more than that,

428

threading is the optimal solution, (and using non-blocking sockets will be

429

faster than using blocking sockets). Unfortunately, threading support in Unixes

430

varies both in API and quality. So the normal Unix solution is to fork a

431

subprocess to deal with each connection. The overhead for this is significant

432

(and don’t do this on Windows - the overhead of process creation is enormous

433

there). It also means that unless each subprocess is completely independent,

434

you’ll need to use another form of IPC, say a pipe, or shared memory and

435

semaphores, to communicate between the parent and child processes.

436

Finally, remember that even though blocking sockets are somewhat slower than

437

non-blocking, in many cases they are the “right” solution. After all, if your

438

app is driven by the data it receives over a socket, there’s not much sense in

439

complicating the logic just so your app can wait on <code class="docutils literal">select</code> instead of

440

<code class="docutils literal">recv</code>.

441

</div>

442

</div>

443

</div>

444

445

446

</div>

447

</div>

448

</div>

449

450

451

<h3><a href="../contents.html">Table Of Contents</a></h3>

452

<ul>

453

<li><a class="reference internal" href="#">Socket Programming HOWTO</a><ul>

454

<li><a class="reference internal" href="#sockets">Sockets</a><ul>

455

<li><a class="reference internal" href="#history">History</a></li>

456

</ul>

457

</li>

458

<li><a class="reference internal" href="#creating-a-socket">Creating a Socket</a><ul>

459

460

</ul>

461

</li>

462

<li><a class="reference internal" href="#using-a-socket">Using a Socket</a><ul>

463

<li><a class="reference internal" href="#binary-data">Binary Data</a></li>

464

</ul>

465

</li>

466

<li><a class="reference internal" href="#disconnecting">Disconnecting</a><ul>

467

<li><a class="reference internal" href="#when-sockets-die">When Sockets Die</a></li>

468

</ul>

469

</li>

470

<li><a class="reference internal" href="#non-blocking-sockets">Non-blocking Sockets</a><ul>

471

<li><a class="reference internal" href="#performance">Performance</a></li>

472

</ul>

473

</li>

474

</ul>

475

</li>

476

</ul>

477

478

<h4>Previous topic</h4>

479

<a href="regex.html"

480

title="previous chapter">Regular Expression HOWTO</a>

481

<h4>Next topic</h4>

482

<a href="sorting.html"

483

title="next chapter">Sorting HOW TO</a>

484

485

486

<li><a href="../bugs.html">Report a Bug</a></li>

487

<li><a href="../_sources/howto/sockets.txt"

488

rel="nofollow">Show Source</a></li>

489

</ul>

490

491

492

<h3>Quick search</h3>

493

494

495

496

497

498

</form>

499

500

Enter search terms or a module, class or function name.

501

502

</div>

503

504

</div>

505

</div>

506

507

</div>

508

509

<h3>Navigation</h3>

510

<ul>

511

512

<a href="../genindex.html" title="General Index"

513

>index</a></li>

514

515

<a href="../py-modindex.html" title="Python Module Index"

516

>modules</a> |</li>

517

518

<a href="sorting.html" title="Sorting HOW TO"

519

>next</a> |</li>

520

521

<a href="regex.html" title="Regular Expression HOWTO"

522

>previous</a> |</li>

523

<li><img src="../_static/py.png" alt=""

524

style="vertical-align: middle; margin-top: -1px"/></li>

525

<li><a href="https://www.python.org/">Python</a> »</li>

526

<li>

527

2.7.12

528

<a href="../index.html">Documentation</a> »

529

</li>

530

531

<li class="nav-item nav-item-1"><a href="index.html" >Python HOWTOs</a> »</li>

532

</ul>

533

</div>

534

535

536

537

The Python Software Foundation is a non-profit corporation.

538

<a href="https://www.python.org/psf/donations/">Please donate.</a>

539

540

Last updated on Sep 20, 2016.

541

<a href="../bugs.html">Found a bug</a>?

542

543

Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.3.3.

544

</div>

545

546

</body>

547

</html>

b'\\ No newline at end of file'

Older »