# Copyright (C) 2001-2020, Python Software Foundation

# This file is distributed under the same license as the Python package.

# Maintained by the python-doc-es workteam.

# docs-es@python.org /

# https://mail.python.org/mailman3/lists/docs-es.python.org/

# Check https://github.com/python/python-docs-es/blob/3.8/TRANSLATORS to get

# the list of volunteers

#

msgid ""

msgstr ""

"Project-Id-Version: Python 3.8\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2022-10-25 19:47+0200\n"

"PO-Revision-Date: 2021-08-04 20:37+0200\n"

"Last-Translator: Cristián Maureira-Fredes <cmaureirafredes@gmail.com>\n"

"Language: es\n"

"Language-Team: python-doc-es\n"

"Plural-Forms: nplurals=2; plural=(n != 1);\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=utf-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Generated-By: Babel 2.10.3\n"

#: ../Doc/howto/sockets.rst:5

msgid "Socket Programming HOWTO"

msgstr "HOW TO - Programación con sockets"

#: ../Doc/howto/sockets.rst

msgid "Author"

msgstr "Autor"

#: ../Doc/howto/sockets.rst:7

msgid "Gordon McMillan"

msgstr "Gordon McMillan"

msgid "Abstract"

msgstr "Resumen"

#: ../Doc/howto/sockets.rst:12

msgid ""

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

msgstr ""

"Los sockets son usados casi en todas partes pero son una de las tecnologías "

"más incomprendidas. Esta es una descripción general de los sockets. No es "

"realmente un tutorial, todavía tendrás trabajo para hacer que las cosas "

"funcionen. No cubre los pequeños detalles (y hay muchos de ellos) pero "

"espero que pueda dar suficiente información para comenzar a usarlos "

"decentemente."

#: ../Doc/howto/sockets.rst:20

msgid "Sockets"

msgstr "Sockets"

#: ../Doc/howto/sockets.rst:22

#, python-format

msgid ""

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

msgstr ""

"Solo voy a hablar de los sockets *INET* (como IPv4), pues solo ellos cubren "

"el 99% del uso de los sockets. Y solo voy a hablar sobre los sockets "

"*STREAM* (como TCP), a menos que realmente sepas lo que haces (y en ese caso "

"esta guía no es para ti), tendrás mejor comportamiento y rendimiento con un "

"socket *STREAM* que con cualquier otro. Voy a tratar de aclarar el misterio "

"de que es un socket, además de algunas ideas sobre como trabajar con sockets "

"bloqueantes y no bloqueantes. Pero voy a comenzar hablando de los sockets "

"bloqueantes, necesitarás saber como funcionan antes de lidiar con los no "

"bloqueantes."

#: ../Doc/howto/sockets.rst:31

msgid ""

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

msgstr ""

"Parte del problema para entenderlos es que \"socket\" puede significar un "

"número de cosas ligeramente diferentes dependiendo del contexto. Entonces, "

"primero vamos a hacer una distinción entre sockets \"cliente\" - un extremo "

"de una conversación, y un socket \"servidor\", que es más como una central "

"de teléfonos. La aplicación cliente (tu navegador, por ejemplo) usa sockets "

"\"cliente\" exclusivamente; el servidor web con quien se está comunicando "

"usa sockets \"cliente\" y \"servidor\"."

#: ../Doc/howto/sockets.rst:40

msgid "History"

msgstr "Historia"

# Como debería traducir la :abbr:?

#: ../Doc/howto/sockets.rst:42

msgid ""

"Of the various forms of :abbr:`IPC (Inter Process Communication)`, 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."

msgstr ""

"De las varias formas de comunicación entre procesos (:abbr:`IPC (Inter "

"Process Communication)`) los sockets son, por mucho, la más popular. En "

"cualquier plataforma es probable que existan otras formas de IPC más "

"rápidas, pero en comunicación multiplataforma los sockets son los únicos "

"competidores."

#: ../Doc/howto/sockets.rst:47

msgid ""

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

msgstr ""

"Fueron inventados en Berkeley como parte del sabor BSD de Unix. Se "

"propagaron como la pólvora con Internet. Con razón: la combinación de "

"sockets con INET hace que hablar con máquinas arbitrarias de todo el mundo "

"sea increíblemente fácil (al menos en comparación con otros esquemas)."

#: ../Doc/howto/sockets.rst:54

msgid "Creating a Socket"

msgstr "Creando un socket"

#: ../Doc/howto/sockets.rst:56

msgid ""

"Roughly speaking, when you clicked on the link that brought you to this "

"page, your browser did something like the following::"

msgstr ""

"De manera general, cuando hiciste click en el enlace que te trajo a esta "

"página tu navegador hizo algo como lo siguiente:"

#: ../Doc/howto/sockets.rst:64

msgid ""

"When the ``connect`` completes, the socket ``s`` 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)."

msgstr ""

"Cuando ``connect`` termina, el socket ``s`` puede ser usado en una petición "

"para traer el texto de la página. El mismo socket leerá la respuesta y luego "

"será destruido. Así es, destruido. Los sockets cliente son normalmente "

"usados solo para un intercambio (o un pequeño numero se intercambios "

"secuenciales)."

#: ../Doc/howto/sockets.rst:70

msgid ""

"What happens in the web server is a bit more complex. First, the web server "

"creates a \"server socket\"::"

msgstr ""

"Lo que sucede en el servidor web es un poco más complejo. Primero, el "

"servidor web crea un \"socket servidor\":"

#: ../Doc/howto/sockets.rst:80

msgid ""

"A couple things to notice: we used ``socket.gethostname()`` so that the "

"socket would be visible to the outside world. If we had used ``s."

"bind(('localhost', 80))`` or ``s.bind(('127.0.0.1', 80))`` we would still "

"have a \"server\" socket, but one that was only visible within the same "

"machine. ``s.bind(('', 80))`` specifies that the socket is reachable by any "

"address the machine happens to have."

msgstr ""

"Un par de cosas que señalar: usamos ``socket.gethostname()`` para que el "

"socket fuera visible al mundo exterior. Si hubiésemos usado ``s."

"bind(('localhost', 80))`` o ``s.bind(('127.0.0.1', 80))`` habríamos tenido "

"un socket servidor pero solo habría sido visible en la misma máquina. ``s."

"bind(('', 80))`` especifica que el socket es accesible desde cualquier "

"dirección que tenga la máquina."

#: ../Doc/howto/sockets.rst:87

msgid ""

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

msgstr ""

"Algo más para señalar: los números de puerto bajos son normalmente "

"reservados para servicios \"conocidos\" (HTTP, SNMP, etc.). Si estás "

"probando los sockets usa un número grande (4 dígitos)."

#: ../Doc/howto/sockets.rst:91

msgid ""

"Finally, the argument to ``listen`` 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."

msgstr ""

"Finalmente, el argumento que se le pasa a ``listen`` le indica a la librería "

"del socket que queremos poner en cola no más de 5 solicitudes de conexión "

"(el máximo normal) antes de rechazar conexiones externas. Si el resto del "

"código está escrito correctamente eso debería ser suficiente."

#: ../Doc/howto/sockets.rst:95

msgid ""

"Now that we have a \"server\" socket, listening on port 80, we can enter the "

"mainloop of the web server::"

msgstr ""

"Ahora que tenemos un socket servidor escuchando en el puerto 80 ya podemos "

"entrar al bucle principal del servidor web:"

#: ../Doc/howto/sockets.rst:106

msgid ""

"There's actually 3 general ways in which this loop could work - dispatching "

"a thread to handle ``clientsocket``, create a new process to handle "

"``clientsocket``, or restructure this app to use non-blocking sockets, and "

"multiplex between our \"server\" socket and any active ``clientsocket``\\ s "

"using ``select``. More about that later. The important thing to understand "

"now is this: this is *all* a \"server\" socket does. It doesn't send any "

"data. It doesn't receive any data. It just produces \"client\" sockets. Each "

"``clientsocket`` is created in response to some *other* \"client\" socket "

"doing a ``connect()`` to the host and port we're bound to. As soon as we've "

"created that ``clientsocket``, 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."

msgstr ""

"Existen en realidad 3 maneras generales en las cuales este bucle puede "

"funcionar - despachar un hilo para manejar ``clientsocket``, crear un "

"proceso nuevo para manejar ``clientsocket`` o reestructurar esta aplicación "

"para usar sockets no bloqueantes y multiplexar entre nuestro \"socket "

"servidor\" y cualquier ``clientsocket`` activo usando ``select``. Más sobre "

"esto después. Lo importante a entender ahora es: esto es *todo* lo que un "

"\"socket servidor hace\". No manda ningún dato. No recibe ningún dato. Solo "

"produce \"sockets clientes\". Cada ``clientsocket`` es creado en respuesta a "

"algún otro \"socket cliente\" que hace ``connect()`` al host y al puerto al "

"que estamos vinculados. Tan pronto como hemos credo ese ``clientsocket`` "

"volvemos a escuchar por más conexiones. Los dos \"clientes\" son libres de "

"\"conversar\" entre ellos - están usando algún puerto asignado dinámicamente "

"que será reciclado cuando la conversación termine."

#: ../Doc/howto/sockets.rst:121

msgid "IPC"

msgstr "IPC"

#: ../Doc/howto/sockets.rst:123

msgid ""

"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 ``'localhost'``. On most platforms, this will take "

"a shortcut around a couple of layers of network code and be quite a bit "

"faster."

msgstr ""

"Si necesitas conexiones IPC rápidas entre dos procesos en una misma máquina "

"puedes revisar los *pipes* o la memoria compartida. Si decides usar sockets "

"``AF_INET``, vincula el servidor con ``\"localhost\"``. En la mayoría de las "

"plataformas, esto tomará un atajo alrededor de algunas capas del código de "

"red y será un poco más rápido."

#: ../Doc/howto/sockets.rst:129

msgid ""

"The :mod:`multiprocessing` integrates cross-platform IPC into a higher-level "

"API."

msgstr ""

"El módulo :mod:`multiprocessing` integra IPC multiplataforma en un API de "

"alto nivel."

#: ../Doc/howto/sockets.rst:134

msgid "Using a Socket"

msgstr "Usando un socket"

#: ../Doc/howto/sockets.rst:136

msgid ""

"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, *as the designer, "

"you will have to decide what the rules of etiquette are for a conversation*. "

"Normally, the ``connect``\\ 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."

msgstr ""

"Lo primero a señalar es que el \"socket cliente\" del navegador y el "

"\"socket cliente\" del servidor web son bestias idénticas. Es decir, esta es "

"una conversación *peer to peer*. O para decirlo de otra manera, *como "

"diseñador, tendrás que decidir cuáles son las reglas de etiqueta para una "

"conversación*. Normalmente, el socket que se conecta inicia la conversación, "

"enviando una solicitud o tal vez un inicio de sesión. Pero esa es una "

"decisión de diseño: no es una regla de los sockets."

#: ../Doc/howto/sockets.rst:143

msgid ""

"Now there are two sets of verbs to use for communication. You can use "

"``send`` and ``recv``, or you can transform your client socket into a file-"

"like beast and use ``read`` and ``write``. 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 ``flush`` on sockets. These are buffered \"files\", "

"and a common mistake is to ``write`` something, and then ``read`` for a "

"reply. Without a ``flush`` in there, you may wait forever for the reply, "

"because the request may still be in your output buffer."

msgstr ""

"Hay dos conjuntos de verbos que se usan para la comunicación. Puedes usar "

"``send`` y ``recv`` o puedes transformar tu socket cliente en algo similar a "

"un archivo y usar ``read`` y ``write``. Esta última es la forma en la que "

"Java presenta sus sockets. No voy a hablar acerca de eso aquí, excepto para "

"advertirte que necesitas usar ``flush`` en los sockets. Estos son archivos "

"en buffer, y un error común es usar ``write`` para escribir algo y luego "

"usar ``read`` para leer la respuesta. Sin usar ``flush`` en este caso, "

"puedes terminar esperando la respuesta por siempre porque la petición "

"estaría aún en el buffer de salida."

#: ../Doc/howto/sockets.rst:152

msgid ""

"Now we come to the major stumbling block of sockets - ``send`` and ``recv`` "

"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 (``send``) or emptied (``recv``). They then tell "

"you how many bytes they handled. It is *your* responsibility to call them "

"again until your message has been completely dealt with."

msgstr ""

"Ahora llegamos al principal problema de los sockets - ``send`` y ``recv`` "

"operan en los buffers de red. Ellos no manejan necesariamente todos los "

"bytes que se les entrega (o espera de ellos), porque su enfoque principal es "

"manejar los buffers de red. En general, ellos retornan cuando los buffers de "

"red asociados se han llenado (``send``) o vaciado (``recv``). Luego ellos "

"dicen cuántos bytes manejaron. Es *tu* responsabilidad llamarlos nuevamente "

"hasta que su mensaje haya sido tratado por completo."

#: ../Doc/howto/sockets.rst:160

msgid ""

"When a ``recv`` 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."

msgstr ""

"Cuando ``recv`` retorna 0 bytes significa que el otro lado ha cerrado (o "

"está en el proceso de cerrar) la conexión. No recibirás más datos de esta "

"conexión. Nunca. Es posible que puedas mandar datos exitosamente. De eso voy "

"a hablar más tarde."

#: ../Doc/howto/sockets.rst:165

msgid ""

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

msgstr ""

"Un protocolo como HTTP usa un socket para una sola transferencia. El cliente "

"manda una petición, luego lee la respuesta. Eso es todo. El socket es "

"descartado. Esto significa que un cliente puede detectar el final de la "

"respuesta al recibir 0 bytes."

# ‪Como debería traducir la :abbr:?

#: ../Doc/howto/sockets.rst:169

msgid ""

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

"realize that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I "

"repeat: if a socket ``send`` or ``recv`` returns after handling 0 bytes, the "

"connection has been broken. If the connection has *not* been broken, you "

"may wait on a ``recv`` forever, because the socket will *not* 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: *messages must either "

"be fixed length* (yuck), *or be delimited* (shrug), *or indicate how long "

"they are* (much better), *or end by shutting down the connection*. The "

"choice is entirely yours, (but some ways are righter than others)."

msgstr ""

"Pero si planeas reusar el socket para más transferencias, tienes que darte "

"cuenta que *no hay* :abbr:`EOT (End of Transfer)` *en un socket.* Repito: si "

"la llamada a ``send`` o ``recv`` de un socket retorna después de manejar 0 "

"bytes, la conexión se ha interrumpido. Si la conexión *no* se ha "

"interrumpido, puedes esperar un ``recv`` para siempre, porque el socket no "

"te dirá cuando no hay más nada por leer (por ahora). Ahora, si piensas sobre "

"eso un poco, te darás cuenta de una verdad fundamental de los sockets: *los "

"mensajes deben ser de longitud fija* (ouch), *o ser delimitados* (ouch), *o "

"indicar que tan largo son* (mucho mejor), *o terminar cerrando la conexión.* "

"La elección es completamente tuya (pero hay algunas vías más correctas que "

"otras)."

#: ../Doc/howto/sockets.rst:180

msgid ""

"Assuming you don't want to end the connection, the simplest solution is a "

"fixed length message::"

msgstr ""

"Asumiendo que no quieres terminar la conexión, la solución más simple es un "

"mensaje de longitud fija:"

#: ../Doc/howto/sockets.rst:217

msgid ""

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

"you send strings, and you can use ``len()`` to determine its length (even if "

"it has embedded ``\\0`` characters). It's mostly the receiving code that "

"gets more complex. (And in C, it's not much worse, except you can't use "

"``strlen`` if the message has embedded ``\\0``\\ s.)"

msgstr ""

"El código de envío aquí es usable para prácticamente cualquier esquema de "

"mensajería - en Python envías cadenas y usas ``len()`` para determinar su "

"longitud (incluso si tiene caracteres ``\\0`` incrustados). Es "

"principalmente el código receptor el que se vuelve más complejo. (Y en C no "

"es mucho peor, excepto que no puedes usar ``strlen`` si el mensaje tiene "

"``\\0`` incrustados)."

#: ../Doc/howto/sockets.rst:223

msgid ""

"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 ``recv``\\ 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."

msgstr ""

"La mejora más fácil es hacer que el primer caracter del mensaje un indicador "

"del tipo de mensaje y que el tipo determine la longitud. Ahora tienes dos "

"``recv`` - el primero para obtener (al menos) ese primer caracter para "

"conocer la longitud, y el segundo en un bucle para obtener el resto. Si "

"decides ir por el camino del delimitador, estarás recibiendo un fragmento de "

"tamaño arbitrario (4096 o 8192 son a menudo buenas elecciones para tamaños "

"de buffers de red) y escaneando lo que recibas en busca del delimitador."

#: ../Doc/howto/sockets.rst:231

msgid ""

"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 ``recv`` 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."

msgstr ""

"Hay una complicación de la que estar consiente: si el protocolo "

"conversacional permite mandar múltiples mensajes consecutivos (sin ningún "

"tipo de respuesta), y pasas a ``recv`` un tamaño de fragmento arbitrario "

"poder terminar leyendo el inicio de un próximo mensaje. Tendrás que dejarlo "

"aparte y guardarlo hasta que sea necesario."

# Como traducir "In playing around" en este contexto?

#: ../Doc/howto/sockets.rst:237

msgid ""

"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 ``recv``. In playing around, you'll get away with it; but in high "

"network loads, your code will very quickly break unless you use two ``recv`` "

"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 ``send`` does "

"not always manage to get rid of everything in one pass. And despite having "

"read this, you will eventually get bit by it!"

msgstr ""

"Prefijar el mensaje con su longitud (por ejemplo, 5 caracteres numéricos) se "

"vuelve más complicado porque (créalo o no), puede que no recibas los 5 "

"caracteres en una llamada a ``recv``. Para proyectos pequeños te saldrás con "

"la tuya; pero con altas cargas de red, tu código se romperá rápidamente a "

"menos que uses dos ``recv`` en bucle - el primero para determinar la "

"longitud, el segundo para obtener la parte del mensaje. Sucio. También será "

"cuando descubras que ``send`` no siempre logra enviar todo de una sola vez. "

"Y a pesar de haber leído esto eventualmente te va a morder!"

#: ../Doc/howto/sockets.rst:246

msgid ""

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

msgstr ""

"Con interés de espacio, la construcción de tu carácter (y preservar mi "

"posición competitiva), estas mejoras se dejan como un ejercicio para el "

"lector. Pasemos a la limpieza."

#: ../Doc/howto/sockets.rst:252

msgid "Binary Data"

msgstr "Datos binarios"

#: ../Doc/howto/sockets.rst:254

msgid ""

"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, `network byte order <https://en.wikipedia.org/wiki/"

"Endianness#Networking>`_ is big-endian, with the most significant byte "

"first, so a 16 bit integer with the value ``1`` would be the two hex bytes "

"``00 01``. However, most common processors (x86/AMD64, ARM, RISC-V), are "

"little-endian, with the least significant byte first - that same ``1`` would "

"be ``01 00``."

msgstr ""

#: ../Doc/howto/sockets.rst:262

#, fuzzy

msgid ""

"Socket libraries have calls for converting 16 and 32 bit integers - ``ntohl, "

"htonl, ntohs, htons`` where \"n\" means *network* and \"h\" means *host*, "

"\"s\" means *short* and \"l\" means *long*. Where network order is host "

"order, these do nothing, but where the machine is byte-reversed, these swap "

"the bytes around appropriately."

msgstr ""

"Es perfectamente posible mandar datos binarios en un socket. El mayor "

"problema es que no todas las máquinas usan el mismo formato para datos "

"binarios. Por ejemplo, un chip Motorola representa un entero de 16 bit con "

"el valor 1 como los dos bytes hexadecimales 00 01. Intel y DEC, sin embargo, "

"son de \"bytes invertidos\" - el mismo valor 1 es 01 00. Las bibliotecas de "

"sockets tienen funciones para convertir enteros de 16 y 32 bit - ``ntohl, "

"htonl, ntohs, htons`` donde la \"n\" significa \"network\" y \"h\" significa "

"\"host\", \"s\" significa \"short\" y \"l\" significa \"long\". Cuando el "

"orden de la red es el orden del servidor, estas funciones no hacen nada, "

"pero cuando la máquina es de \"bytes invertidos\", estas cambian los bytes "

"apropiadamente."

#: ../Doc/howto/sockets.rst:268

#, fuzzy

msgid ""

"In these days of 64-bit machines, the ASCII representation of binary data is "

"frequently smaller than the binary representation. That's because a "

"surprising amount of the time, most integers have the value 0, or maybe 1. "

"The string ``\"0\"`` would be two bytes, while a full 64-bit integer would "

"be 8. Of course, this doesn't fit well with fixed-length messages. "

"Decisions, decisions."

msgstr ""

"En estos días de máquinas de 32 bit, la representación ascii de los datos "

"binarios es con frecuencia más pequeña que la representación binaria. Esto "

"es porque una sorprendente cantidad de veces, todos esos \"longs\" tienen de "

"valor 0, o tal vez 1. La cadena \"0\" tendría dos bytes, mientras el binario "

"cuatro. Por supuesto, esto no funciona bien con los mensajes de longitud "

"fija. Decisiones, decisiones."

#: ../Doc/howto/sockets.rst:277

msgid "Disconnecting"

msgstr "Desconectando"

#: ../Doc/howto/sockets.rst:279

msgid ""

"Strictly speaking, you're supposed to use ``shutdown`` on a socket before "

"you ``close`` it. The ``shutdown`` 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 ``close`` is the "

"same as ``shutdown(); close()``. So in most situations, an explicit "

"``shutdown`` is not needed."

msgstr ""

"Estrictamente hablando, se supone que debes usar ``shutdown`` en un socket "

"antes de cerrarlo con ``close``. ``shutdown`` es un aviso para el socket en "

"el otro lado. Dependiendo del argumento que se le pase, puede significar "

"\"No voy a mandar más datos, pero voy a escuchar\" o \"No estoy escuchando, "

"adiós!\". La mayoría de bibliotecas para sockets, sin embargo, están tan "

"acostumbradas a que los programadores ignoren esta parte de la etiqueta que "

"normalmente ``close`` es lo mismo que ``shutdown(); close()``. Por tanto en "

"la mayoría de las situaciones usar ``shutdown`` de manera explícita no es "

"necesario."

#: ../Doc/howto/sockets.rst:287

msgid ""

"One way to use ``shutdown`` effectively is in an HTTP-like exchange. The "

"client sends a request and then does a ``shutdown(1)``. 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 ``send`` completes "

"successfully then, indeed, the client was still receiving."

msgstr ""

"Una forma de usar ``shutdown`` de manera efectiva es en un intercambio "

"similar a *HTTP*. El cliente manda una petición y entonces hace un "

"``shutdown(1)``. Esto le dice al servidor \"El cliente terminó de enviar, "

"pero todavía puede recibir\". El servidor puede detectar \"EOF\" (Fin del "

"Archivo) al recibir 0 bytes. Puede asumir que se completó la petición. El "

"servidor envía una respuesta. Si el ``send`` termina satisfactoriamente "

"entonces, en efecto, el cliente todavía estaba recibiendo."

#: ../Doc/howto/sockets.rst:294

msgid ""

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

"socket is garbage collected, it will automatically do a ``close`` if it's "

"needed. But relying on this is a very bad habit. If your socket just "

"disappears without doing a ``close``, the socket at the other end may hang "

"indefinitely, thinking you're just being slow. *Please* ``close`` your "

"sockets when you're done."

msgstr ""

"Python lleva el apagado automático un paso más allá, y dice que cuando un "

"socket es eliminado por el recolector de basura, automáticamente llama a "

"``close`` si es necesario. Pero confiar en esto es un mal hábito. Si tu "

"socket simplemente desaparece sin llamar a ``close``, el socket del otro "

"lado puede colgarse indefinidamente, pensando que solo estas siendo lento. "

"*Por favor* cierra los sockets cuando termines."

#: ../Doc/howto/sockets.rst:302

msgid "When Sockets Die"

msgstr "Cuando los sockets mueren"

#: ../Doc/howto/sockets.rst:304

msgid ""

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

"the other side comes down hard (without doing a ``close``). 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 "

"*not* 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."

msgstr ""

"Probablemente lo peor de usar sockets bloqueantes es lo que pasa cuando el "

"otro lado se apaga inesperadamente (sin llamar a ``close``). Tu socket es "

"probable que se cuelgue. TCP es un protocolo confiable, y va a esperar un "

"largo, largo tiempo antes de rendirse con una conexión. Si estás usando "

"hilos, todo el hilo está esencialmente muerto. No hay mucho que puedas hacer "

"respecto a eso. A menos que no estés haciendo algo tonto, como mantener un "

"bloqueo mientras se realiza una lectura bloqueante, el hilo realmente no "

"estará consumiendo muchos recursos. *No* trates de matar el hilo - parte de "

"la razón por la que los hilos son más eficientes que los procesos es que "

"evitan la complicación asociada con el reciclaje automático de recursos. En "

"otras palabras, si te las arreglas para matar el hilo, es muy probable que "

"todo el proceso termine arruinado."

#: ../Doc/howto/sockets.rst:318

msgid "Non-blocking Sockets"

msgstr "*Sockets* no bloqueantes"

# Como traduzco inside-out?

#: ../Doc/howto/sockets.rst:320

msgid ""

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

msgstr ""

"Si has entendido todo lo anterior, ya conoces la mayor parte de lo que "

"necesitas saber sobre las mecánicas del uso de los sockets. Usarás las "

"mismas llamadas, de la misma manera. Es solo eso, si lo haces correctamente, "

"tu aplicación estará casi correcta."

#: ../Doc/howto/sockets.rst:325

msgid ""

"In Python, you use ``socket.setblocking(False)`` to make it non-blocking. In "

"C, it's more complex, (for one thing, you'll need to choose between the BSD "

"flavor ``O_NONBLOCK`` and the almost indistinguishable POSIX flavor "

"``O_NDELAY``, which is completely different from ``TCP_NODELAY``), 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.)"

msgstr ""

"En Python, usa ``socket.setblocking(False)`` para que no sea bloqueante. En "

"C, es más complejo (por un lado, deberá elegir entre el sabor BSD "

"``O_NONBLOCK`` y el sabor POSIX casi indistinguible ``O_NDELAY``, que es "

"completamente diferente de ``TCP_NODELAY``) , pero es exactamente la misma "

"idea. Haz esto después de crear el socket, pero antes de usarlo. (En "

"realidad, si estás loco, puedes cambiar de un lado a otro)."

#: ../Doc/howto/sockets.rst:332

msgid ""

"The major mechanical difference is that ``send``, ``recv``, ``connect`` and "

"``accept`` 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."

msgstr ""

"La principal diferencia mecánica es que ``send``, ``recv``, ``connect`` y "

"``accept`` pueden retornar sin haber hecho nada. Tu tienes (por supuesto) un "

"número de elecciones. Puedes verificar el código de retorno y los códigos de "

"error y en general volverte loco. Si no me crees pruébalo alguna vez. Tu "

"aplicación crecerá grande, con errores y consumirá todo el CPU. Así que "

"vamos a saltarnos las soluciones descerebradas y hacerlo correctamente."

#: ../Doc/howto/sockets.rst:339

msgid "Use ``select``."

msgstr "Usando ``select``."

#: ../Doc/howto/sockets.rst:341

msgid ""

"In C, coding ``select`` is fairly complex. In Python, it's a piece of cake, "

"but it's close enough to the C version that if you understand ``select`` in "

"Python, you'll have little trouble with it in C::"

msgstr ""

"En C, usar ``select`` es algo complejo. En Python es pan comido, pero está "

"lo suficientemente cercano a la versión de C que si entiendes el ``select`` "

"en Python tendrás pocos problemas con él el C:"

#: ../Doc/howto/sockets.rst:352

msgid ""

"You pass ``select`` 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 ``select`` 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."

msgstr ""

"A ``select`` se le pasan tres listas: la primera contiene todos los sockets "

"que puedes intentar leer; la segunda con todos los sockets que puedes "

"intentar escribir, y la tercera (normalmente se deja vacía) todos los que "

"quieras verificar los errores. Debes tener en cuenta que un socket puede ir "

"en más de una lista. La llamada a ``select`` es bloqueante, pero puedes "

"darle un tiempo de espera. Esto generalmente es una cosa sensata de hacer - "

"dale un tiempo de espera largo (un minuto por ejemplo) a menos que tengas "

"una buena razón para no hacerlo."

#: ../Doc/howto/sockets.rst:360

msgid ""

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

msgstr ""

"En el retorno tendrás tres listas. Estas contienen los sockets que son "

"realmente legibles, escribibles y con error. Cada una de estas lista es un "

"subconjunto (posiblemente vacío) de la lista correspondiente que pasaste."

#: ../Doc/howto/sockets.rst:364

msgid ""

"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 ``recv`` on that socket will return "

"*something*. Same idea for the writable list. You'll be able to send "

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

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

"it just means outbound network buffer space is available.)"

msgstr ""

"Si un socket está en la lista retornada legible, puedes estar tan-seguro-"

"como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en este "

"socket va a retornar *algo*. La misma idea se aplica a la lista de "

"escribibles. Serás capaz de mandar *algo*. Tal vez no todo lo que quieras, "

"pero *algo* es mejor que nada. (Realmente, cualquier socket socket "

"razonablemente saludable va a retornar como escribible - eso solo significa "

"que el espacio de salida del buffer de red está disponible)"

#: ../Doc/howto/sockets.rst:371

msgid ""

"If you have a \"server\" socket, put it in the potential_readers list. If it "

"comes out in the readable list, your ``accept`` will (almost certainly) "

"work. If you have created a new socket to ``connect`` 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."

msgstr ""

"Si tienes un socket *servidor*, ponlo en la lista de *potenciales legibles*. "

"Se retorna en la lista de legibles, una llamada a ``accept`` va a funcionar "

"(casi seguro). Se has creado un nuevo socket para llamar a ``connect`` para "

"conectarte con otro, ponlo en la lista de *potenciales escribibles*. Si "

"retorna en la lista de escribibles, tienes una buena oportunidad de que esté "

"conectado."

#: ../Doc/howto/sockets.rst:377

msgid ""

"Actually, ``select`` 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."

msgstr ""

"Realmente, ``select`` puede ser útil incluso con sockets bloqueantes. Es una "

"manera de determinar si vas a bloquear - el socket retorna como leíble "

"cuando hay algo en el buffer. Sin embargo, esto aun no sirve de ayuda con el "

"problema de determinar si el otro extremo terminó, o solo está ocupado con "

"otra cosa."

#: ../Doc/howto/sockets.rst:382

msgid ""

"**Portability alert**: On Unix, ``select`` works both with the sockets and "

"files. Don't try this on Windows. On Windows, ``select`` 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."

msgstr ""

"**Alerta de portabilidad**: En Unix, ``select`` funciona tanto con sockets "

"como con archivos. No intentes esto en Windows. En Windows ``select`` "

"funciona solo con sockets. También ten en cuenta que en C, muchas de las "

"opciones más avanzadas de los sockets se hacen diferentes en Windows. De "

"hecho, en Windows normalmente uso hilos (que funciona muy, muy bien) con los "

"sockets."