< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] RFC 3263, reSIProcate vs sipX


Good thing I went to lunch after I sent that last post. :)  I'll leave ares
in, but I'd still like to use the TestDns class synchronously, with only one
Query per calling thread.  Is that possible?  If critical regions in the
stack library are mutex protected, I figure my calling threads could use
DnsInterface independently and block when necessary.

To do so, I figure I need to do this, in testDns.cxx:

- leave TestDnsHandler unchanged, since it needs to collect the results. 
- change TestDns to only inherit from DnsInterface, and remove the thread()
method
- from main(), remove dns.run, dns.shutdown, and dns.join
- load my Query like the (argc == 1) case.  If TestDns is no longer a
thread, will it block at dns.lookup?
- if so, I wont need to check handler->complete(), which should be true when
lookup finishes
- I would still iterate through the handler->results vector for the single
query the same way.

Dave

PS: I saw the 1.0.2 tar file in the release directory, thanks.

-----Original Message-----
From: Robert Sparks

Our messages crossed.

ares provides the wire-level DNS client.

RjS

On Nov 28, 2006, at 11:35 AM, Dave Mason wrote:

> Running this stuff against a test DNS server will be my final step.  I 
> havent done much with DNS besides check the RFC and buy the book, so 
> any tips on setting that up will be much appreciated.
>
> As for the code, that confirms my suspicions.  Mostly I was hoping 
> there wasn't much I'd need to pull out of the stack besides the stuff 
> you mentioned.  As for rutil I'll just try whittling it down and see 
> what I can get away with.
>
> One thing I forgot to ask before:  I'm already running in a 
> multithreaded environment, so I don't think I need ARES and the async 
> stuff.  I'm thinking I can just comment USE_ARES out of the 
> Makefile.pkg, along with the stuff in the main Makefile that builds 
> the ares library?  I'll try that next.  As long as everything is 
> reentrant I should be OK.  Then to test it, I'll fix the TestDns class 
> in testDns.cxx to not inherit from ThreadIf.
>
> Thanks,
> Dave
>
>
> -----Original Message-----
> Subject: Re: [reSIProcate] RFC 3263, reSIProcate vs sipX
>
>       I have recently done some work on the resip DNS code to get it up to

> snuff. testDns is much, much bigger now, but it needs a test DNS
> zone- file
> to be set up in a very particular way for it to work. I want to try to 
> have this done sometime this week.
>
>       As for isolating the DNS code, you will need to pull a lot of rutil 
> with it. Also, you'll need resip/stack/DnsResult.[hc]xx (where all the 
> 3263 logic is) and resip/stack/DnsInterface.[hc]xx to make it all go. 
> I know for sure this drags resip/stack/Tuple.[hc]xx in as well, and 
> possibly other stuff.
>
> Best regards,
> Byron Campen
>
>> Hi,
>>
>> I posted this right before the holiday last week, no doubt it got 
>> lost in a haze of turkey and football.  Since then I figured out my 
>> compile problem.
>> I was missing gperf.  I installed that, along with a new openssl and 
>> Berkeley db, and things generally ran fine.
>>
>> My other questions remain, and I'm still curious what people here 
>> think about sipX vs resiprocate.  There is a resip/stack/test/testDns 
>> program that appears to do exactly what I need, so my goal now is to 
>> identify the supporting classes it needs and extract them from the 
>> rest of the stack.
>> Aside from just getting it to compile, any advice on what to leave in 
>> or out will help too.
>>
>> Regards,
>> Dave
>>
>> ---------Original message-------------- Hi all,
>>
>> I've got a question about the SIP stack code.  This seemed like the 
>> right list, my apologies if it should go to the user list.
>>
>> I have a working SIP stack that does not support 3263 SRV and NAPTR 
>> lookups.
>> It only does a basic gethostbyname from DNS.  My mission is to add
>> 3263
>> support, so I checked the most popular open source SIP stacks looking 
>> for a DNS access class that I could pick up and drop into my stack.
>> The big ones appear to be reSIProcate and sipX.  They both look good 
>> but have very different designs, so I thought I'd check here for some 
>> help in picking one.
>>
>> sipX has a class called SipSrvLookup that, at first glance, appears 
>> to do exactly what I need.  On the other hand, reSIProcate looks like 
>> it has lot more going on, so I wonder what functionality it must have 
>> that the other does not.  I had more trouble figuring out where to 
>> start with this one, so I have some questions that maybe yall can 
>> help with here:
>>
>> - First, any general things to keep in mind in choosing between the 
>> two will help.  I think I saw a FAQ on this somewhere, which led me 
>> to believe reSIProcate has a lot more features, but I'm not sure 
>> particularly how that applies to my case.  One thing I noticed is 
>> that reSIProcate has a lot more abstraction around the DNS layer.  
>> Does this buy you much?
>>
>> - I need to call some method that will do "find me a SIP server using 
>> RFC
>> 3263 methods if possible, otherwise gethostbyname."  In sipX this 
>> method looks like SipSrvLookup::servers.  In reSIProcate, is it 
>> DnsInterface::lookup?  That method returns a DnsResult object, which 
>> I guess contains a list of servers that you search using its lookup 
>> method.
>> Hopefully I don't need to change my application code much.
>>
>> - Once I identify the method I need to call, I need to pick out the 
>> supporting classes that it needs.  I don't need the whole stack, just 
>> the
>> 3263 part of it.  I guess this will be parts of resip/stack and 
>> rutil/dns?
>> Any help with this will simplify things a lot.
>>
>>  <deleted stuff about compile problem>
>>
>> Thanks for your help!
>>
>> Dave