> but why would we have a partial retransmission in the first place?
> under which circumstances would the receiver only ACK half the packet
> it has received, causing a partial retransmission on the sender side?
F.e. path mtu discovery. Well, this is really marginal effect, almost
impossible in real life. Especially taking into account that PORT is short.
> tcp packet one: "PORT 192,16"
> packet two: "8,1,1,12,34\r"
> (or even more packets). How would we reliably match against the command?
> Where do you draw the line? what is about each character in one packet?
"PORT xxx" is removed from stream and replacement is inserted to this point.
No problems with location.
The problem is present, but it is different: before you received all
the information, you cannot send subsequent packets and have to drop them.
It is already flaw of approach, not a question of quality.
[ Note: I really think the approach is capitally and badly wrong with
no rights to survive. Ring buffer is already part of right approach.
Probably, it is worth to say what I think about this. Right start
point is two TCP connections connected back-to-back. All the scheme
should be based on this. After this you start to optimize shortcutting
some things, but not breaking semantics. With plain NAT nothing but
TCP state monitoring remains, with rewriting you leave more, or even all
in the most hard situations.
> And please don't think that any previous linux version did better than
> we currently do.
I do not think this. It was surely worse.
> But then, nat is always ugly and un-perfect. And how much additional
> code complexity
Well, I just found this funny comment occasionally and wanted to know what
is this and how it was possible to classify some sender of some tcp
as a "cracker". :-)
> 0.00001% cases?
Yes, maybe even much less. Multiply by amount of users and one day person
of this 0.00001% will find this and bug you.
Well, when something is easy it should be made. Counting of presents
apply to the case when something is difficult.