Kern Mod and TCP retrasmit problem

[Cole]

Hi.

These are obviously things I will need to look into regarding
retransmission if the packet does actually get lost.

As for the MTU issue, if the kernel mod pushes the data over the MTU
size, then the packet is not changed and left as is.

I was hoping to keep this clean, and use existing methods for hooking
into the stream. Also the goal im working for is to be able to use
this on a box doing routing to hopefully get some sort of compression
working between 2 end points. So most of the data would not actual be
generated from userland processes.

So im back to the original issue of trying to track down the
variable/structure that is holding the original size of the packet or
some variable holding the expected return ACK?

Thanks
/Cole

On 17 May 2011 14:48, Daniel Hartmeier <daniel at benzedrine.cx> wrote:
> What if your modified (shortened) packet does get lost? If you
> messed with the tcpcb in the way you intend, how do you plan on
> getting retransmission working, when it's needed?
>
> Or what if you enlarge a packet, are you sure it won't violate
> the MTU?
>
> It seems you're doing this on wrong side of the stack. Why don't
> you hook your code into the side facing userland, where socket
> writes from the userland process add data to the kernel buffer,
> and the socket is still a stream?
>
> Or what's the reason for doing it after the stream has been
> packetized already?
>
> Daniel
>