Is HTTP an Async Protocol

[Bob Badger]

Hi,

Simple question (although I guess with a complicated answer). Is HTTP
an async protocol? For instance, if I send a message to a c#
webservice via http what is the protocol actually doing?

Thanks in advance
Steffan

 

[Kevin Spencer]

Simple question (although I guess with a complicated answer). Is HTTP

an async protocol?

Short answer, no.

Long answer: HTTP is a protocol. "asynch" is not relevant to protocols.
"asynch" (ansynchronous) is a term related to programming. It is a reference
to how a program performs certain types of operations. In a single-threaded
program, the program cannot execute more than one instruction at a time, as
a single thread cannot execute more than one instruction at a time.
Therefore, any instruction which takes a certain amount of time to execute
will "block" the execution of the thread until it is completed. In a
multio-threaded program, you have the option of performing operations
"asynchronously" (that is, independently of each other, wthout having to
wait).

A protocol is a standard for communication. Network protocols almost
entirely work in the same way that humans communicate. That is, a computer
sends a message to another computer, and the other computer responds to that
message. Since there are any number of reasons why a response might be
delayed, or even not occur, network applications generally use asynchronous
threads to communicate with other network resources. This way, the program
can create a thread to do the communication, and continue with other work.
When the communication thread receives a response, or times out waiting for
one, it can notify the application, via an event or callback, which can then
react to the response.

The HTTP protocol is a networking protocol. It defines a set of standards
for applications to communicate on a TCP network. This set of standards is
based upon a client-server Request/Response exchange. The client makes an
HTTP request of the HTTP server, which then responds with an HTTP response.
These requests and responses are at least partially in the form of text,
although binary data can accompany the message. The protocol itself,
however, is pure text.

For a quick and easy "crash course" on HTTP, see:

http://www.jmarshall.com/easy/http/

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Jay R. Wren]

Short answer, no.

Long answer: HTTP is a protocol. "asynch" is not relevant to protocols.
"asynch" (ansynchronous) is a term related to programming. It is a reference
to how a program performs certain types of operations. In a single-threaded
program, the program cannot execute more than one instruction at a time, as
a single thread cannot execute more than one instruction at a time.
Therefore, any instruction which takes a certain amount of time to execute
will "block" the execution of the thread until it is completed. In a
multio-threaded program, you have the option of performing operations
"asynchronously" (that is, independently of each other, wthout having to
wait).

A protocol is a standard for communication. Network protocols almost
entirely work in the same way that humans communicate. That is, a computer
sends a message to another computer, and the other computer responds to that
message. Since there are any number of reasons why a response might be
delayed, or even not occur, network applications generally use asynchronous
threads to communicate with other network resources. This way, the program
can create a thread to do the communication, and continue with other work.
When the communication thread receives a response, or times out waiting for
one, it can notify the application, via an event or callback, which can then
react to the response.

The HTTP protocol is a networking protocol. It defines a set of standards
for applications to communicate on a TCP network. This set of standards is
based upon a client-server Request/Response exchange. The client makes an
HTTP request of the HTTP server, which then responds with an HTTP response.
These requests and responses are at least partially in the form of text,
although binary data can accompany the message. The protocol itself,
however, is pure text.

For a quick and easy "crash course" on HTTP, see:

http://www.jmarshall.com/easy/http/

While still synchronous, HTTP/1.1 does support pipelining. Normally
each HTTP request is made one after the other. You can see this by
connecting (use telnet.exe to port 80) to a web server and issuing GET
commands. Using pipelining you can issue lots of commands all at once,
and get lots of response all at once. The commands can even finish out
of order and ultimately our http client libraries can act on those
commands out of order, this type of facilities helps enable our use of
asynchronous programming approaches.

See http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

Now the unknown question is: Do the various .NET Http libraries support
using pipelining? Could threads share a Http connection pool which
pipelines commands on open Http connections? Does it matter? How much
may this accelerate my use of Web Services.

Often I wish I had a job in research which would allow me to investigate
and answer these questions.

 

[Bruce Barker]

you are not quite correct. TCP/IP is an asynchronous protocol (like most
network protocols). .net api webclient give a sync and async interface to
the protocol, which may confuse you.

the difference between a synchronous and asynchronous protocol is in timing.
a synchronous protocol (like an atm switch uses), has standard time slices,
and packets are guaranteed to be delivered in that timeslice.

HTTP is actually 3 layers

network layer (IP)
transport layer (TCP/IP)
session layer (HTTP)

IP is a an asynchronous datagram layer
TCP/IP is an asynchronous reliable delivery layer, the sender get
acknowledgement that each packet was received, and the receiver get packets
delivered in transmit order.

HTTP is a session layer. it is a simple send request, receive a response
protocol. when the client sends the request, it has no idea of how long the
response will take.

when a library supplies an api to a network protocol, it can supply a
blocking or nonblocking api. this is commonly referred to as synchronous /
asynchronous (but this is not strickly true, most operating systems run all
code asynchronously, as any real-time programmer will tell you). when in
blocking mode it looks synchronous, because the next statement will not run
until the network request completes, while in nonblocking mode you do not
which code statement will be executing when the request completes.

with a nonblocking api there are two approaches, one where your code polls
for a completion status (unix i/o approach), and a asynchronous trap mode,
where a completion routine (delegate in .net terms) is called when the
request completes.

this is all different then using a seperate thread for calling a blocking
api.


-- bruce (sqlwork.com)

 

[Kevin Spencer]

Thanks for the clarification Bruce. I suppose it's a matter of how one
interprets the question, and/or the definition of "HTTP" in the context of
the question. If you say that HTTP is 3 layers, which is true in one sense,
you are including the network and transport layer, which are not
HTTP-specific. TCP/IP and IP are used by many protocols. As the poster was
asking specifically about HTTP, I made an assumption which may or may not
have been correct about what he was asking. However, after your
clarification, I'm sure he has all the information he needs.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.