By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,974 Members | 1,834 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,974 IT Pros & Developers. It's quick & easy.

custom handlers & dumb question

P: n/a
Hi,

Apologies if this isn't the correct forum. I am writing a communication
solution (actually on the Compact Framework) based on HttpWebRequests
hooking up with custom handlers on the server side. My dumb question is
this: how reliable is http? For example if I use PUT and call GetResponse on
my request object with no problem, can I guarantee that every byte of my
file will always arrive at the web server?

I know this sounds stupid but I just want to be sure, obviously I could
append the byte count to the end of the file and have my custom handler
check it against the incoming byte stream and maybe respond with an ACK or
NACK. My thinking is that this is all handled at TCP/IP level and http is
100% reliable but I just wanted reassurance!

Thanks
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
Nov 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
tcp unlike udp is a reliable transport. this means every packet sent get an
acknowledgement, so if you can trust the status of a send (no need for own
ACK/NAK). with http, you should also check the return status, to know if the
PUT worked.

tcp has limited retry logic, so a PUT can often fail, but your packet send
will fail.

note: you can get false failures, where the put was actually sucessfully
processed by the server, but the client did not get an acknowledgment back
(iis buffering may prevent the server code from seeing this condition).
-- bruce (sqlwork.com)
"Stelrad Doulton" <___@____.com> wrote in message
news:%v*****************@newsfe3-gui.ntli.net...
| Hi,
|
|
|
| Apologies if this isn't the correct forum. I am writing a communication
| solution (actually on the Compact Framework) based on HttpWebRequests
| hooking up with custom handlers on the server side. My dumb question is
| this: how reliable is http? For example if I use PUT and call GetResponse
on
| my request object with no problem, can I guarantee that every byte of my
| file will always arrive at the web server?
|
|
|
| I know this sounds stupid but I just want to be sure, obviously I could
| append the byte count to the end of the file and have my custom handler
| check it against the incoming byte stream and maybe respond with an ACK or
| NACK. My thinking is that this is all handled at TCP/IP level and http is
| 100% reliable but I just wanted reassurance!
|
|
|
| Thanks
|
|
| ---
| Outgoing mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
|
|
Nov 19 '05 #2

P: n/a
Cheers Bruce,

That was exactly what I was after!

I have about 2 days experience with IIS, is there any configuration I can do
reduce the false failues, or should I just be prepared to handle resubmits
as gracefully as possible?

"bruce barker" <no***********@safeco.com> wrote in message
news:uZ**************@TK2MSFTNGP10.phx.gbl...
tcp unlike udp is a reliable transport. this means every packet sent get
an
acknowledgement, so if you can trust the status of a send (no need for own
ACK/NAK). with http, you should also check the return status, to know if
the
PUT worked.

tcp has limited retry logic, so a PUT can often fail, but your packet send
will fail.

note: you can get false failures, where the put was actually sucessfully
processed by the server, but the client did not get an acknowledgment back
(iis buffering may prevent the server code from seeing this condition).
-- bruce (sqlwork.com)
"Stelrad Doulton" <___@____.com> wrote in message
news:%v*****************@newsfe3-gui.ntli.net...
| Hi,
|
|
|
| Apologies if this isn't the correct forum. I am writing a communication
| solution (actually on the Compact Framework) based on HttpWebRequests
| hooking up with custom handlers on the server side. My dumb question is
| this: how reliable is http? For example if I use PUT and call
GetResponse
on
| my request object with no problem, can I guarantee that every byte of my
| file will always arrive at the web server?
|
|
|
| I know this sounds stupid but I just want to be sure, obviously I could
| append the byte count to the end of the file and have my custom handler
| check it against the incoming byte stream and maybe respond with an ACK
or
| NACK. My thinking is that this is all handled at TCP/IP level and http
is
| 100% reliable but I just wanted reassurance!
|
|
|
| Thanks
|
|
| ---
| Outgoing mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
|
|

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
Nov 19 '05 #3

P: n/a
you have to handle resubmits. i usually use a transaction guid.

-- bruce (sqlwork.com)

"Stelrad Doulton" <___@____.com> wrote in message
news:eT*****************@newsfe3-gui.ntli.net...
| Cheers Bruce,
|
| That was exactly what I was after!
|
| I have about 2 days experience with IIS, is there any configuration I can
do
| reduce the false failues, or should I just be prepared to handle resubmits
| as gracefully as possible?
|
| "bruce barker" <no***********@safeco.com> wrote in message
| news:uZ**************@TK2MSFTNGP10.phx.gbl...
| > tcp unlike udp is a reliable transport. this means every packet sent get
| > an
| > acknowledgement, so if you can trust the status of a send (no need for
own
| > ACK/NAK). with http, you should also check the return status, to know if
| > the
| > PUT worked.
| >
| > tcp has limited retry logic, so a PUT can often fail, but your packet
send
| > will fail.
| >
| > note: you can get false failures, where the put was actually sucessfully
| > processed by the server, but the client did not get an acknowledgment
back
| > (iis buffering may prevent the server code from seeing this condition).
| >
| >
| > -- bruce (sqlwork.com)
| >
| >
| > "Stelrad Doulton" <___@____.com> wrote in message
| > news:%v*****************@newsfe3-gui.ntli.net...
| > | Hi,
| > |
| > |
| > |
| > | Apologies if this isn't the correct forum. I am writing a
communication
| > | solution (actually on the Compact Framework) based on HttpWebRequests
| > | hooking up with custom handlers on the server side. My dumb question
is
| > | this: how reliable is http? For example if I use PUT and call
| > GetResponse
| > on
| > | my request object with no problem, can I guarantee that every byte of
my
| > | file will always arrive at the web server?
| > |
| > |
| > |
| > | I know this sounds stupid but I just want to be sure, obviously I
could
| > | append the byte count to the end of the file and have my custom
handler
| > | check it against the incoming byte stream and maybe respond with an
ACK
| > or
| > | NACK. My thinking is that this is all handled at TCP/IP level and http
| > is
| > | 100% reliable but I just wanted reassurance!
| > |
| > |
| > |
| > | Thanks
| > |
| > |
| > | ---
| > | Outgoing mail is certified Virus Free.
| > | Checked by AVG anti-virus system (http://www.grisoft.com).
| > | Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
| > |
| > |
| >
| >
|
|
| ---
| Outgoing mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
|
|
Nov 19 '05 #4

P: n/a
Never heard of this strategy!! Is there a sample somewhere you could point
me to?

Cheers

"bruce barker" <no***********@safeco.com> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl...
you have to handle resubmits. i usually use a transaction guid.

-- bruce (sqlwork.com)

"Stelrad Doulton" <___@____.com> wrote in message
news:eT*****************@newsfe3-gui.ntli.net...
| Cheers Bruce,
|
| That was exactly what I was after!
|
| I have about 2 days experience with IIS, is there any configuration I
can
do
| reduce the false failues, or should I just be prepared to handle
resubmits
| as gracefully as possible?
|
| "bruce barker" <no***********@safeco.com> wrote in message
| news:uZ**************@TK2MSFTNGP10.phx.gbl...
| > tcp unlike udp is a reliable transport. this means every packet sent
get
| > an
| > acknowledgement, so if you can trust the status of a send (no need for
own
| > ACK/NAK). with http, you should also check the return status, to know
if
| > the
| > PUT worked.
| >
| > tcp has limited retry logic, so a PUT can often fail, but your packet
send
| > will fail.
| >
| > note: you can get false failures, where the put was actually
sucessfully
| > processed by the server, but the client did not get an acknowledgment
back
| > (iis buffering may prevent the server code from seeing this
condition).
| >
| >
| > -- bruce (sqlwork.com)
| >
| >
| > "Stelrad Doulton" <___@____.com> wrote in message
| > news:%v*****************@newsfe3-gui.ntli.net...
| > | Hi,
| > |
| > |
| > |
| > | Apologies if this isn't the correct forum. I am writing a
communication
| > | solution (actually on the Compact Framework) based on
HttpWebRequests
| > | hooking up with custom handlers on the server side. My dumb question
is
| > | this: how reliable is http? For example if I use PUT and call
| > GetResponse
| > on
| > | my request object with no problem, can I guarantee that every byte
of
my
| > | file will always arrive at the web server?
| > |
| > |
| > |
| > | I know this sounds stupid but I just want to be sure, obviously I
could
| > | append the byte count to the end of the file and have my custom
handler
| > | check it against the incoming byte stream and maybe respond with an
ACK
| > or
| > | NACK. My thinking is that this is all handled at TCP/IP level and
http
| > is
| > | 100% reliable but I just wanted reassurance!
| > |
| > |
| > |
| > | Thanks
| > |
| > |
| > | ---
| > | Outgoing mail is certified Virus Free.
| > | Checked by AVG anti-virus system (http://www.grisoft.com).
| > | Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
| > |
| > |
| >
| >
|
|
| ---
| Outgoing mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
|
|

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
Nov 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.