[Dibbler] Sending methods

Tomasz Mrugalski thomson at klub.com.pl
Wed Dec 29 02:11:04 CET 2004


On Tue, 28 Dec 2004 somebody known as shenjian630 wrote:

>     I read the code in dibbler-0.2.0-src, I have some questions. Why the 
Hey, someone is looking at my code. Cool. Take note that 0.2.0 version is
outdated. Consider downloading 0.3.0, or even not yet released 0.3.1 code.
You can find it by using links on the website and simply replacing
"0.3.0" with "0.3.1", e.g. source can be downloaded from the following 
URL: http://klub.com.pl/dhcpv6/dibbler-0.3.1-src.tar.gz

>body of the answer function in the class TClntMsgAdvertise is empty , and 
>why do you write a sentence "this should never happen" in the {} ?  The 
It does not work that way. Let me explain:
CLI: creates TClntMsgSolicit
CLI: sends this message [TClntMsg::send()]
SRV: recevies msg
SRV: creates TSrvMsgSolicit [TSrvIfaceMgr::select()]
SRV: relays message and prepares proper answer (i.e. TSrvMsgAdvertise is
      created) [TSrvTransMgr::relayMsg()]
SRV: sends reply [TSrvMsg::send()]
CLI: receives msg
CLI: creates TClntMsgAdvertise [TClntIfaceMgr::select()]
CLI: relays message [TClntTransMgr::relayMsg()]
CLI: orginal message is found and reply is being passed, e.g.
      solicit->answer(advertise)
CLI: received Advertise is analysed [TClntMsgSolicit::answer()] and
      Request message is being generated [TClntTransMgr->sendRequest()]

And that's how it works.

>location of the answer function what I say is at ClntMsgAdvertise.cpp 
>,line 79. I think the client sends the REQUEST message after it receives 
>the ADVERTISE message. In dibbler-0.2.0-src, it creates a new pointer 
>which points to the class TClntMsgAdvertise,
> like "ptr = new TClntMsgAdvertise". But I can not find which function 
>you use to send the REQUEST message. I consider that you use the answer 
Take a look at TClntTransMgr::sendRequest(). It's also good to know that 
all those send functions (sendSolicit(), sendRenew() etc.) do not really 
send those packets, they are only adding them to the TransMgr list. 
Consider this list as "transactions in progress". This process is being 
logged in a rather detailed manner:

[1] 59:47 Info      Creating SOLICIT message  on eth0 interface.
[2] 59:47 Notice    Sleeping for 1 second(s).
[3] 59:48 Info      Processing msg (SOLICIT,transID=0x8c59ec,opts: 1 3 8 6)
[4] 59:48 Debug     Sending SOLICIT on eth0/2 to multicast.

1. Solicit is created and added to the list.
2. DHCPClient::run() does another run in the main loop.
3. Every message stored in the list is being processed.
4. New (not sent yet) message is detected in the list, so it is being 
sent.

>function in the class TClntMsgAdvertise to send the REQUEST message, 
>however it is empty. Maybe I am wrong. That is my puzzle.
Nobody said that Dibbler's code is plain and simple. I'm glad that the 
word you have used is just "puzzle" :)

>Thank you very much!
No problem. I strongly advise you to download newer version. Besides new 
features and lots of bug fixes, it also has improved logging system (logs 
are always stored in a file and many messages were clarified).

> Happy new year, with best wishes!
Thanks. And to you, too!

-- 
Tomasz Mrugalski,              | "In a World without Walls and Fences  |
thomson(at)klub(dot)com(dot)pl |  who needs Windows and Gates?"        |
                               |                      seen on T-shirt  |


More information about the Dibbler mailing list