All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1ee3ee6e05ae30a229306a8863c83d44@localhost>

diff --git a/a/1.txt b/N1/1.txt
index b3ecc54..2af379a 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,28 +1,54 @@
 
 On Mon, 22 Aug 2011 09:33:52 +0900, "Jun.Kondo" wrote:
+
 > By using this patch, we want to prevent "timeout occured over the
+
 network
+
 > that is low throughput but available".
+
 > 
+
 > But in the current implementation, both blocking and non-blocking,
+
 > user processes can't recognize the reason in detail
+
 > when failed to write to socket buffer, we think.
 
+
+
 For your application it should not matter WHY the data can be written to
+
 the peer. It can be happened that the peer close the window, some
+
 scheduling bottleneck or whatever else. A blocking socket means for you
+
 that some data is in the pipe, waiting for transmit. This is the knowledge
+
 that you require, and you should deal with it. A blocking socket does not
+
 mean FAILED, a failure is returned via ECONNRESET or otherwise. So
+
 everything is fine when your socket blocks. Probably you should adjust your
+
 Apache timeouts or other parts of the program logic.
 
+
+
 > As stated above, we think it is difficult for user processes to handle
+
 > timeout of writing socket buffer,
+
 > when wmem is configured large value.(to ensure high throughput over the
+
 > high ralency network, like 3G).
 
+
+
 No, you should adjust your code and account that the socket has data in
+
 the pipe. That's all.
 
+
+
 Changing tcp_lowat
diff --git a/a/content_digest b/N1/content_digest
index 689f1cf..cb79d8b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -21,31 +21,57 @@
  "b\0"
  "\n"
  "On Mon, 22 Aug 2011 09:33:52 +0900, \"Jun.Kondo\" wrote:\n"
+ "\n"
  "> By using this patch, we want to prevent \"timeout occured over the\n"
+ "\n"
  "network\n"
+ "\n"
  "> that is low throughput but available\".\n"
+ "\n"
  "> \n"
+ "\n"
  "> But in the current implementation, both blocking and non-blocking,\n"
+ "\n"
  "> user processes can't recognize the reason in detail\n"
+ "\n"
  "> when failed to write to socket buffer, we think.\n"
  "\n"
+ "\n"
+ "\n"
  "For your application it should not matter WHY the data can be written to\n"
+ "\n"
  "the peer. It can be happened that the peer close the window, some\n"
+ "\n"
  "scheduling bottleneck or whatever else. A blocking socket means for you\n"
+ "\n"
  "that some data is in the pipe, waiting for transmit. This is the knowledge\n"
+ "\n"
  "that you require, and you should deal with it. A blocking socket does not\n"
+ "\n"
  "mean FAILED, a failure is returned via ECONNRESET or otherwise. So\n"
+ "\n"
  "everything is fine when your socket blocks. Probably you should adjust your\n"
+ "\n"
  "Apache timeouts or other parts of the program logic.\n"
  "\n"
+ "\n"
+ "\n"
  "> As stated above, we think it is difficult for user processes to handle\n"
+ "\n"
  "> timeout of writing socket buffer,\n"
+ "\n"
  "> when wmem is configured large value.(to ensure high throughput over the\n"
+ "\n"
  "> high ralency network, like 3G).\n"
  "\n"
+ "\n"
+ "\n"
  "No, you should adjust your code and account that the socket has data in\n"
+ "\n"
  "the pipe. That's all.\n"
  "\n"
+ "\n"
+ "\n"
  Changing tcp_lowat
 
-4ce1c23a2f7bf34624e4d0cdd849c2e8e3515a9f94c52a8f7f9700cf97ed9d2a
+f43644b5ccd469e3b05606f90a987f2990d07df09a75f72ca6955b6ed432e641

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.