From 142f6284c52e4cfa5b01af1a9f4798e5018fbdfe Mon Sep 17 00:00:00 2001 From: ktowen Date: Wed, 5 Aug 2020 19:51:28 -0400 Subject: [PATCH 1/3] Traducido howto/sockets.po --- howto/sockets.po | 731 +++++++++++++++++++++++++++++++---------------- 1 file changed, 484 insertions(+), 247 deletions(-) diff --git a/howto/sockets.po b/howto/sockets.po index 38a29aaab0..06bff96e88 100644 --- a/howto/sockets.po +++ b/howto/sockets.po @@ -1,230 +1,323 @@ # 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. +# 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/PyCampES/python-docs-es/blob/3.8/TRANSLATORS to get the list of volunteers # -#, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 3.8\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-05-06 11:59-0400\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" +"PO-Revision-Date: 2020-08-05 19:57-0400\n" "Language-Team: python-doc-es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" +"Last-Translator: \n" +"Language: es\n" +"X-Generator: Poedit 2.3.1\n" #: ../Doc/howto/sockets.rst:5 msgid "Socket Programming HOWTO" -msgstr "" +msgstr "*HOW TO* - Programación con sockets" #: ../Doc/howto/sockets.rst:0 msgid "Author" -msgstr "" +msgstr "Autor" #: ../Doc/howto/sockets.rst:7 msgid "Gordon McMillan" -msgstr "" +msgstr "Gordon McMillan" #: ../Doc/howto/sockets.rst:None msgid "Abstract" -msgstr "" +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." +"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 "" +msgstr "Sockets" #: ../Doc/howto/sockets.rst:22 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 "" +"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 "" +"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 mas 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 "" +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." +"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)." +"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 de la derivación de *Unix* BSD y se " +"expandió como la pólvora en internet. Con buena razón --- la combinación de los " +"sockets con INET hace que hablar con computadoras arbitrarias alrededor del " +"mundo sea increíblemente sencillo (al menos comparado con otros esquemas)." #: ../Doc/howto/sockets.rst:54 msgid "Creating a Socket" -msgstr "" +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::" +"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)." +"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 mas 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." +"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)." +"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." +"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 " +"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 "" +"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 app 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 mas 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 "" +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." +"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." +"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 "" +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 "" +"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 "" +"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 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 " +"búfer, 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 " +"búfer 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 "" +"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 ellso 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." +"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 "" @@ -232,67 +325,110 @@ msgid "" "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 "" +"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::" +"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 mas simple es un " +"mansaje 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.)" +"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 "" +"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." +"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 "" +"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 "" @@ -300,182 +436,283 @@ msgid "" "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 "" +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, 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 - ``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 "" +"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 - ``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:264 msgid "" "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." -msgstr "" +"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." +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:272 msgid "Disconnecting" -msgstr "" +msgstr "Desconectando" #: ../Doc/howto/sockets.rst:274 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 "" +"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, adios!\". 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." #: ../Doc/howto/sockets.rst:282 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 "" +"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:289 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." +"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:297 msgid "When Sockets Die" -msgstr "" +msgstr "Cuando los sockets mueren" #: ../Doc/howto/sockets.rst:299 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 "" +"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 " +"esta 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 mas " +"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:313 msgid "Non-blocking Sockets" -msgstr "" +msgstr "*Sockets* no bloqueantes" +# Como traduzco inside-out? #: ../Doc/howto/sockets.rst:315 +#, fuzzy 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." +"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 sabes 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:320 msgid "" -"In Python, you use ``socket.setblocking(0)`` 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.)" +"In Python, you use ``socket.setblocking(0)`` 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 se usa ``socket.setblocking(0)`` para hacer un socket no bloqueante. " +"En C es un poco más complejo (por una parte, tendrás que decidir entre la manera " +"BSD de usar ``O_NONBLOCK`` y la manera casi indistinguible de Posix de " +"``O_NDELAY``, que es completamente diferente de ``TCP_NODELAY``), pero es " +"exactamente la misma idea. Esto se hace después de crear el socket pero antes de " +"usarlo (Realmente, si estás loco, puedes cambiar de una manera a la otra)." #: ../Doc/howto/sockets.rst:327 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 "" +"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:334 msgid "Use ``select``." -msgstr "" +msgstr "Usando ``select``." #: ../Doc/howto/sockets.rst:336 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::" +"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:347 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 "" +"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:355 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." +"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 " +"leíbles, 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:359 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 " +"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 "" +"*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 esta en la lista retornada de los leíbles, puedes estar tan-seguro-" +"como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en este socket " +"va a devolver *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 búfer de red " +"está disponible)" #: ../Doc/howto/sockets.rst:366 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." +"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 leíbles*. Se " +"retorna en la lista de leíbles, una llamada a ``acept`` va a funcionar (casi " +"seguro). Se has creado un nuevo socket para llamar a ``conect`` para conectarte " +"con otro, ponlo en la lista de *potenciales escribibles*. Si retorna en la lista " +"de escribibles, tienes una buena oportunidad de que este conectado." #: ../Doc/howto/sockets.rst:372 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." +"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 búfer. 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:377 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 "" +"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." From 96f42430fb3c03833faf43fd79ef736e5df7f609 Mon Sep 17 00:00:00 2001 From: ktowen Date: Thu, 6 Aug 2020 09:05:14 -0400 Subject: [PATCH 2/3] Algunas correcciones --- dictionaries/howto_sockets.txt | 8 ++++++ howto/sockets.po | 51 +++++++++++++++++----------------- 2 files changed, 33 insertions(+), 26 deletions(-) create mode 100644 dictionaries/howto_sockets.txt diff --git a/dictionaries/howto_sockets.txt b/dictionaries/howto_sockets.txt new file mode 100644 index 0000000000..0020bdc05d --- /dev/null +++ b/dictionaries/howto_sockets.txt @@ -0,0 +1,8 @@ +Motorola +Posix +buffers +leíble +multiplexar +pruébalo +usable +caracter \ No newline at end of file diff --git a/howto/sockets.po b/howto/sockets.po index 06bff96e88..91cdad2f97 100644 --- a/howto/sockets.po +++ b/howto/sockets.po @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: Python 3.8\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-05-06 11:59-0400\n" -"PO-Revision-Date: 2020-08-05 19:57-0400\n" +"PO-Revision-Date: 2020-08-06 09:28-0400\n" "Language-Team: python-doc-es\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -21,7 +21,7 @@ msgstr "" #: ../Doc/howto/sockets.rst:5 msgid "Socket Programming HOWTO" -msgstr "*HOW TO* - Programación con sockets" +msgstr "HOW TO - Programación con sockets" #: ../Doc/howto/sockets.rst:0 msgid "Author" @@ -85,7 +85,7 @@ 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 mas como una central de " +"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\"." @@ -102,7 +102,7 @@ msgid "" "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 " +"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." @@ -148,7 +148,7 @@ 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 mas complejo. Primero, el servidor " +"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 @@ -212,14 +212,14 @@ msgid "" 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 app para usar sockets no " +"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 mas conexiones. Los dos " +"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." @@ -281,13 +281,13 @@ msgid "" 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 que Java " +"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 " -"búfer, y un error común es usar ``write`` para escribir algo y luego usar " +"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 " -"búfer de salida." +"buffer de salida." #: ../Doc/howto/sockets.rst:152 msgid "" @@ -303,7 +303,7 @@ msgstr "" "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 ellso dicen cuántos bytes " +"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." @@ -360,8 +360,8 @@ 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 mas simple es un " -"mansaje de longitud fija:" +"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 "" @@ -503,7 +503,7 @@ msgstr "" "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." +"usar ``shutdown`` de manera explícita no es necesario." #: ../Doc/howto/sockets.rst:282 msgid "" @@ -559,10 +559,10 @@ msgstr "" "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 " -"esta esencialmente muerto. No hay mucho que puedas hacer respecto a eso. A menos " +"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 mas " +"*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." @@ -573,16 +573,15 @@ msgstr "*Sockets* no bloqueantes" # Como traduzco inside-out? #: ../Doc/howto/sockets.rst:315 -#, fuzzy 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 sabes la mayor parte de lo que necesitas " +"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á " +"la misma manera. Es solo eso, si lo haces correctamente, tu aplicación estará " "casi correcta." #: ../Doc/howto/sockets.rst:320 @@ -669,12 +668,12 @@ msgid "" "(Actually, any reasonably healthy socket will return as writable - it just means " "outbound network buffer space is available.)" msgstr "" -"Si un socket esta en la lista retornada de los leíbles, puedes estar tan-seguro-" +"Si un socket está en la lista retornada de los leíbles, puedes estar tan-seguro-" "como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en este socket " "va a devolver *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 búfer de red " +"como escribible - eso solo significa que el espacio de salida del buffer de red " "está disponible)" #: ../Doc/howto/sockets.rst:366 @@ -686,10 +685,10 @@ msgid "" "chance that it has connected." msgstr "" "Si tienes un socket *servidor*, ponlo en la lista de *potenciales leíbles*. Se " -"retorna en la lista de leíbles, una llamada a ``acept`` va a funcionar (casi " -"seguro). Se has creado un nuevo socket para llamar a ``conect`` para conectarte " +"retorna en la lista de leíbles, 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 este conectado." +"de escribibles, tienes una buena oportunidad de que esté conectado." #: ../Doc/howto/sockets.rst:372 msgid "" @@ -700,8 +699,8 @@ msgid "" 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 búfer. 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." +"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:377 msgid "" From e56b521a50a748400a083fdf2e46abf993ef435f Mon Sep 17 00:00:00 2001 From: ktowen Date: Thu, 6 Aug 2020 09:37:24 -0400 Subject: [PATCH 3/3] powrap howto/sockets.po --- howto/sockets.po | 891 ++++++++++++++++++++++++----------------------- 1 file changed, 458 insertions(+), 433 deletions(-) diff --git a/howto/sockets.po b/howto/sockets.po index 91cdad2f97..65619ec76a 100644 --- a/howto/sockets.po +++ b/howto/sockets.po @@ -38,16 +38,18 @@ 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." +"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" @@ -55,40 +57,42 @@ msgstr "Sockets" #: ../Doc/howto/sockets.rst:22 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." +"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\"." +"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" @@ -97,27 +101,29 @@ 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." +"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." +"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)." +"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 de la derivación de *Unix* BSD y se " -"expandió como la pólvora en internet. Con buena razón --- la combinación de los " -"sockets con INET hace que hablar con computadoras arbitrarias alrededor del " -"mundo sea increíblemente sencillo (al menos comparado con otros esquemas)." +"expandió como la pólvora en internet. Con buena razón --- la combinación de " +"los sockets con INET hace que hablar con computadoras arbitrarias alrededor " +"del mundo sea increíblemente sencillo (al menos comparado con otros " +"esquemas)." #: ../Doc/howto/sockets.rst:54 msgid "Creating a Socket" @@ -125,67 +131,70 @@ 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::" +"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:" +"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)." +"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)." +"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\":" +"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." +"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." +"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)." +"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)." +"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." +"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." +"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 "" @@ -197,31 +206,32 @@ msgstr "" #: ../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 " +"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." +"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" @@ -229,23 +239,25 @@ 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." +"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." +"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." +"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." +"El módulo :mod:`multiprocessing` integra IPC multiplataforma en un API de " +"alto nivel." #: ../Doc/howto/sockets.rst:134 msgid "Using a Socket" @@ -253,71 +265,72 @@ 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." +"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." +"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." +"``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." +"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." +"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." +"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 "" @@ -333,102 +346,104 @@ msgstr "" # ‪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)." +"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)." +"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::" +"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.)" +"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)." +"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." +"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." +"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." +"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!" +"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!" +"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 "" @@ -436,9 +451,9 @@ msgid "" "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." +"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" @@ -446,41 +461,42 @@ 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, 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 - ``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." +"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 - ``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:264 msgid "" "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." +"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." 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." +"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:272 msgid "Disconnecting" @@ -488,54 +504,57 @@ msgstr "Desconectando" #: ../Doc/howto/sockets.rst:274 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, adios!\". 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." +"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, " +"adios!\". 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:282 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." +"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:289 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." +"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." +"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:297 msgid "When Sockets Die" @@ -543,29 +562,30 @@ msgstr "Cuando los sockets mueren" #: ../Doc/howto/sockets.rst:299 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." +"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:313 msgid "Non-blocking Sockets" @@ -574,47 +594,48 @@ msgstr "*Sockets* no bloqueantes" # Como traduzco inside-out? #: ../Doc/howto/sockets.rst:315 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." +"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." +"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:320 msgid "" -"In Python, you use ``socket.setblocking(0)`` 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 se usa ``socket.setblocking(0)`` para hacer un socket no bloqueante. " -"En C es un poco más complejo (por una parte, tendrás que decidir entre la manera " -"BSD de usar ``O_NONBLOCK`` y la manera casi indistinguible de Posix de " -"``O_NDELAY``, que es completamente diferente de ``TCP_NODELAY``), pero es " -"exactamente la misma idea. Esto se hace después de crear el socket pero antes de " -"usarlo (Realmente, si estás loco, puedes cambiar de una manera a la otra)." +"In Python, you use ``socket.setblocking(0)`` 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 se usa ``socket.setblocking(0)`` para hacer un socket no " +"bloqueante. En C es un poco más complejo (por una parte, tendrás que decidir " +"entre la manera BSD de usar ``O_NONBLOCK`` y la manera casi indistinguible " +"de Posix de ``O_NDELAY``, que es completamente diferente de " +"``TCP_NODELAY``), pero es exactamente la misma idea. Esto se hace después de " +"crear el socket pero antes de usarlo (Realmente, si estás loco, puedes " +"cambiar de una manera a la otra)." #: ../Doc/howto/sockets.rst:327 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." +"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." +"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:334 msgid "Use ``select``." @@ -622,96 +643,100 @@ msgstr "Usando ``select``." #: ../Doc/howto/sockets.rst:336 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::" +"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:" +"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:347 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." +"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:355 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." +"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 " -"leíbles, escribibles y con error. Cada una de estas lista es un subconjunto " -"(posiblemente vacío) de la lista correspondiente que pasaste." +"En el retorno tendrás tres listas. Estas contienen los sockets que son " +"realmente leíbles, 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:359 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 " +"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 de los leíbles, puedes estar tan-seguro-" -"como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en este socket " -"va a devolver *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)" +"*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 de los leíbles, puedes estar tan-" +"seguro-como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en " +"este socket va a devolver *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:366 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 leíbles*. Se " -"retorna en la lista de leíbles, 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." +"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 leíbles*. " +"Se retorna en la lista de leíbles, 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:372 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." +"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." +"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:377 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." +"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."