Hi Zeljko,
I thought that transactions in the batch environment were also subject to
run-rate limits and punitive action. Has that changed?
thx,
m2
> -----Original Message-----
> From: owner-discuss-list@opensrs.org [mailto:owner-discuss-
> list@opensrs.org] On Behalf Of Zeljko Dimic
> Sent: Thursday, June 03, 2004 2:33 PM
> To: discuss-list@opensrs.com
> Subject: RE: Snapback
>
> Hi Nick,
> if you're interested to go after expired domains, I'd like to give you few
> pointers:
>
> - generic whois is not reliable indicator if domain is available or not,
> as
> it's not real-time
> - there is a very competitive industry built around 'speculative' names,
> and
> it's not easy to crack into it
> - and most importantly, any sort of high-volume, repetitive activity
> should
> not be executed against our regular production environment. Both Tucows
> and
> registry may construe it as abuse, and we may temporarily limit your
> access
> to our system. Rather, you should connect to batch.opensrs.net - all the
> ports and functionality are equivalent to regular prod. environment.
> However, batch environment uses special pool of connections to the
> registry,
> that is more appropriate for this type of activities.
>
> Regards,
> ------------------------------------
> Zeljko Dimic
> Technical Product Manager
> zdimic@tucows.com
> Tucows Inc.
> 96 Mowat Avenue
> Toronto, ON, M6K 3M1
> Canada
> tel: 416.535.0123 x 1256
> fax: 416.531.5584
> ------------------------------------
>
> -----Original Message-----
> From: owner-discuss-list@opensrs.org
> [mailto:owner-discuss-list@opensrs.org]On Behalf Of Nick Wilsdon
> Sent: Thursday, June 03, 2004 6:40 AM
> To: 'Gordon Hudson'; discuss-list@opensrs.com
> Subject: RE: Snapback
>
>
> Hi Gordon,
>
> Yes, this is my exact concern about any system of this type, the load on
> the retry operation and how that would affect the OpenSRS system. It
> does not seem a difficult function to put in so I was wondering why the
> developers had not.
>
> However if the auto-retry mechanism could be triggered by a whois
> search, to start retrying when the domain was 'free' and to stop when it
> was again 'taken' (either by ourselves or someone else) then the time
> could be greatly controlled.
>
> I would like to investigate this further - can anyone else see any
> reasons for not doing so or know more about the load/limits of the
> connections? Also, if we developed a system of this kind would it be of
> interest to make it a GPL distribution to the community?
>
> Best,
>
> Nick
>
> Managing Director
> e3internet
> http://www.e3internet.com
>
>
> ----- Original Message -----
> From: "Nick Wilsdon" <n.wilsdon@e3internet.com>
> To: <discuss-list@opensrs.com>
> Sent: Wednesday, June 02, 2004 8:33 AM
> Subject: RE: Snapback
>
>
> > Hi,
> >
> > >From examining this further - it really comes down to auto-retrying
> the
> > pending domain order doesn't it? We actually had this one domain in
> > question in the pending order queue but the domain was still
> technically
> > not available so the order had not gone through. I was sitting there
> > manually retrying the order as the time came near to the release but
> > someone with a system in place got it before me.
> >
> > So is there a way to enable the domain request to be reattempted
> > automatically when queued?
>
> I don't believe so but you could write a script that did it.
> However, I seem to remember people getting into trouble for doing this
> because it tied up too many connections to Verisign.
> That may have changed.
>
> Regards
>
> Gordon Hudson
> Hostroute.com Ltd
> www.hostroute.net
>
>
>
>
> ------------------------------------------------
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:57 EDT