Connetu_C

As sash_oo7 said, look at a provider with a specific DDoS service if you're really concerned, but the hardware (and hugely over-provisioned capacity) is expensive so expect to pay "big bucks" for it The Staminus offer seems comprehensive, but I would suggest opting for at least the 500Kpps - gaming clients seem to get routinely targeted by DDoS (for reasons I've never understood - obviously the offended player needs to get out into the sunshine!) and we've seen amplification attacks easily in the order of 3Gbps and 500Kpps. In theory, with that level of traffic you could be looking at up to 5Mpps too - which is not pleasant even if it can be filtered easily by today's edge router hardware. Amplification attacks can be ramped up-and-up pretty easily over a short space of time, so 500Mbps / 50Kpps isn't going to get you very far with even an amateur malcontent. By contrast, if that traffic doesn't need intelligent inspection - e.g. just filtering UDP packets will solve the problem - then you really don't need any specialist protection service. I didn't know Rapidswitch (might do under IOMart I guess) or Poundhost (especially) did any DDoS protection? Relevant questions for you are: How often do attacks occur? What is their typical size and vector? Do I need specialist "intelligent" protection? How much does a window of downtime cost the business compared with the recurring cost of having ultimate levels of protection in place? Good luck

It really depends on what attack vector(s) you have in play. If the attackers are targeting your port 80/443 and are truly distributed (coming from hundreds, thousands, tens of thousands of source IPs etc.) then identifying the malicious traffic amongst genuine becomes very problematic without expensive "intelligent" gear. Also if the attack is of a size which is difficult to manage - e.g. multi-Gbps or multi-10Gbps - then some high throughput routing platforms and high capacity links are needed to mitigate. If, on the other hand, someone is using a DNS amplification attack on you (from experience, this one is recently very common) - so you've just got UDP junk coming to port 53 - and that is within a manageable size, then your ISP can filter it for you (at their discretion and level of helpfulness of course). This costs nothing except if the attack is prolonged and racks up their upstream bandwidth bills... but usually attackers give up before then. It's usually in the ISP's interests to keep the junk off their core. Unfortunately, seeing their attack is being successfully thwarted, sometimes attackers keep ramping the attack up after mitigation, which can cause the ISP (and its other customers) problems; then temporarily dropping the affected customer's service is the quickest way to restore stability across the entire network for all customers. Do you have any further data on what your attack actually consists of and its size? That will probably tell you what sort of DDoS "protection" you need. We wrote a blog post on this very topic in February describing different approaches commonly taken - I've linked to it; hopefully it won't get censored.

Do you ever call the setupdbconn() method? It doesn't look like you do... which explains why $this->dbconn is null and hence PHP tells you it is a "non-object". One of the reasons PHP's loose typing is bad - most other languages would report a "null pointer" rather than a confusing "non-object"... unless it's C/C++ in which case you get a segmentation fault and a nasty core crash. Hope that helps. Edit: you should either call $this->setupdbconn() in a constructor, or do an explicit check before you use it in the other method - something like: if(empty($this->dbconn)) $this->setupdbconn();

The comparison between companies is really a case of what you're looking for: price, technical quality of service, customer service. Rarely do you get the best of all worlds - by their very nature, the budget mass market providers have so many clients to deal with that it increases their technical drain and decreases personal service. On the flip side, if you can afford to pay more you will generally get to work with people who really take time to understand your requirements and deliver an optimal solution. All depends what you need! You'll need to check the differences between the Web and Standard editions of Windows Server and SQL Server as this alters the cost and features available to you. As I say, SQL Server Standard is very expensive.

Have you thought about a dedicated server rather than a VPS (I assume this is what "semi-dedicated" means)? You should be able to get a Windows Server with SQL Server Web Edition (SQL Standard edition is really expensive - ballpark £300/month) within your budget. It won't be shared, so will have greater performance and far larger disk space available in case you needed it later. You could set it up however you like. You won't get "unlimited bandwidth" from any host though, as it simply doesn't exist... nor is anything else in the universe without bounds - except possibly the universe itself If you want improved performance and uptime, it's best to think about what you need to be provisioned and find someone who will reliably allocate that bandwidth to you. This is basically the opposite of what you get on the "unlimited" gimmicks.

I don't think so. Isn't the reason for images not showing usually to avoid the old "embed and hit" routine - when an e-mail loads it requests the image from the target server and hence they know you've opened the e-mail? By encoding a key (or even the full e-mail address) in the image URL, it used to be used by spammers and bulk mailers to verify that addresses were real and worth sending more of their junk to. I think you can usually avoid this by embedding the images inside the e-mail (as multipart MIME). But then you can get some very large e-mails which will increase your bandwidth, their download time, and may bounce at certain mail servers.

Yes, you can use the X-Sendfile method to do that, with PHP first handling the authentication etc. Obviously if the PHP bit isn't doing something critical or amazing, then it's slowing the process down though; useful, but definitely not a replacement for the Web server serving static resources directly.

The short answer to this is "no". Stand back for a minute and think about how you are going to do this: you will probably want to use an <img src="..." /> tag in your HTML. The src attribute has to be a URL of a publicly accessible resource - i.e. it is impossible to give the user access to the image without it having a URL it can be found at! You're basically wanting a resource which needs to be accessible, not to be accessible... errr... see the problem? Perhaps you should look at authentication/authorisation - so that the image always exists at the URL, but access is denied if the user is not logged in? Placing outside the Web root will ensure the image is never available via your Web server - you would never be able to access it through a URL without using a controller script to fetch the file from disk and present it at another URL (this is highly inefficient, as the file has to be read from disk into RAM, using CPU, and then out to network - Web servers tend to serve static content using sendfile or similar to copy directly from disk to network without all the intermediate processing). Possible solution: If you don't want to use authorisation, then off the top of my head one solution is to use a PHP controller which is used to fetch the images from disk. Each time you need an image, ask the controller to generate a one-time secret key which maps to an image on disk. Then use the secret key as the argument to your controller in the img src URL generated into the HTML page. The controller will return the image on the first request for the key, then destroy the key-image mapping. So if it were called for a second time, the key would not be found and it would return a 404. BUT this is useless in practise to protect an image from theft as anyone can still download to their hard drive if they know their way around browsers, caches and various simple HTTP tools. Not sure what exactly you're trying to achieve, but the general rule is that if you give any access for something to somebody, then they can always steal it by one means or another! The only way to have complete security is to prevent anyone ever looking at something - which usually defeats the entire point!

For low volumes, it'll be easiest if you use a third party payment provider like PayPal, MoneyBookers etc. If you go down the road of doing this more in-house (lower cost per transaction), there are still a number of solutions. At a minimum you will need a Merchant Account with a UK provider (this is not the same as a commercial/business bank account) - this is the most difficult part as you may be declined due to risk. After you have a Merchant Account (or before setting it up), talk to several merchant payment service providers. These providers will collect the details on your behalf, via the merchant account, the latter who will (after a few days) then deposit the funds in your UK bank account. Solutions with a payment service provider range from them hosting everything (much like PayPal, but depending on transaction volume with lower fees), to you hosting only an SSL payment page, to you hosting everything and only passing them API calls with transaction details. Be aware that as you take more responsibility on yourself, you will need to become more stringent with PCI compliance - the industry standard for ensuring security of card acceptance. If you are doing any of the payment processing/hosting yourself, at a minimum you would need to complete a self-assessment questionnaire and pay for quarterly network scans. In most cases it is simplest to either use a complete outsourced solution like PayPal, or to use a merchant provider's fully hosted solution, unless you require additional functionality not provided by either of those approaches.

I'll assume you either have login credentials to the server and/or the ability to create Web-facing dynamic content (e.g. PHP or ASP scripts), otherwise this is never going to happen. So... If you only want to list the files and not retrieve them, and your remote server is Linux based, you can use a remote SSH command execution - e.g. using the PHP SSH2 extension. You can execute "ls <path>" for example to get a list of filenames (only) in the <path> directory. Other variations including file sizes, owners, permissions etc. are all available with various ls options. Alternatively, if the remote server is a web server, why not expose on that a directory listing which you can retrieve via HTTP -- e.g. using PHP cURL. Process the returned HTTP content and send that to your users.

You say "in order to Deny Access to all directory" - just to double check, you do know that -Indexes only stops directory listings and not access to the directories (assuming the visitor knows the exact path to a resource). Create a .htaccess with Options -Indexes in the directory where you don't want the listing to occur. In general, .htaccess settings will apply to the current directory and everything it contains (and their contents etc.).

This might sound obvious, but the way to make them invisible is simply (1) not to link to them anywhere; (2) ensure directory listings are disabled (check your Web server configuration, or your hosting control panel if using one). Then search engines (and users) will have no way of knowing those directories exist unless they already know the path.

We use this company for sending automated SMS messages (from our network/server monitoring system): http://intellisms.co.uk/ They do an HTTP API with provided example client code in PHP, Java, .Net (or you can easily write your own from scratch). In two years, we've had no problems with their service at all.

Within reason, yes. Sensible and obvious optimisations can be made as you go - and spotting those comes with experience more than anything. If a section of code is taking a long time to process in development, then definitely correct it. But efforts are best placed in further development than worrying about milliseconds here and there. Compiling into C++ is unnecessary unless you are running a high traffic site. PHP isn't actually that bad. As I said, our website runs code which I imagine is an order of magnitude more complex than yours, we use the standard PHP interpreter without opcode caching, and with no C++ compilation, and it's taking ~200ms to process the homepage. That's fine - with the appropriate image and CSS optimisations, the whole page loads in under a second. We also recently rewrote an application from Java Enterprise (a compiled in-memory language which is nearly as fast as C++) into a PHP framework. On average, it executes at the same speed as the Java application. For maybe 10ms of additional speed, are we going to worry about writing everything in C++ (a maintenance nightmare) compared to how easy PHP is to build and maintain? Nope. The fact you are experiencing long delays with PHP is not a fundamental problem with PHP itself - it's something to do with your server, connection (have you tried timing the PHP on localhost?) or your PHP code. Your code looks simple too (far simpler than most of ours does), suggesting either server configuration or connection is your issue.

Apologies if I've missed something, but you're basically saying that your page is loading via the PHP in a reasonable time on a fixed line but taking a long time on a mobile? Whatever device you use to access your server makes NO difference to the time PHP will take to process and deliver that page - that's purely down to server hardware and software optimisations. I ran this test: http://tools.pingdom.com/fpt/?url=mulgrewenterprises.co.uk Results shifted between good (200ms for the HTML) and slow (1s for the HTML). This might be your Internet connection (you're not running this site in a proper data centre are you?), or your hosting platform. Our site is PHP based, results are fine (average 250ms for the HTML): http://tools.pingdom.com/fpt/?url=www.connetu.com If it's taking a long time to load on your mobile, this is either a mobile network or client device bottleneck and has nothing to do with PHP. I find a lot of mobile Internet traffic takes a while to connect even if the downloading and page rendering is reasonably fast. There's a saying: "premature optimisation is the root of all evil" in programming. Why? Because it's much better to use a language which is quick to program in (like PHP) and gets results, and then worry about where the bottlenecks are and correct them (you'll also have a much better idea where the important optimisations are needed whilst experiencing significant traffic). Until such a time that you are pushing millions of pages per hour, a small added delay will make no difference to the end user experience and will just waste a lot of your time trying to "fix". It simply doesn't make sense.

"onclick" validation implies you are using JavaScript - bots (like any non-JScript client) don't execute your JavaScript, so it all goes through successfully. You should implement server-side validation if you want to prevent this, and add JavaScript as a nicer alternative for those clients who support it.

Can you try the code on another system without Wordpress installed (even a local Apache install on your workstation)? At least you'll know whether it's the rewrite itself or something else in Wordpress conflicting. You could also do a blanket redirect from .com to .co.uk - this is beneficial for SEO besides (as some search engines penalise "duplicate content" on different domains). If that worked as the first rule in the script, then your feed would also redirect. Not sure how you do this with the feed:// protocol - might need another RewriteCond to catch this case.

It isn't working because of a conflict with your Wordpress rewrites. You could work out exactly where this is happening and put some exclusions in, or you could just move the code fragment we wrote to place it before every other Wordpress rewrite (possibly in the server configuration itself if there are any rewrites in there), so it gets done first. What is likely happening is that another rule is executing with an [L] and therefore the "Feed Redirect" block is never even processed.

It worked for me on a test server (using a different domain obviously), so I don't think there's anything wrong with the .htaccess snippet I supplied above. You should check your server error logs (if you have access to them) as they may hint as to why it's not working. Other things to check are the main server configuration - is mod_rewrite enabled and does the config allow you to use these directives in .htaccess files? Does your Web server have permissions to read the .htaccess file - e.g. are any other directives working (permission errors should also be shown in your error logs)? Are you using any other rewrite directives (explicitly or implicitly, for example provided by a CMS) which may conflict?

I forgot that if you put the rewrite in .htaccess in a directory, rather than in the server config file, you don't put the leading directory path on paths - in your case this is just the /. So you need: RewriteEngine on RewriteCond %{HTTP_HOST} ^www.voltronik.com$ RewriteRule ^feed/(.*)$ feed://www.voltronik.co.uk/feed/$1 [R=301,L] Does that work now?

Where are you putting the .htaccess file? In what directory/path?

Client side redirects (using HTML) should be avoided for two reasons: (1) they rely on the client to understand the HTML in order to do the redirect; (2) they involve serving an unnecessary amount of header and body data in the HTTP response. An HTTP redirect response is better - either by server-side header manipulation in scripts (e.g. in PHP) or by server configuration... it doesn't really matter. Of course, if you're serving a resource from a static file, the script method doesn't apply and you are forced to use server configuration (which in my opinion is a "cleaner" solution in many cases anyway, particularly if a resource has moved).

A RewriteRule matches whole paths, and not hosts or protocols (which can be matched by the appropriate RewriteCond but not doing the scheme and host in one go, as you have done). You therefore need something like: RewriteEngine on RewriteCond %{HTTP_HOST} ^www.voltronik.com$ RewriteRule ^/feed/(.*)$ feed://www.voltronik.co.uk/feed/$1 [R=301,L] Does that work for you?

Yes, please do let us know how you get on. I'm particularly intrigued that their marketing promotes unlimited (no time limits) access to managed support, at a budget VPS price. Since expert skills are expensive, I'm curious how they can cope with demand or will be able to scale out on the existing pricing model. Be interesting to know how you find their reliability and support.

In my opinion, it depends. Example: we run most of our internal services virtualised (in a "cloud" as it were). Each VM is assigned its own 2GHz+ core and at least 1GB RAM. Aside from CPU cache misses, this works very well - better guaranteed resources for each application than on a shared server, and we ensure enough is available. We benefit from consolidation of hardware, power, wasted CPU cycles and RAM segments, improving efficiency. In addition, files are cached by Linux in RAM - so it doesn't matter that the underlying hard drives are shared between VMs, as most static resources are being buffered in the VM RAM anyway, so are fast (much faster than dedicated hard drive in fact). Intensive disk I/O (usually very busy databases) is where VMs will bottleneck - for everything else they're usually as good, if not better (due to superior hardware), than a budget dedicated solution. Obviously if you're not paying for larger RAM allocations, that will decrease performance - RAM is basically the most important factor for a VPS with decent performance. It's all highly dependent. To say VMs will never be speedy is relative as technology progresses: today's VMs (done right) are superior to the dedicated servers of 5 years ago.