@@ -209,7 +209,7 @@ msgid ""
209209"allocated port which will be recycled when the conversation ends."
210210msgstr ""
211211"事實上，有三種方法可以讓這個迴圈運作 - 分配一個執行緒 (thread) 來處理 "
212- "``clientsocket`` 、建立一個新行程 (process) 來處理 ``clientsocket``，或者將"
212+ "``clientsocket`` 、建立一個程序 (process) 來處理 ``clientsocket``，或者將"
213213"這個程式重新改寫成使用非阻塞 socket，並使用 ``select`` 在我們的「伺服器端」"
214214"socket 和任何有效的 ``clientsocket`` 之間進行多工處理。稍後將會更詳細的介紹。"
215215"現在最重要的是理解：這就是「伺服器端」socket 做的\\ *所有*\\ 事情。它不會發送任何"
@@ -231,7 +231,7 @@ msgid ""
231231"a shortcut around a couple of layers of network code and be quite a bit "
232232"faster."
233233msgstr ""
234- "如果你需要在一台機器上的兩個行程間進行快速的行程間通訊 (IPC)，你應該考慮使用"
234+ "如果你需要在一台機器上的兩個程序間進行快速的程序間通訊 (IPC)，你應該考慮使用"
235235"管道 (pipes) 或共享記憶體 (shared memory)。如果你確定要使用 AF_INET sockets，"
236236"請將「伺服器端」socket 綁定到 ``'localhost'``。在大多數平台上，這樣將會繞過幾個"
237237"網路程式碼層，並且速度會更快一些。"
@@ -240,7 +240,7 @@ msgstr ""
240240msgid ""
241241"The :mod:`multiprocessing` integrates cross-platform IPC into a higher-level "
242242"API."
243- msgstr ":mod:`multiprocessing`將跨平台的行程間通訊整合到更高層的 API 中。"
243+ msgstr ":mod:`multiprocessing`將跨平台程序間通訊整合到更高層的 API 中。"
244244
245245#: ../../howto/sockets.rst:134
246246msgid "Using a Socket"
@@ -535,13 +535,13 @@ msgid ""
535535"automatic recycling of resources. In other words, if you do manage to kill "
536536"the thread, your whole process is likely to be screwed up."
537537msgstr ""
538- "使用阻塞式 socket 最糟糕的地方可能是在另一端突然強制關閉（未執行 ``close``
538+ "使用阻塞式 socket 最糟糕的地方可能是在另一端突然強制關閉（未執行 ``close``）"
539539"的情況下會發生什麼？你的 socket 很可能會處於阻塞狀態。TCP 是一種可靠的協議，"
540540"它在放棄連線之前會等待很長很長的時間。如果你正在使用執行緒，整個執行緒基本上"
541541"已經無法使用。在這方面，你無法做太多事情。只要你不做一些愚蠢的事情，比如在"
542- "執行阻塞式讀取時持有一個鎖，那麼執行緒並不會消耗太多資源。**不要**\\ 試圖終止"
543- "執行緒 -執行緒比行程更有效的部分原因是它們避免了與自動回收資源相關的開銷 。換"
544- "句話說，如果你確實設法終止了執行緒，整個行程可能會出現問題 。"
542+ "執行阻塞式讀取時持有一個鎖，那麼執行緒並不會消耗太多資源。**不要**\ 試圖終止"
543+ "執行緒 -執行緒比程序更有效的部分原因是它們避免了與自動回收資源相關的開銷 。換"
544+ "句話說，如果你確實設法終止了執行緒，整個程序可能會出現問題 。"
545545
546546#: ../../howto/sockets.rst:318
547547msgid "Non-blocking Sockets"
@@ -555,8 +555,8 @@ msgid ""
555555"will be almost inside-out."
556556msgstr ""
557557"如果你已經理解了前面的內容，你已經知道了大部分關於使用 sockets 的機制的所需知"
558- "識，你仍然會以非常相似的方式使用相同的函式。只是 ，如果你做的對，#, fuzzy（這 "
559- "邊的 inside-out）不確定要怎麼翻 。"
558+ "識，你仍然會以非常相似的方式使用相同的函式。就這樣而已 ，如果你做的對，你的程式 "
559+ "就會是近乎完美的 。"
560560
561561#: ../../howto/sockets.rst:325
562562msgid ""
@@ -583,7 +583,7 @@ msgid ""
583583"and do it right."
584584msgstr ""
585585"主要的機制差異在於 ``send``、``recv``、``connect`` 和 ``accept`` 可能在沒有執"
586- "行任何操作的情況下就回傳了。你當然有多種選擇。你可以檢查返回值和錯誤代碼 ，但"
586+ "行任何操作的情況下就回傳了。你當然有多種選擇。你可以檢查回傳值和錯誤代碼 ，但"
587587"這些操作通常會讓自己抓狂。如果你不相信我，不妨試試看。你的應用程式會變得臃"
588588"腫、錯誤百出，並且占用 CPU。所以，讓我們跳過無腦的解決方案，使用正確的方式。"
589589
@@ -599,9 +599,7 @@ msgid ""
599599msgstr ""
600600"在 C 中，編寫 ``select`` 是非常複雜的，但在 Python 中，這很簡單，並與 C 的版"
601601"本非常類似，如果你理解了 Python 中的 ``select``，在 C 中處理它時也不會有太大"
602- "的困難\n"
603- "\n"
604- "::"
602+ "的困難： ::"
605603
606604#: ../../howto/sockets.rst:352
607605msgid ""
@@ -616,7 +614,7 @@ msgstr ""
616614"你傳遞給 ``select`` 三個列表：第一個列表包含你可能想要嘗試讀取的所有 "
617615"sockets；第二個包含所有你可能想要嘗試寫入的 sockets，最後一個（通常為空）包含"
618616"你想要檢查錯誤的 sockets。你應該注意，一個 socket 可以同時存在於多個列表中。"
619- "``select``的調用是阻塞的 ，但你可以設置超時。通常這是一個明智的做法 - 除非有"
617+ "``select``呼叫是阻塞的 ，但你可以設置超時。通常這是一個明智的做法 - 除非有"
620618"充分的理由，否則給它一個很長的超時（比如一分鐘）。"
621619
622620#: ../../howto/sockets.rst:360
@@ -638,9 +636,9 @@ msgid ""
638636"it just means outbound network buffer space is available.)"
639637msgstr ""
640638"如果一個 socket 在輸出的可讀列表中，你可以幾乎確定，在這個業務中我們能夠得到"
641- "的最接近確定的事情是，對該 socket 的 ``recv``調用將會返回一些 *內容*。對於可寫"
642- "列表，也是同樣的思想 。你將能夠發送一些 *內容*， 也許不是全部，但 *一些內容*\\ 總比"
643- "什麼都沒有好。（實際上，任何比較正常的套接字都會以可寫的方式回傳 - 這只是意味"
639+ "的最接近確定的事情是，對該 socket 的 ``recv``呼叫將會回傳一些 *內容*。對於可寫"
640+ "列表，也是同樣的想法 。你將能夠發送一些 *內容*。 也許不是全部，但 *一些內容*\\ 總比"
641+ "什麼都沒有好。（實際上，任何比較正常的 socket 都會以可寫的方式回傳 - 這只是意味"
644642"者「外送網路 (outbound network)」的緩衝空間是可用的。）"
645643
646644#: ../../howto/sockets.rst:371
@@ -652,7 +650,7 @@ msgid ""
652650"have a decent chance that it has connected."
653651msgstr ""
654652"如果你有一個「伺服器端」socket，請將其放在 potential_readers 列表中，如果它在"
655- "可讀列表中出現，你的 ``accept``調用 （幾乎可以確定）會成功。如果你創建了一個 "
653+ "可讀列表中出現，你的 ``accept``呼叫 （幾乎可以確定）會成功。如果你建立了一個 "
656654"新的 socket 去 ``connect`` 到其他地方，請將它放在 potential_writers 列表中，"
657655"如果它在可寫列表中出現，那麼他有可能已經連接上了。"
658656
@@ -665,7 +663,7 @@ msgid ""
665663"something else."
666664msgstr ""
667665"實際上，即使是使用阻塞式 socket 的情況下，``select`` 也很方便。這是一種判斷是否"
668- "會被阻塞的方法之一 -
666+ "會被阻塞的方法之一 - 當緩衝區中有某些內容時， socket 會回傳為可讀。然而，這"
669667"仍然無法解決判斷另一端是否完成，或者只是忙於其他事情的問題。"
670668
671669#: ../../howto/sockets.rst:382
@@ -678,6 +676,6 @@ msgid ""
678676msgstr ""
679677"**可移植性警告**：在 Unix 上，``select`` 同時適用於 sockets 和文件。但請不要"
680678"在 Windows 上嘗試這麼做，在 Windows 上，``select`` 只適用於 sockets。同時，請"
681- "注意，在 C 語言中，許多更高級的 socket 選項在 Windows 上有不同的實現方式。實"
682- "際上，在 Windows 上，我通常會使用執行緒（這非常非常有效 ）與我的 sockets 一起"
679+ "注意，在 C 語言中，許多更進階的 socket 選項在 Windows 上有不同的實現方式。實"
680+ "際上，在 Windows 上，我通常會使用執行緒（這非常，非常有效 ）與我的 sockets 一起"
683681"使用。"