9 Feb
2017
9 Feb
'17
3:58 p.m.
On 9 Feb 2017 10:19 +0100, from pnr(a)planet.nl (Paul Ruizendaal):
A TCP connection spends most of its time in the
'established' state. I
wonder if just putting the code for this state in the kernel and handling
only the state changes and other states in a daemon is perhaps the best
split on constrained hardware. I'm not aware of any historical
implementation having that design, so perhaps it is flawed thinking.
Wouldn't the state change code need to be executable, even if it
technically isn't in the kernel? I can see no _obvious_ reason why you
_couldn't_ have a daemon handling state changes and non-established
TCP connections, but I'm having a hard time seeing what it would save
you in terms of code size. If anything, it seems like the code would
need to be a little larger in total, because now you have two
components interacting where previously there was just one component
doing all of the work.
One benefit I can see though would be to reduce the incidence of bugs
in the established-state code; less code running privileged means less
things to screw up so badly that the system panics (or scribbles over
the wrong data). A crashed TCP daemon would be an annoyance, but would
at least allow you to restart it or to reboot the system at leisure
rather than having the whole system come to a screeching halt.
You'd need some amount of synchronization either way, to prevent two
connections changing state at the same time from stepping on each
other's toes, but that would hardly be unheard of in the kernel of a
multitasking OS...
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)