[lkml]   [2001]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Client receives TCP packets but does not ACK
    OK guys -- how much money are you willing to be that TCP is guaranteed??
    Since you don't want to talk OSI that's OK -- that's just to educate some

    Try this: (this is what I ran into years ago and had to argue to death).

    #1 Client1 has tcp connection to Server1. Both machines are setup to retry
    connections if they fail.
    #2 Server1 has power outage (note that Client1 has absolutely NO idea what
    happens until Server1 is back up again no RST -- no nothin').
    #3 Client1 finally times out and is able to reconnect to Server1 and thinks
    everything is OK (as do all the programmers at our customer who think TCP is
    a guaranteed protocol).
    #4 Analysis shows numerous transacations have been lost (complete panic by
    the customer).

    Here's the big question. Who's fault is it? Our customer tried to claim
    that the TCP stack was at fault on our server (a Windows 3.1 box) because it
    "dropped packets" and didn't know about it. Then they thought that the TCP
    stack on their client was at fault because it never showed an error trying
    to write to the socket.

    After much argument I finally was able to show them (from the author of TCP
    whom I emailed for support) that TCP is NOT guaranteed -- it's up to what
    you guys are calling the "API" layer (OSI Layer 7) to ENSURE that data
    ACTUALLY gets to it's intended target. I was brought in late on this
    contract but I never would've implemented the brain-dead protocol (or
    actually complete lack of one) for sending transactions across a socket.

    You're right in that TCP will work just fine AS LONG AS THERE ARE NO

    You can write a program that just opens a socket and blasts data to the
    recipient without an error. And as long as your protocol is session
    oriented you'll be fine. If the session aborts you just resend the whole

    But that does NOT make a robust solution for a transaction oriented protocol
    (like the one that started this thread) (contrary to what many people think
    AND code up).
    P.S. My reference to TCP being at OSI layer 5 is because that's what the API
    is for sockets -- Session Layer -- and that's all that people generally
    think is needed. Big mistake if you're transaction-oriented.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.034 / U:12.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site