[haiku-gsoc] Re: Fwd: Re: [HCD08] ICMP error handling & propagation project
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: "Yin Qiu" <allenchue@xxxxxxxxx>
- Date: Sun, 13 Jul 2008 19:05:31 +0200 CEST
"Yin Qiu" <allenchue@xxxxxxxxx> wrote:
> I am notified that I have to subscribe the haiku-gsoc mailing list. I
> tried
> and was informed that I am already a subscriber of it, which was
> supposed to
> be. It seems that the something went wrong about the mailing list, so
> I am
> forwarding the previous mail to you directly.
Bummer; sometimes it makes sense to check in the mailing list history
if your mail actually showed up when in doubt. In any case, I'm
answering to you personally and on the list.
> Attached is a diff file and an header file reflecting my current
> understanding about the project. The code is most just skeleton.
> Vachkov's
> work was my primary reference. Please help me by checking the new
> code and
> added comments to see if my understanding is correct.
Besides some very minor coding style issues (the comment style is a bit
inconsistent, some constant naming could be improved (like
NET_ERROR_FRAG_DF)), I think you are on the right track.
> I also have some additional questions, which might be stupid.
Nope, not this time ;-)
> 1. How does the IPv4 protocol dispatch the error to the target
> protocol in
> case of an invocation of error_received()?
It would need to do something similar to what it already does for
ipv4_receive_data() - determine the target protocol, and forward it to
that one.
> 2. On the other side, how does the ICMP protocol call the
> error_received()
> hook of the IPv4 protocol?
The ICMP protocol would either need to register itself as an error
handler with the domain (and gains some special functions it could
use), or it would just directly call the error_received() function on
the domain.
> 3. Source quench message is supposed to be sent when the host or
> gateway is
> receiving datagrams that exceeds its processing capacity. How do we
> determine the incoming datagrams are actually exceeding or
> approaching the
> capacity?
Since we cannot restrict our CPU usage in any way, the only way for
this to happen would be the lack of memory to create new buffers. So if
a new buffer cannot be created due to a B_NO_MEMORY error, the source
quench message could be generated.
Since this might come too late (both report-wise and layer-wise), you
might also want to have a look at other operating systems (like Linux
or FreeBSD) how they handle this, and if they send those messages at
all.
> 4. As Alan previously pointed out, when the upper protocol like TCP/
> UDP
> encounters an error, it should call the error_reply() hook, which in
> turn
> generates the ICMP error message. According to RFC 792, this ICMP
> message
> should include original IP header, which has been removed prior to
> propagating the packages to upper protocol. I checked the original
> thread
> and it seems that no solution was given. Do you have any clue to
> solve this
> problem?
We had a few possible suggestions outlined in that thread. IIRC I
favored adding the header as an extra field (protected against changes)
to the net_buffer, so that it can later still be accessed.
Another way would be to reconstruct that header on the fly if that is
possible (which might be by storing only a tiny bit more than what the
net_buffer already has).
Again, it might be educational to have a look at other platforms; while
other networking stacks have usually less strictly separated layers,
the general problem is the same.
HTH, and I'm looking forward for your next questions (and diffs) :-)
Bye,
Axel.
Other related posts:
