Date: Tue, 17 May 2011 15:16:51 +0200 From: Cole <cole@opteqint.net> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-net@freebsd.org Subject: Re: Kern Mod and TCP retrasmit problem Message-ID: <BANLkTinDY4ny1Y8Ur64S9r_GjHrHPaOM=Q@mail.gmail.com> In-Reply-To: <20110517124855.GA25571@insomnia.benzedrine.cx> References: <BANLkTi=qLfYCA=A5pCSk9OgMCV_9s4zkLg@mail.gmail.com> <20110517124855.GA25571@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinDY4ny1Y8Ur64S9r_GjHrHPaOM=Q>