538 lines
40 KiB
HTML
538 lines
40 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<title>Socket Programming HOWTO — Python 3.7.4 documentation</title>
|
||
<link rel="stylesheet" href="../_static/pydoctheme.css" type="text/css" />
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
|
||
|
||
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
|
||
<script type="text/javascript" src="../_static/jquery.js"></script>
|
||
<script type="text/javascript" src="../_static/underscore.js"></script>
|
||
<script type="text/javascript" src="../_static/doctools.js"></script>
|
||
<script type="text/javascript" src="../_static/language_data.js"></script>
|
||
|
||
<script type="text/javascript" src="../_static/sidebar.js"></script>
|
||
|
||
<link rel="search" type="application/opensearchdescription+xml"
|
||
title="Search within Python 3.7.4 documentation"
|
||
href="../_static/opensearch.xml"/>
|
||
<link rel="author" title="About these documents" href="../about.html" />
|
||
<link rel="index" title="Index" href="../genindex.html" />
|
||
<link rel="search" title="Search" href="../search.html" />
|
||
<link rel="copyright" title="Copyright" href="../copyright.html" />
|
||
<link rel="next" title="Sorting HOW TO" href="sorting.html" />
|
||
<link rel="prev" title="Regular Expression HOWTO" href="regex.html" />
|
||
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
|
||
<link rel="canonical" href="https://docs.python.org/3/howto/sockets.html" />
|
||
|
||
<script type="text/javascript" src="../_static/copybutton.js"></script>
|
||
<script type="text/javascript" src="../_static/switchers.js"></script>
|
||
|
||
|
||
|
||
<style>
|
||
@media only screen {
|
||
table.full-width-table {
|
||
width: 100%;
|
||
}
|
||
}
|
||
</style>
|
||
|
||
|
||
</head><body>
|
||
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="../genindex.html" title="General Index"
|
||
accesskey="I">index</a></li>
|
||
<li class="right" >
|
||
<a href="../py-modindex.html" title="Python Module Index"
|
||
>modules</a> |</li>
|
||
<li class="right" >
|
||
<a href="sorting.html" title="Sorting HOW TO"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="regex.html" title="Regular Expression HOWTO"
|
||
accesskey="P">previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">Python HOWTOs</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="document">
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
<div class="body" role="main">
|
||
|
||
<div class="section" id="socket-programming-howto">
|
||
<span id="socket-howto"></span><h1>Socket Programming HOWTO<a class="headerlink" href="#socket-programming-howto" title="Permalink to this headline">¶</a></h1>
|
||
<dl class="field-list simple">
|
||
<dt class="field-odd">Author</dt>
|
||
<dd class="field-odd"><p>Gordon McMillan</p>
|
||
</dd>
|
||
</dl>
|
||
<div class="topic">
|
||
<p class="topic-title first">Abstract</p>
|
||
<p>Sockets are used nearly everywhere, but are one of the most severely
|
||
misunderstood technologies around. This is a 10,000 foot overview of sockets.
|
||
It’s not really a tutorial - you’ll still have work to do in getting things
|
||
operational. It doesn’t cover the fine points (and there are a lot of them), but
|
||
I hope it will give you enough background to begin using them decently.</p>
|
||
</div>
|
||
<div class="section" id="sockets">
|
||
<h2>Sockets<a class="headerlink" href="#sockets" title="Permalink to this headline">¶</a></h2>
|
||
<p>I’m only going to talk about INET (i.e. IPv4) sockets, but they account for at least 99% of
|
||
the sockets in use. And I’ll only talk about STREAM (i.e. TCP) sockets - unless you really
|
||
know what you’re doing (in which case this HOWTO isn’t for you!), you’ll get
|
||
better behavior and performance from a STREAM socket than anything else. I will
|
||
try to clear up the mystery of what a socket is, as well as some hints on how to
|
||
work with blocking and non-blocking sockets. But I’ll start by talking about
|
||
blocking sockets. You’ll need to know how they work before dealing with
|
||
non-blocking sockets.</p>
|
||
<p>Part of the trouble with understanding these things is that “socket” can mean a
|
||
number of subtly different things, depending on context. So first, let’s make a
|
||
distinction between a “client” socket - an endpoint of a conversation, and a
|
||
“server” socket, which is more like a switchboard operator. The client
|
||
application (your browser, for example) uses “client” sockets exclusively; the
|
||
web server it’s talking to uses both “server” sockets and “client” sockets.</p>
|
||
<div class="section" id="history">
|
||
<h3>History<a class="headerlink" href="#history" title="Permalink to this headline">¶</a></h3>
|
||
<p>Of the various forms of <abbr title="Inter Process Communication">IPC</abbr>,
|
||
sockets are by far the most popular. On any given platform, there are
|
||
likely to be other forms of IPC that are faster, but for
|
||
cross-platform communication, sockets are about the only game in town.</p>
|
||
<p>They were invented in Berkeley as part of the BSD flavor of Unix. They spread
|
||
like wildfire with the Internet. With good reason — the combination of sockets
|
||
with INET makes talking to arbitrary machines around the world unbelievably easy
|
||
(at least compared to other schemes).</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="creating-a-socket">
|
||
<h2>Creating a Socket<a class="headerlink" href="#creating-a-socket" title="Permalink to this headline">¶</a></h2>
|
||
<p>Roughly speaking, when you clicked on the link that brought you to this page,
|
||
your browser did something like the following:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># create an INET, STREAMing socket</span>
|
||
<span class="n">s</span> <span class="o">=</span> <span class="n">socket</span><span class="o">.</span><span class="n">socket</span><span class="p">(</span><span class="n">socket</span><span class="o">.</span><span class="n">AF_INET</span><span class="p">,</span> <span class="n">socket</span><span class="o">.</span><span class="n">SOCK_STREAM</span><span class="p">)</span>
|
||
<span class="c1"># now connect to the web server on port 80 - the normal http port</span>
|
||
<span class="n">s</span><span class="o">.</span><span class="n">connect</span><span class="p">((</span><span class="s2">"www.python.org"</span><span class="p">,</span> <span class="mi">80</span><span class="p">))</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>When the <code class="docutils literal notranslate"><span class="pre">connect</span></code> completes, the socket <code class="docutils literal notranslate"><span class="pre">s</span></code> can be used to send
|
||
in a request for the text of the page. The same socket will read the
|
||
reply, and then be destroyed. That’s right, destroyed. Client sockets
|
||
are normally only used for one exchange (or a small set of sequential
|
||
exchanges).</p>
|
||
<p>What happens in the web server is a bit more complex. First, the web server
|
||
creates a “server socket”:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># create an INET, STREAMing socket</span>
|
||
<span class="n">serversocket</span> <span class="o">=</span> <span class="n">socket</span><span class="o">.</span><span class="n">socket</span><span class="p">(</span><span class="n">socket</span><span class="o">.</span><span class="n">AF_INET</span><span class="p">,</span> <span class="n">socket</span><span class="o">.</span><span class="n">SOCK_STREAM</span><span class="p">)</span>
|
||
<span class="c1"># bind the socket to a public host, and a well-known port</span>
|
||
<span class="n">serversocket</span><span class="o">.</span><span class="n">bind</span><span class="p">((</span><span class="n">socket</span><span class="o">.</span><span class="n">gethostname</span><span class="p">(),</span> <span class="mi">80</span><span class="p">))</span>
|
||
<span class="c1"># become a server socket</span>
|
||
<span class="n">serversocket</span><span class="o">.</span><span class="n">listen</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>A couple things to notice: we used <code class="docutils literal notranslate"><span class="pre">socket.gethostname()</span></code> so that the socket
|
||
would be visible to the outside world. If we had used <code class="docutils literal notranslate"><span class="pre">s.bind(('localhost',</span>
|
||
<span class="pre">80))</span></code> or <code class="docutils literal notranslate"><span class="pre">s.bind(('127.0.0.1',</span> <span class="pre">80))</span></code> we would still have a “server” socket,
|
||
but one that was only visible within the same machine. <code class="docutils literal notranslate"><span class="pre">s.bind(('',</span> <span class="pre">80))</span></code>
|
||
specifies that the socket is reachable by any address the machine happens to
|
||
have.</p>
|
||
<p>A second thing to note: low number ports are usually reserved for “well known”
|
||
services (HTTP, SNMP etc). If you’re playing around, use a nice high number (4
|
||
digits).</p>
|
||
<p>Finally, the argument to <code class="docutils literal notranslate"><span class="pre">listen</span></code> tells the socket library that we want it to
|
||
queue up as many as 5 connect requests (the normal max) before refusing outside
|
||
connections. If the rest of the code is written properly, that should be plenty.</p>
|
||
<p>Now that we have a “server” socket, listening on port 80, we can enter the
|
||
mainloop of the web server:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">while</span> <span class="kc">True</span><span class="p">:</span>
|
||
<span class="c1"># accept connections from outside</span>
|
||
<span class="p">(</span><span class="n">clientsocket</span><span class="p">,</span> <span class="n">address</span><span class="p">)</span> <span class="o">=</span> <span class="n">serversocket</span><span class="o">.</span><span class="n">accept</span><span class="p">()</span>
|
||
<span class="c1"># now do something with the clientsocket</span>
|
||
<span class="c1"># in this case, we'll pretend this is a threaded server</span>
|
||
<span class="n">ct</span> <span class="o">=</span> <span class="n">client_thread</span><span class="p">(</span><span class="n">clientsocket</span><span class="p">)</span>
|
||
<span class="n">ct</span><span class="o">.</span><span class="n">run</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>There’s actually 3 general ways in which this loop could work - dispatching a
|
||
thread to handle <code class="docutils literal notranslate"><span class="pre">clientsocket</span></code>, create a new process to handle
|
||
<code class="docutils literal notranslate"><span class="pre">clientsocket</span></code>, or restructure this app to use non-blocking sockets, and
|
||
multiplex between our “server” socket and any active <code class="docutils literal notranslate"><span class="pre">clientsocket</span></code>s using
|
||
<code class="docutils literal notranslate"><span class="pre">select</span></code>. More about that later. The important thing to understand now is
|
||
this: this is <em>all</em> a “server” socket does. It doesn’t send any data. It doesn’t
|
||
receive any data. It just produces “client” sockets. Each <code class="docutils literal notranslate"><span class="pre">clientsocket</span></code> is
|
||
created in response to some <em>other</em> “client” socket doing a <code class="docutils literal notranslate"><span class="pre">connect()</span></code> to the
|
||
host and port we’re bound to. As soon as we’ve created that <code class="docutils literal notranslate"><span class="pre">clientsocket</span></code>, we
|
||
go back to listening for more connections. The two “clients” are free to chat it
|
||
up - they are using some dynamically allocated port which will be recycled when
|
||
the conversation ends.</p>
|
||
<div class="section" id="ipc">
|
||
<h3>IPC<a class="headerlink" href="#ipc" title="Permalink to this headline">¶</a></h3>
|
||
<p>If you need fast IPC between two processes on one machine, you should look into
|
||
pipes or shared memory. If you do decide to use AF_INET sockets, bind the
|
||
“server” socket to <code class="docutils literal notranslate"><span class="pre">'localhost'</span></code>. On most platforms, this will take a
|
||
shortcut around a couple of layers of network code and be quite a bit faster.</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<p>The <a class="reference internal" href="../library/multiprocessing.html#module-multiprocessing" title="multiprocessing: Process-based parallelism."><code class="xref py py-mod docutils literal notranslate"><span class="pre">multiprocessing</span></code></a> integrates cross-platform IPC into a higher-level
|
||
API.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="using-a-socket">
|
||
<h2>Using a Socket<a class="headerlink" href="#using-a-socket" title="Permalink to this headline">¶</a></h2>
|
||
<p>The first thing to note, is that the web browser’s “client” socket and the web
|
||
server’s “client” socket are identical beasts. That is, this is a “peer to peer”
|
||
conversation. Or to put it another way, <em>as the designer, you will have to
|
||
decide what the rules of etiquette are for a conversation</em>. Normally, the
|
||
<code class="docutils literal notranslate"><span class="pre">connect</span></code>ing socket starts the conversation, by sending in a request, or
|
||
perhaps a signon. But that’s a design decision - it’s not a rule of sockets.</p>
|
||
<p>Now there are two sets of verbs to use for communication. You can use <code class="docutils literal notranslate"><span class="pre">send</span></code>
|
||
and <code class="docutils literal notranslate"><span class="pre">recv</span></code>, or you can transform your client socket into a file-like beast and
|
||
use <code class="docutils literal notranslate"><span class="pre">read</span></code> and <code class="docutils literal notranslate"><span class="pre">write</span></code>. The latter is the way Java presents its sockets.
|
||
I’m not going to talk about it here, except to warn you that you need to use
|
||
<code class="docutils literal notranslate"><span class="pre">flush</span></code> on sockets. These are buffered “files”, and a common mistake is to
|
||
<code class="docutils literal notranslate"><span class="pre">write</span></code> something, and then <code class="docutils literal notranslate"><span class="pre">read</span></code> for a reply. Without a <code class="docutils literal notranslate"><span class="pre">flush</span></code> in
|
||
there, you may wait forever for the reply, because the request may still be in
|
||
your output buffer.</p>
|
||
<p>Now we come to the major stumbling block of sockets - <code class="docutils literal notranslate"><span class="pre">send</span></code> and <code class="docutils literal notranslate"><span class="pre">recv</span></code> operate
|
||
on the network buffers. They do not necessarily handle all the bytes you hand
|
||
them (or expect from them), because their major focus is handling the network
|
||
buffers. In general, they return when the associated network buffers have been
|
||
filled (<code class="docutils literal notranslate"><span class="pre">send</span></code>) or emptied (<code class="docutils literal notranslate"><span class="pre">recv</span></code>). They then tell you how many bytes they
|
||
handled. It is <em>your</em> responsibility to call them again until your message has
|
||
been completely dealt with.</p>
|
||
<p>When a <code class="docutils literal notranslate"><span class="pre">recv</span></code> returns 0 bytes, it means the other side has closed (or is in
|
||
the process of closing) the connection. You will not receive any more data on
|
||
this connection. Ever. You may be able to send data successfully; I’ll talk
|
||
more about this later.</p>
|
||
<p>A protocol like HTTP uses a socket for only one transfer. The client sends a
|
||
request, then reads a reply. That’s it. The socket is discarded. This means that
|
||
a client can detect the end of the reply by receiving 0 bytes.</p>
|
||
<p>But if you plan to reuse your socket for further transfers, you need to realize
|
||
that <em>there is no</em> <abbr title="End of Transfer">EOT</abbr> <em>on a socket.</em> I repeat: if a socket
|
||
<code class="docutils literal notranslate"><span class="pre">send</span></code> or <code class="docutils literal notranslate"><span class="pre">recv</span></code> returns after handling 0 bytes, the connection has been
|
||
broken. If the connection has <em>not</em> been broken, you may wait on a <code class="docutils literal notranslate"><span class="pre">recv</span></code>
|
||
forever, because the socket will <em>not</em> tell you that there’s nothing more to
|
||
read (for now). Now if you think about that a bit, you’ll come to realize a
|
||
fundamental truth of sockets: <em>messages must either be fixed length</em> (yuck), <em>or
|
||
be delimited</em> (shrug), <em>or indicate how long they are</em> (much better), <em>or end by
|
||
shutting down the connection</em>. The choice is entirely yours, (but some ways are
|
||
righter than others).</p>
|
||
<p>Assuming you don’t want to end the connection, the simplest solution is a fixed
|
||
length message:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">MySocket</span><span class="p">:</span>
|
||
<span class="sd">"""demonstration class only</span>
|
||
<span class="sd"> - coded for clarity, not efficiency</span>
|
||
<span class="sd"> """</span>
|
||
|
||
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">sock</span><span class="o">=</span><span class="kc">None</span><span class="p">):</span>
|
||
<span class="k">if</span> <span class="n">sock</span> <span class="ow">is</span> <span class="kc">None</span><span class="p">:</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">sock</span> <span class="o">=</span> <span class="n">socket</span><span class="o">.</span><span class="n">socket</span><span class="p">(</span>
|
||
<span class="n">socket</span><span class="o">.</span><span class="n">AF_INET</span><span class="p">,</span> <span class="n">socket</span><span class="o">.</span><span class="n">SOCK_STREAM</span><span class="p">)</span>
|
||
<span class="k">else</span><span class="p">:</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">sock</span> <span class="o">=</span> <span class="n">sock</span>
|
||
|
||
<span class="k">def</span> <span class="nf">connect</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">host</span><span class="p">,</span> <span class="n">port</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">sock</span><span class="o">.</span><span class="n">connect</span><span class="p">((</span><span class="n">host</span><span class="p">,</span> <span class="n">port</span><span class="p">))</span>
|
||
|
||
<span class="k">def</span> <span class="nf">mysend</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">msg</span><span class="p">):</span>
|
||
<span class="n">totalsent</span> <span class="o">=</span> <span class="mi">0</span>
|
||
<span class="k">while</span> <span class="n">totalsent</span> <span class="o"><</span> <span class="n">MSGLEN</span><span class="p">:</span>
|
||
<span class="n">sent</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">sock</span><span class="o">.</span><span class="n">send</span><span class="p">(</span><span class="n">msg</span><span class="p">[</span><span class="n">totalsent</span><span class="p">:])</span>
|
||
<span class="k">if</span> <span class="n">sent</span> <span class="o">==</span> <span class="mi">0</span><span class="p">:</span>
|
||
<span class="k">raise</span> <span class="ne">RuntimeError</span><span class="p">(</span><span class="s2">"socket connection broken"</span><span class="p">)</span>
|
||
<span class="n">totalsent</span> <span class="o">=</span> <span class="n">totalsent</span> <span class="o">+</span> <span class="n">sent</span>
|
||
|
||
<span class="k">def</span> <span class="nf">myreceive</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="n">chunks</span> <span class="o">=</span> <span class="p">[]</span>
|
||
<span class="n">bytes_recd</span> <span class="o">=</span> <span class="mi">0</span>
|
||
<span class="k">while</span> <span class="n">bytes_recd</span> <span class="o"><</span> <span class="n">MSGLEN</span><span class="p">:</span>
|
||
<span class="n">chunk</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">sock</span><span class="o">.</span><span class="n">recv</span><span class="p">(</span><span class="nb">min</span><span class="p">(</span><span class="n">MSGLEN</span> <span class="o">-</span> <span class="n">bytes_recd</span><span class="p">,</span> <span class="mi">2048</span><span class="p">))</span>
|
||
<span class="k">if</span> <span class="n">chunk</span> <span class="o">==</span> <span class="sa">b</span><span class="s1">''</span><span class="p">:</span>
|
||
<span class="k">raise</span> <span class="ne">RuntimeError</span><span class="p">(</span><span class="s2">"socket connection broken"</span><span class="p">)</span>
|
||
<span class="n">chunks</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">chunk</span><span class="p">)</span>
|
||
<span class="n">bytes_recd</span> <span class="o">=</span> <span class="n">bytes_recd</span> <span class="o">+</span> <span class="nb">len</span><span class="p">(</span><span class="n">chunk</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="sa">b</span><span class="s1">''</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">chunks</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The sending code here is usable for almost any messaging scheme - in Python you
|
||
send strings, and you can use <code class="docutils literal notranslate"><span class="pre">len()</span></code> to determine its length (even if it has
|
||
embedded <code class="docutils literal notranslate"><span class="pre">\0</span></code> characters). It’s mostly the receiving code that gets more
|
||
complex. (And in C, it’s not much worse, except you can’t use <code class="docutils literal notranslate"><span class="pre">strlen</span></code> if the
|
||
message has embedded <code class="docutils literal notranslate"><span class="pre">\0</span></code>s.)</p>
|
||
<p>The easiest enhancement is to make the first character of the message an
|
||
indicator of message type, and have the type determine the length. Now you have
|
||
two <code class="docutils literal notranslate"><span class="pre">recv</span></code>s - the first to get (at least) that first character so you can
|
||
look up the length, and the second in a loop to get the rest. If you decide to
|
||
go the delimited route, you’ll be receiving in some arbitrary chunk size, (4096
|
||
or 8192 is frequently a good match for network buffer sizes), and scanning what
|
||
you’ve received for a delimiter.</p>
|
||
<p>One complication to be aware of: if your conversational protocol allows multiple
|
||
messages to be sent back to back (without some kind of reply), and you pass
|
||
<code class="docutils literal notranslate"><span class="pre">recv</span></code> an arbitrary chunk size, you may end up reading the start of a
|
||
following message. You’ll need to put that aside and hold onto it, until it’s
|
||
needed.</p>
|
||
<p>Prefixing the message with its length (say, as 5 numeric characters) gets more
|
||
complex, because (believe it or not), you may not get all 5 characters in one
|
||
<code class="docutils literal notranslate"><span class="pre">recv</span></code>. In playing around, you’ll get away with it; but in high network loads,
|
||
your code will very quickly break unless you use two <code class="docutils literal notranslate"><span class="pre">recv</span></code> loops - the first
|
||
to determine the length, the second to get the data part of the message. Nasty.
|
||
This is also when you’ll discover that <code class="docutils literal notranslate"><span class="pre">send</span></code> does not always manage to get
|
||
rid of everything in one pass. And despite having read this, you will eventually
|
||
get bit by it!</p>
|
||
<p>In the interests of space, building your character, (and preserving my
|
||
competitive position), these enhancements are left as an exercise for the
|
||
reader. Lets move on to cleaning up.</p>
|
||
<div class="section" id="binary-data">
|
||
<h3>Binary Data<a class="headerlink" href="#binary-data" title="Permalink to this headline">¶</a></h3>
|
||
<p>It is perfectly possible to send binary data over a socket. The major problem is
|
||
that not all machines use the same formats for binary data. For example, a
|
||
Motorola chip will represent a 16 bit integer with the value 1 as the two hex
|
||
bytes 00 01. Intel and DEC, however, are byte-reversed - that same 1 is 01 00.
|
||
Socket libraries have calls for converting 16 and 32 bit integers - <code class="docutils literal notranslate"><span class="pre">ntohl,</span>
|
||
<span class="pre">htonl,</span> <span class="pre">ntohs,</span> <span class="pre">htons</span></code> where “n” means <em>network</em> and “h” means <em>host</em>, “s” means
|
||
<em>short</em> and “l” means <em>long</em>. Where network order is host order, these do
|
||
nothing, but where the machine is byte-reversed, these swap the bytes around
|
||
appropriately.</p>
|
||
<p>In these days of 32 bit machines, the ascii representation of binary data is
|
||
frequently smaller than the binary representation. That’s because a surprising
|
||
amount of the time, all those longs have the value 0, or maybe 1. The string “0”
|
||
would be two bytes, while binary is four. Of course, this doesn’t fit well with
|
||
fixed-length messages. Decisions, decisions.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="disconnecting">
|
||
<h2>Disconnecting<a class="headerlink" href="#disconnecting" title="Permalink to this headline">¶</a></h2>
|
||
<p>Strictly speaking, you’re supposed to use <code class="docutils literal notranslate"><span class="pre">shutdown</span></code> on a socket before you
|
||
<code class="docutils literal notranslate"><span class="pre">close</span></code> it. The <code class="docutils literal notranslate"><span class="pre">shutdown</span></code> is an advisory to the socket at the other end.
|
||
Depending on the argument you pass it, it can mean “I’m not going to send
|
||
anymore, but I’ll still listen”, or “I’m not listening, good riddance!”. Most
|
||
socket libraries, however, are so used to programmers neglecting to use this
|
||
piece of etiquette that normally a <code class="docutils literal notranslate"><span class="pre">close</span></code> is the same as <code class="docutils literal notranslate"><span class="pre">shutdown();</span>
|
||
<span class="pre">close()</span></code>. So in most situations, an explicit <code class="docutils literal notranslate"><span class="pre">shutdown</span></code> is not needed.</p>
|
||
<p>One way to use <code class="docutils literal notranslate"><span class="pre">shutdown</span></code> effectively is in an HTTP-like exchange. The client
|
||
sends a request and then does a <code class="docutils literal notranslate"><span class="pre">shutdown(1)</span></code>. This tells the server “This
|
||
client is done sending, but can still receive.” The server can detect “EOF” by
|
||
a receive of 0 bytes. It can assume it has the complete request. The server
|
||
sends a reply. If the <code class="docutils literal notranslate"><span class="pre">send</span></code> completes successfully then, indeed, the client
|
||
was still receiving.</p>
|
||
<p>Python takes the automatic shutdown a step further, and says that when a socket
|
||
is garbage collected, it will automatically do a <code class="docutils literal notranslate"><span class="pre">close</span></code> if it’s needed. But
|
||
relying on this is a very bad habit. If your socket just disappears without
|
||
doing a <code class="docutils literal notranslate"><span class="pre">close</span></code>, the socket at the other end may hang indefinitely, thinking
|
||
you’re just being slow. <em>Please</em> <code class="docutils literal notranslate"><span class="pre">close</span></code> your sockets when you’re done.</p>
|
||
<div class="section" id="when-sockets-die">
|
||
<h3>When Sockets Die<a class="headerlink" href="#when-sockets-die" title="Permalink to this headline">¶</a></h3>
|
||
<p>Probably the worst thing about using blocking sockets is what happens when the
|
||
other side comes down hard (without doing a <code class="docutils literal notranslate"><span class="pre">close</span></code>). Your socket is likely to
|
||
hang. TCP is a reliable protocol, and it will wait a long, long time
|
||
before giving up on a connection. If you’re using threads, the entire thread is
|
||
essentially dead. There’s not much you can do about it. As long as you aren’t
|
||
doing something dumb, like holding a lock while doing a blocking read, the
|
||
thread isn’t really consuming much in the way of resources. Do <em>not</em> try to kill
|
||
the thread - part of the reason that threads are more efficient than processes
|
||
is that they avoid the overhead associated with the automatic recycling of
|
||
resources. In other words, if you do manage to kill the thread, your whole
|
||
process is likely to be screwed up.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="non-blocking-sockets">
|
||
<h2>Non-blocking Sockets<a class="headerlink" href="#non-blocking-sockets" title="Permalink to this headline">¶</a></h2>
|
||
<p>If you’ve understood the preceding, you already know most of what you need to
|
||
know about the mechanics of using sockets. You’ll still use the same calls, in
|
||
much the same ways. It’s just that, if you do it right, your app will be almost
|
||
inside-out.</p>
|
||
<p>In Python, you use <code class="docutils literal notranslate"><span class="pre">socket.setblocking(0)</span></code> to make it non-blocking. In C, it’s
|
||
more complex, (for one thing, you’ll need to choose between the BSD flavor
|
||
<code class="docutils literal notranslate"><span class="pre">O_NONBLOCK</span></code> and the almost indistinguishable Posix flavor <code class="docutils literal notranslate"><span class="pre">O_NDELAY</span></code>, which
|
||
is completely different from <code class="docutils literal notranslate"><span class="pre">TCP_NODELAY</span></code>), but it’s the exact same idea. You
|
||
do this after creating the socket, but before using it. (Actually, if you’re
|
||
nuts, you can switch back and forth.)</p>
|
||
<p>The major mechanical difference is that <code class="docutils literal notranslate"><span class="pre">send</span></code>, <code class="docutils literal notranslate"><span class="pre">recv</span></code>, <code class="docutils literal notranslate"><span class="pre">connect</span></code> and
|
||
<code class="docutils literal notranslate"><span class="pre">accept</span></code> can return without having done anything. You have (of course) a
|
||
number of choices. You can check return code and error codes and generally drive
|
||
yourself crazy. If you don’t believe me, try it sometime. Your app will grow
|
||
large, buggy and suck CPU. So let’s skip the brain-dead solutions and do it
|
||
right.</p>
|
||
<p>Use <code class="docutils literal notranslate"><span class="pre">select</span></code>.</p>
|
||
<p>In C, coding <code class="docutils literal notranslate"><span class="pre">select</span></code> is fairly complex. In Python, it’s a piece of cake, but
|
||
it’s close enough to the C version that if you understand <code class="docutils literal notranslate"><span class="pre">select</span></code> in Python,
|
||
you’ll have little trouble with it in C:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">ready_to_read</span><span class="p">,</span> <span class="n">ready_to_write</span><span class="p">,</span> <span class="n">in_error</span> <span class="o">=</span> \
|
||
<span class="n">select</span><span class="o">.</span><span class="n">select</span><span class="p">(</span>
|
||
<span class="n">potential_readers</span><span class="p">,</span>
|
||
<span class="n">potential_writers</span><span class="p">,</span>
|
||
<span class="n">potential_errs</span><span class="p">,</span>
|
||
<span class="n">timeout</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>You pass <code class="docutils literal notranslate"><span class="pre">select</span></code> three lists: the first contains all sockets that you might
|
||
want to try reading; the second all the sockets you might want to try writing
|
||
to, and the last (normally left empty) those that you want to check for errors.
|
||
You should note that a socket can go into more than one list. The <code class="docutils literal notranslate"><span class="pre">select</span></code>
|
||
call is blocking, but you can give it a timeout. This is generally a sensible
|
||
thing to do - give it a nice long timeout (say a minute) unless you have good
|
||
reason to do otherwise.</p>
|
||
<p>In return, you will get three lists. They contain the sockets that are actually
|
||
readable, writable and in error. Each of these lists is a subset (possibly
|
||
empty) of the corresponding list you passed in.</p>
|
||
<p>If a socket is in the output readable list, you can be
|
||
as-close-to-certain-as-we-ever-get-in-this-business that a <code class="docutils literal notranslate"><span class="pre">recv</span></code> on that
|
||
socket will return <em>something</em>. Same idea for the writable list. You’ll be able
|
||
to send <em>something</em>. Maybe not all you want to, but <em>something</em> is better than
|
||
nothing. (Actually, any reasonably healthy socket will return as writable - it
|
||
just means outbound network buffer space is available.)</p>
|
||
<p>If you have a “server” socket, put it in the potential_readers list. If it comes
|
||
out in the readable list, your <code class="docutils literal notranslate"><span class="pre">accept</span></code> will (almost certainly) work. If you
|
||
have created a new socket to <code class="docutils literal notranslate"><span class="pre">connect</span></code> to someone else, put it in the
|
||
potential_writers list. If it shows up in the writable list, you have a decent
|
||
chance that it has connected.</p>
|
||
<p>Actually, <code class="docutils literal notranslate"><span class="pre">select</span></code> can be handy even with blocking sockets. It’s one way of
|
||
determining whether you will block - the socket returns as readable when there’s
|
||
something in the buffers. However, this still doesn’t help with the problem of
|
||
determining whether the other end is done, or just busy with something else.</p>
|
||
<p><strong>Portability alert</strong>: On Unix, <code class="docutils literal notranslate"><span class="pre">select</span></code> works both with the sockets and
|
||
files. Don’t try this on Windows. On Windows, <code class="docutils literal notranslate"><span class="pre">select</span></code> works with sockets
|
||
only. Also note that in C, many of the more advanced socket options are done
|
||
differently on Windows. In fact, on Windows I usually use threads (which work
|
||
very, very well) with my sockets.</p>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
|
||
<div class="sphinxsidebarwrapper">
|
||
<h3><a href="../contents.html">Table of Contents</a></h3>
|
||
<ul>
|
||
<li><a class="reference internal" href="#">Socket Programming HOWTO</a><ul>
|
||
<li><a class="reference internal" href="#sockets">Sockets</a><ul>
|
||
<li><a class="reference internal" href="#history">History</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#creating-a-socket">Creating a Socket</a><ul>
|
||
<li><a class="reference internal" href="#ipc">IPC</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#using-a-socket">Using a Socket</a><ul>
|
||
<li><a class="reference internal" href="#binary-data">Binary Data</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#disconnecting">Disconnecting</a><ul>
|
||
<li><a class="reference internal" href="#when-sockets-die">When Sockets Die</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#non-blocking-sockets">Non-blocking Sockets</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="regex.html"
|
||
title="previous chapter">Regular Expression HOWTO</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="sorting.html"
|
||
title="next chapter">Sorting HOW TO</a></p>
|
||
<div role="note" aria-label="source link">
|
||
<h3>This Page</h3>
|
||
<ul class="this-page-menu">
|
||
<li><a href="../bugs.html">Report a Bug</a></li>
|
||
<li>
|
||
<a href="https://github.com/python/cpython/blob/3.7/Doc/howto/sockets.rst"
|
||
rel="nofollow">Show Source
|
||
</a>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="../genindex.html" title="General Index"
|
||
>index</a></li>
|
||
<li class="right" >
|
||
<a href="../py-modindex.html" title="Python Module Index"
|
||
>modules</a> |</li>
|
||
<li class="right" >
|
||
<a href="sorting.html" title="Sorting HOW TO"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="regex.html" title="Regular Expression HOWTO"
|
||
>previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" >Python HOWTOs</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
<div class="footer">
|
||
© <a href="../copyright.html">Copyright</a> 2001-2019, Python Software Foundation.
|
||
<br />
|
||
The Python Software Foundation is a non-profit corporation.
|
||
<a href="https://www.python.org/psf/donations/">Please donate.</a>
|
||
<br />
|
||
Last updated on Jul 13, 2019.
|
||
<a href="../bugs.html">Found a bug</a>?
|
||
<br />
|
||
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 2.0.1.
|
||
</div>
|
||
|
||
</body>
|
||
</html> |