I am developing a high performance HTTP messaging engine which potentially
needs to service many simultaneous requests.

My main concern with using any of the built in framework classes such as
WebClient or HttpWebrequest is that they internally use threads from the
machines thread pool which I think potentially limits scalability.

Can anyone offer advice on how best to implement a scalable HTTP messaging
engine? I know going back to basics and building a HTTP messenger upwards
from the TCP level would be the best solution but this seems like a fairly
substantial coding task. Ideally I would like to leverage something at a
little higher level.

I've done a fair bit of Googling but cannot find a definitive answer.

Any ideas, tips or advice would be gratefully received.

Clive



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4473 (20091001) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Windows Azure

"C Smith" <nomail@nomail> wrote in message
news:(E-Mail Removed)...
>I am developing a high performance HTTP messaging engine which potentially
>needs to service many simultaneous requests.
>
> My main concern with using any of the built in framework classes such as
> WebClient or HttpWebrequest is that they internally use threads from the
> machines thread pool which I think potentially limits scalability.
>
> Can anyone offer advice on how best to implement a scalable HTTP messaging
> engine? I know going back to basics and building a HTTP messenger upwards
> from the TCP level would be the best solution but this seems like a fairly
> substantial coding task. Ideally I would like to leverage something at a
> little higher level.
>
> I've done a fair bit of Googling but cannot find a definitive answer.
>
> Any ideas, tips or advice would be gratefully received.
>
> Clive
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4473 (20091001) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>