我的脚本和hostgators托管服务，以及一些其他信息[关闭]

Question

Hi guys I have a few questions that I wanted to ask. I an using hostgators business plan hosting on a shared server and when I talked to them about limitations and such they have told me that the limit for sending emails is 500 per hour(I think but not too sure maybe 1000, but it doesn't matter.) and I think I'll be having problems when my work goes live, so I am thinking to make some kind of script(PHP) that will be monitoring the outgoing emails allow 350 emails to be sent and put the rest on hold until the hour passes and after that send another 350 and so on, and so on. And I am planing of building a update system with XML RPC for engine and communicating with remote server and if there are any updates available to start reading them and applying them to the system triggered by CRON. So that was the information I wanted to give now the questions:

1. Email monitor:
1.1 How to get the amount of emails sent?
1.2 How should I set up the CRON for it?(if i set up CRON with less than 5mins I think it will be deleted.) Or should I use alternative and what should it be?
1.3 Can someone please give me an example script?
2. XML RPC updater:
2.1 What will be the best way to make it?
2.2 What has to be the method except "Check"->"Response[true|false]"->"Read updated content"->"Write updated content"?
2.3 Is it a good idea to make such system and what will be the most secure way to make it?

Answer 1

You can always have a table in your database which sets how many e-mails have been sent on a particular day. You can use UPDATE email_count SET emails = emails + 1 WHERE date = $current_date in a PHP query ($current_date is the variable PHP has to get from the timestamp) and before sending an e-mail, check against this value using a SELECT query.

Of course, you'll need to decide what you want. Prohibit e-mail sending (I'll take a user's registration confirming e-mail as an example) if the limit is reached, or just throttle (postpone) them. If you decide to prohibit, your work is simple: if the amount is already at the limit, you just disable the registration form.

If you decide to throttle, you'll have a much complex problem requiring a much complex solution. You will need to generate the e-mails (either as their already-made text format, or just the variable contents) and store them in the database along with the To: value. You will also need accuracy and a set-up cron, so that in the next hour, you first parse the "left-behind" e-mails from the previous hour.

But what if the previous day generates so many e-mails not only that one, but the hour thereafter gets "clogged"? You need to measure and model the usage of your site and get the best example. There might be some equations out there which could help you set up a pattern of throttling. Half of the limit is reserved hourly for possible left-behind e-mails? Taking some population statistics methods in account? There are various options.

Take note that if there is CLI PHP installed on the server, cron can execute PHP scripts too. Just make sure that the cron-ran file's output is generated in a more fitting way for plaintext report files, as cron can be set to save the file's output into a file somewhere on the filesystem.

00 * * * * /usr/local/bin/php /home/john/myscript.php

---

Fetching remote updates requires you to take care to prevent any malicious data. You should try encapsulating your update information into a compressed container (gzip?) and calculate checksums on it. The method should be:

• Query the remote server
• Check difference/update on remote server
• Fetch response (if there was difference)
• Check against difference locally with some sanitizing and hashing
• Merge fetched update

If you are to set up the remote server's system too (what XML-RPC might send as reponse), I would try implementing a reliable method with enough security checks. But try to prevent premature optimization and overkilling.

However, there are also other wrappers you might use for communicating with a remote server. Take cURL as an example.