custom handlers & dumb question

[Stelrad Doulton]

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

[bruce barker]

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
|
|

[Stelrad Doulton]

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

[bruce barker]

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
|
|

[Stelrad Doulton]

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