On Wed, 17 Jan 2001, Werner Almesberger wrote:
> jamal wrote:
> > He should still be able to do reliable communication by doing the
> > state maintanance within the user space app.
> > The mechanism is already in place.
> > [nlmsghdr.nlmsg_seq. as well as flags NLM_F_ACK, NLM_F_ECHO ]
>
> Well, having flow control alone doesn't help. You still have the
> problem of what to do when you generate more events that the
> receiver(s) are handling. In TCP, you simply block the sender,
> or return EAGAIN, pushing the responsibility one level up.
>
I dont know if you have a serious enough problem to mandate congestion
control. Reordering/gaps will happen if you loose a message.
ACKs, seq numbers and timers should suffice plenty, no? The information
about a link state for example doesnt disappear because a netlink message
didnt make it to user space for whatever reason (eg the small rcvbuffer
overflow). You can always pull the details off the kernel when some
associated timer expires. The only problem i see is that if you were
interested in a state
> The question here is of course if the entire communication model
> is appropriate. An alternative approach could be to just record
> that a notification is needed, wake the reader(s), and generate
> the actual message in response to the recvmsg call. This way,
> one could still pretend to user space that we have a simple
> message-based notification system, while underneath, we happily
> compress notifications.
>
> Note that this wouldn't work well in all cases. E.g. if you have
> lots of routes coming and going (and not coming back), you can't
> compress notifications. Of course, netlink may be the least of
> your worries in such a situation ...
>
This is the classical problem Alexey was pointing to. Unsolvable, unless
you have infinite memory in place.
The idea of compressed notifications (update "queues") in the kernel is
beggining to look sane to me. But even for that you need to draw a line
somewhere. And it is only useful if you are really interested in the
sequence of states some entity has gone through. I suspect mostly you
will be interested in knowing the state _current_ as opposed to "what
happened? how did you get here? " kind of thing.
I think the whole retransmit and reliability stuff needs to stay in user-space
cheers,
jamal
|