I've recently replaced some decades old DNS logic with DnsClient.NET (went from 10k lines down to 1k). One feature I'm now missing is the ability to get results directly from the in-memory cache. I can implement a custom feature but I thought I'd first check if it's a desired feature for this library in which case I can do a PR?
As background the requirement for the cache lookups is for a SIP (VoIP) library. In a similar manner to HTTP, SIP requests and responses are sent using SIP URI's in the form sip:1234@sipsorcery.com. A difference from HTTP is that SIP is normally sent over UDP and therefore has a built in retransmit mechanism. If a SIP message does not get a response it will retry the send at intervals of 0.5, 1s, 2s, 4s, 4s, 4s ... up to 11 retries.
How that's relevant for DNS cache lookups is that for high volume SIP server applications it's not feasible to block the main SIP transport thread waiting for DNS lookups. The desired approach is to get the initial request at t0, identify a DNS lookup is required and then discard the message. At t0.5 the same message will be retransmitted. If the DNS result is in the cache it gets used otherwise the message is again discarded. And so on at t1, t2, t4 etc.
I've recently replaced some decades old DNS logic with
DnsClient.NET(went from 10k lines down to 1k). One feature I'm now missing is the ability to get results directly from the in-memory cache. I can implement a custom feature but I thought I'd first check if it's a desired feature for this library in which case I can do a PR?As background the requirement for the cache lookups is for a SIP (VoIP) library. In a similar manner to HTTP, SIP requests and responses are sent using SIP URI's in the form
sip:1234@sipsorcery.com. A difference from HTTP is that SIP is normally sent over UDP and therefore has a built in retransmit mechanism. If a SIP message does not get a response it will retry the send at intervals of 0.5, 1s, 2s, 4s, 4s, 4s ... up to 11 retries.How that's relevant for DNS cache lookups is that for high volume SIP server applications it's not feasible to block the main SIP transport thread waiting for DNS lookups. The desired approach is to get the initial request at t0, identify a DNS lookup is required and then discard the message. At t0.5 the same message will be retransmitted. If the DNS result is in the cache it gets used otherwise the message is again discarded. And so on at t1, t2, t4 etc.