Efficient methods
in [Embedded]
|
From: Rick Jones on 22 Feb 2010 13:53 > > While I understand that some lazy programmers might use TCP/IP for > > some minor ad hoc applications. > Because it's a *reliable* transport protocol? Why waste effort in > the application doing what an off the shelf stack can do for you? Well, TCP does not actually guarantee the data will make it to the remote, what TCP guarantees is notification of probable non-delivery. rick jones -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: Paul Keinanen on 22 Feb 2010 16:03 On Mon, 22 Feb 2010 18:53:28 +0000 (UTC), Rick Jones <rick.jones2(a)hp.com> wrote: > >> > While I understand that some lazy programmers might use TCP/IP for >> > some minor ad hoc applications. > >> Because it's a *reliable* transport protocol? Why waste effort in >> the application doing what an off the shelf stack can do for you? > >Well, TCP does not actually guarantee the data will make it to the >remote, what TCP guarantees is notification of probable non-delivery. Neither does the TCP re-establish connection from the client to the server if the server is rebooted, powered up, hardware replaced, switch to a redundant unit (and if symbolic addressing is used, change of IP address). You still need to build an additional layer to handle these events and re-establishing connections for non-attended 24/7 operation.
From: Rick Jones on 22 Feb 2010 17:10 In comp.os.linux.networking Paul Keinanen <keinanen(a)sci.fi> wrote: > On Mon, 22 Feb 2010 18:53:28 +0000 (UTC), Rick Jones > <rick.jones2(a)hp.com> wrote: > > Well, TCP does not actually guarantee the data will make it to the > > remote, what TCP guarantees is notification of probable > > non-delivery. > Neither does the TCP re-establish connection from the client to the > server if the server is rebooted, powered up, hardware replaced, > switch to a redundant unit (and if symbolic addressing is used, > change of IP address). > You still need to build an additional layer to handle these events > and re-establishing connections for non-attended 24/7 operation. Indeed. In the parlance of the seven-layer (or nine depending on one's point of view - https://www.isc.org/files/9layer.thumb.png) TCP is but a transport protocol, it is not a session protocol. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: glen herrmannsfeldt on 22 Feb 2010 17:16 In comp.protocols.tcp-ip Paul Keinanen <keinanen(a)sci.fi> wrote: (snip) > Neither does the TCP re-establish connection from the client to the > server if the server is rebooted, powered up, hardware replaced, > switch to a redundant unit (and if symbolic addressing is used, change > of IP address). UDP will do some of those. The UDP implementation of NFS is pretty good at surviving server reboots and continuing on as if nothing changed. I believe the TCP implementations automatically reconnect, transparent to the user. > You still need to build an additional layer to handle these events and > re-establishing connections for non-attended 24/7 operation. -- glen
From: Paul Keinanen on 22 Feb 2010 17:54
On Mon, 22 Feb 2010 22:16:23 +0000 (UTC), glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >In comp.protocols.tcp-ip Paul Keinanen <keinanen(a)sci.fi> wrote: >(snip) > >> Neither does the TCP re-establish connection from the client to the >> server if the server is rebooted, powered up, hardware replaced, >> switch to a redundant unit (and if symbolic addressing is used, change >> of IP address). > >UDP will do some of those. The UDP implementation of NFS is >pretty good at surviving server reboots and continuing on as >if nothing changed. I believe the TCP implementations automatically >reconnect, transparent to the user. > >> You still need to build an additional layer to handle these events and >> re-establishing connections for non-attended 24/7 operation. > >-- glen If the TCP implementation of NFS will perform the reconnection, then that is the feature of the NFS, not the TCP. |