Quote from: MPOE-PR on November 18, 2012, 04:03:24 PM

Well, since we're discussing this: your computer sends a SYN. The MPEx server goes SYN-ACK. Your computer goes ACK. The TCP connection is not established. Your computer goes POST. The MPEx server responds to that POST. Your failure scenario was that somehow right after the POST but right before the response completion the connection drops. This scenario is possible in theory, but not quite comparable with the general "oh maybe the connection failed we'll investigate" alternative.

I'm rather bored with this discussion. You are dense. I'll try to spell it out for you one more time, but this is the last time...

OK, let's consider it from user's perspective. User tries to submit order to MPex. His user agent "hangs". User doesn't know whether his order was accepted. He waits for some time, let's say 30 seconds, then clicks "stop" button and tries to check whether order was accepted by other means.

Let's say order was not accepted, then user will try to re-submit it.

Suppose it was time sensitive like it was with smickles order. How is MPex going to explain why order wasn't accepted immediately? Most likely response is "oh maybe the connection failed we'll investigate": connection failure is indeed the most likely cause, but it is a good idea to check server logs.

If user was running Wireshark, or maybe just in-browser debugger like firebug, he would know more about this failure, but let's just say a typical user doesn't run Wireshark so it doesn't matter.

Now let's consider a bit more complex case: suppose that packet which was carrying request body was buffered at some router between user's computer and MPex server and was "in flight" for some considerable time, e.g. 1 minute. It's possible in case of congestion, packet loss/retransmission, routing problems etc.

In that case we can a situation like this: 1) user clicks "stop" button in browser, but it doesn't stop packets which are already in flight; 2) user checks state, it says that order is not accepted; 3) now those packets which are in flight arrive to server and it actually accepts the offer. Whoopsie.

It isn't simply theoretically possible, this actually happens. Say, when I use ssh sometimes it freezes and I see what I typed after a significant delay.

So... How is this different on ICBIT? I don't know. As I understand, there is no progress indicator, but it is not a fundamental flaw, it can be trivially added. Otherwise, situation is identical.

It is completely independent from transparency issues, I agree that use of PGP signatures and full transaction log are desired features.

But that wouldn't have helped smickles. On the other hand, Wireshark could: he could see whether he got SYN-ACK and whether server ACKnowledged that it received POST body. Having that log he could prove that problem is indeed at ICBIT's side. (Sort of, ACK isn't signed... But it would be a good evidence.) Unless ICBIT blocked him via IP address on firewall (iptables TARPIT). Then he would need to use pathping to collect evidence...

Anyway, you need to learn a bit more about how networking works (just knowing about SYN-ACK isn't enough), and how to consider concurrency problems (i.e. you need to consider all possible event orderings for all participants). Also you have serious problems with logic. ("MPex uses PGP signatures, and thus ICBIT sucks". Really?)