The biggest problem with caching is that it won't be accurate in some cases. Imagine you are competing for a name during NSI drop times, and OpenSRS does a cache refresh once a minute, how slim would your chances be to actually register that name, since OpenSRS will register the fact that the name becomes available on average 30 secs after it happened on the registry level. I think a bigger speed improvement would for example be to implement a bulk lookup API where the client sends one packet with a request for multiple TLDs and then OpenSRS takes it and queries all registries for those TLDs and returns one packet to the client side with all results - that way we can eliminate multiple round-trips between the client and the server and the gazillion packets that get involved in such operation.
Regadrs, Vlad Jebelev OpenSRS developer On Sun, 30 Dec 2001 [EMAIL PROTECTED] wrote: > You should also take into consideration that the > Registry-Registrar-Protocol only allows one lookup at a time. > > Now they could implement caching of prior lookup results (like I believe > some other registrars do) and return local results if the cache entry for > the domain being looked up hasn't expired. This could possibly speed up > some lookups (like for popular names) as it would eliminate the registry > delay. However this may be more work than its worth... > > On Sun, 30 Dec 2001, Jose Luis Moya wrote: > > > It is not directly related to this questions, but everybody replies 2,3,5 > > seconds.. in any case I still think OpenSRS whould work on improving speeds > > of API lookups. Now a days is normal to search a name (for 5 to 8 > > extensions) and then suggest a client another say 3/4. If this takes 15/20 > > seconds... the client will probably give up. Not to say, how to do some form > > of masive lookup of say 25 names in all extensions at one time... it can go > > on for a minute or so. > > > > I understand this has to do, among other things, in the fact that the API > > (perhaps solved in the latest version) opens and closes a connection for > > each name and extension... hello... name... reply... close... hello... > > name...reply.. etc > > > > Perhaps some development should be put on speeding up this processes, > > meanwhile I understand the only way to do bulk queries at reasonable speeds > > is consulting some whois server, but the results in this case is never > > completely accurate. > >
