Making HTTP 'appear' more reliable.

Dot .Net Dilemmas
I was listening to the .NET Rocks episode 'Udi Dahan Scales Web Applications!' (date 12/08/2008) and about 1/3 of the way through it they discuss something that is, what I consider, very important and seldom discussed issue regarding making HTTP 'appear' more reliable and give our users a better and more confidence building experience while using our web sites or services.
(Some of what is written below is from notes that I have taken while listening to the .NET episode so I am not claiming this to be an original idea.)

Something that I have always struggled with is, what to do when I am on a web site purchasing something and I go to make a payment by clicking the ‘Submit’ button and hey-presto; nothing happens?
I think that it has been drilled into us over the years NOT to hit that submit button again as it could mean multiple payments on our credit card. If you are like me, you simply click the little ‘X’ button at the top of the page or browser and keep an eye on your card transactions over the next month. So, how do we stop this happening when we are designing our own sites where we want to instill some customer confidence and not lose customer business?

I came across what at the early stages sounds like a pretty good and clean solution to this problem but as yet, I have not tried to implement it.

Basically HTTP is inherently unreliable and there is not much in the broader sense of the internet that we can do about this. However, there are a number of steps we can take to lessen the impact of this shortcoming.
Basically we design a retry protocol in such a way that if we send a request from the browser to the server we don’t get a satisfactory response back from the server in a reasonable time (for any action on data where we need to ensure it remains consistent), we resend the request again.
We would also need to ensure that server side code is designed in such away that, even is the request is sent any number of times, it is only processed once. One way we could do this is to tag a GUID (Globally Unique IDentifier ) onto the request. The same GUID would be also tagged onto the response and in this way, it wouldn’t matter if the first request got lost or the first response got lost we can be pretty sure that the data that was sent was received and processed. From the user’s perspective they don't see any of this as it is all under the hood. Until that point where we say ‘yeah, we got your data’, we can ensure that our service is fairly reliable on top of an fairly unreliable protocol (HTTP).

As I’m sure you can see, this sounds a very promising solution to what is, from what I can see, a pretty universal problem for any web site that has to ensure data persistence. I am going to try and implement this on some of the web applications that I use to take customer payments over and I will update my blog on how I got on and problems that I had to overcome but for now, as I am off to Uluru for the weekend, I’ll simply post this as a reminder.