Re: Wrapping TCP communications in HTTP
- From: "Alexander Nickolov" <agnickolov@xxxxxxxx>
- Date: Mon, 5 Dec 2005 11:02:33 -0800
HTTP is a half-duplex protocol. You send, then you receive,
then you send again, etc. You can't send twice, nor receive twice.
Note this is with regard to the protocol itself, not meaning all
your data must be submitted in a single socket send...
Therefore, for full duplex communication you need two sockets.
The send socket is used to send all requests. The server simply
replies with 200 OK as soon as it receives the data, so you can
send again. The receive socket is constantly polled by the client
so the server can return any data it has. The server will normally
not respond right away if it has nothing to send. Instead, it holds
the initiative and replies when there's data. My advice was
that if you have nothing to send from the client for a long time,
you need to still periodically send an empty keep-alive message
to force any NAT routers along the way to keep your connection
alive. Similarly, the server should reply with empty keep-alive
response if it has no data to send, for the same reasons. A
minute interval for keep-alives should be pretty reasonable.
Of course, the HTTP potocol incurs significant performance hit
for interactive data because it requires the server to respond
before you can continue sending data. On higher latency wide
networks this can be quite noticeable, with very low network
utilization. You should combine small packets into larger ones
to improve performance. A complementary approach is to use
mutiple sockets in each direction and multiplex the traffic, but
you'll need to reassemble at the other end as they may come
out of order.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Mick" <Mick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:38FA521C-3B87-4C17-BF0F-7147E29BD893@xxxxxxxxxxxxxxxx
> Thanks for the reply Alexander!
>
> So, are you saying that a single HTTP tunnel (e.g. a client connecting to
> a
> server) doesn't support full-duplex (bi-directional) communications? If
> that's true, then HTTP tunneling probably won't work for us; at least not
> without completely rewriting our entire comm framework.
>
>
>
> "Alexander Nickolov" wrote:
>
>> Check out RFC 2616:
>> http://www.faqs.org/rfcs/rfc2616.html
>>
>> If your protocol is half-duplex, you can tunnel it using a single
>> persistent connection to the HTTP server. If it is full-duplex,
>> you'll need two independent connections - one for sending and
>> one for receiving (by constantly polling the server for messages).
>> Don't forget to send idle ping mesages when you have nothing
>> to send, and and don't hold the receive connection at the server
>> without response for too long. Don't forget proxies either and
>> specify "Proxy-Connection: keep-alive" as well when going through
>> a proxy.
>>
>> --
>> =====================================
>> Alexander Nickolov
>> Microsoft MVP [VC], MCSD
>> email: agnickolov@xxxxxxxx
>> MVP VC FAQ: http://www.mvps.org/vcfaq
>> =====================================
>>
>> "Mick" <Mick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:209149C0-2024-40F5-8BF0-C95384B671D7@xxxxxxxxxxxxxxxx
>> > We have a set of applications that use TCP sockets (winsock2) to
>> > communicate
>> > between machines. To communicate, a client machine establishes a TCP
>> > socket
>> > connection to a server, then sends and receives messages using our own
>> > proprietary protocol. We have developed and tested all of this and it
>> > works
>> > fine. Now, because of firewall security issues at some of our customer
>> > sites,
>> > we would like to wrap these communications in the HTTP protocol. Is it
>> > possible to do this? If so, what would be required to implement this?
>> >
>> > I know very little about HTTP, but my understanding is that HTTP
>> > communications requires that you establish a session with a server,
>> > send
>> > request messages to the server, and then wait to receive a response.
>> > Would
>> > this require us to scrap our existing socket implementation, or can we
>> > just
>> > wrap our messages in HTTP?
>> >
>> > Any advice on how to implenent this will be much appreciated. Thanks!
>> >
>>
>>
>>
.
- References:
- Re: Wrapping TCP communications in HTTP
- From: Alexander Nickolov
- Re: Wrapping TCP communications in HTTP
- Prev by Date: Re: Connection close in HTTP server
- Next by Date: Re: LSP HTTP redirecting
- Previous by thread: Re: Wrapping TCP communications in HTTP
- Next by thread: Re: Wrapping TCP communications in HTTP
- Index(es):
Relevant Pages
|
