Upcoming Release of Overhauled Delivery Script Code

3 posts / 0 new
Last post
puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

Hello,

This is just a quick note to let ShrinkTheWeb users know that I have been working on re-factoring all of the delivery script code (xino/xian) over the past 45 days and am planning to deploy it in the next few days. I will update this thread and also our Twitter feed, ShrinkTheWeb's Twitter feed, when I am ready to proceed. I won't give much notice, because there won't be any downtime from the deployment, provided all goes smoothly, and I will be closely monitoring for any issues that arise.

This overhaul adds much better (and more accurate) logging, better security, some minor improvements, and increased performance... along with a number of fixes for obscure bugs that have gone unreported for years.

No change is required as a result of this update. All existing code should continue to work as before. I am thoroughly testing these scripts and believe that the transition will be seamless -even fixing some unnoticed or unreported potential issues.

If you are dying to know, you can read more about the epic (hehe) battles I've been facing:

The (Boring) Thrills of a Programmer

Lastly, the only noticeable changes in the behavior of these scripts is that a number of malicious or badly misconfigured types of requests will simply be dropped now. So, we will only give a very brief, related text response or no response at all. This should only affect those who are trying to steal service, which seems to be a lot of people these days.

I hope your 2016 is off to a great start thus far!

Cheers,

Brandon

puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

Update: I deployed the new delivery scripts at 07:00 GMT -0500 today, 02/21/2016. The transition went off without a hitch and the system is running very smoothly. There is a lot more data being reported now, performance is improved, and the "Image Retrieval Error" hasn't shown up 10 hours since (usually happens once an hour or every other hour). So I am hopeful that the "fix" I put in for that is properly handling the final reason for those errors. Time will tell. If so, then it looks like the system is running at 100% success rate. I won't get my hopes up too high, but things look promising! Smile

puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

I almost forgot: I wanted to document that this release also introduces a slight change in behavior for those who are on shared hosting where another Free account has already reserved the server's public IP. In those cases, the code now checks the original reserving account to see if it is inactive or banned. If it is, then the referrer IP is transparently moved from the original account into the requesting account and the request is honored.

No change is required for this to work. It all happens behind-the-scenes. The only evidence that this has occurred is that an entry will be put in the logs for the requesting account that shows "Referrer added to Allowed Referrers" and will show the IP moved. This will help alleviate the headache of having to open a support ticket asking for us to check and move the IP manually.

Some background: Unfortunately, the few ruined it for the many and forced us to ban shared IPs across Free accounts, but this new behavior will hopefully help out some users. Since hosting companies have been slashing costs by migrating to mega-servers that oversell thousands or tens of thousands of accounts on a single IP, it has been a growing problem of Free users running into not being able to use our "Advanced Method" because their server's IP is reserved.

I have, so far, been unable to come up with a better solution to avoid malicious users from stealing service to the point of putting me out of business. I had considered Google's method of allowing public access, up to 25,000 accesses per IP per day, but with our volume, that would lead to serious headaches. Once enough users from the same server accessed the service, ALL requests for that day would be denied. That's no good. Also, a malicious user on a server could eat up ALL of that days requests in a short time and leave everyone else on that server without service; also no good.

Do you have an elegant solution? I'd love to hear ideas!

ShrinkTheWeb® (About STW) is another innovation by Neosys Consulting
Contact Us | PagePix Benefits | Learn More | STW Forums | Our Partners | Privacy Policy | Terms of Use

Announcing Javvy, the best crypto exchange and wallet solution (coming soon!)

©2018 ShrinkTheWeb. All rights reserved. ShrinkTheWeb is a registered trademark of ShrinkTheWeb.