Messages in this thread | | | From | "Mike Black" <> | Subject | Re: Client receives TCP packets but does not ACK | Date | Sat, 16 Jun 2001 07:55:59 -0400 |
| |
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 people.
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 PROBLEMS!!!!
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 thing.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |