M
Mark
Hi...
We've tried to implement the jabber xep-0124 http tunneling extension using
the HttpListener class on the server side (basically other jabber
conversations get wrapped in an http request, and the connection gets kept
open with 1 request outstanding all the time).
We've also tried to implement a test harness in C# with buckets of async i/o
completions and callback delegates. Looking over the test harness, there are
some interesting questions I'm scratching my head about:
1) Each tester uses System.Net.WebRequest.Create (url) to initiate a contact
and the BeginGetResponse() method to asynchronously wait for the response.
Request.KeepAlive is set to false. The initial WebRequest.Create(url) takes
a long time (~ 13 seconds) to get a connection to the destination server but
subsequent message sends are generally much faster. With KeepAlive set to
false, is the framework keeping the connection open anyway? Is it keeping
some of the info cached? I'm wondering why subsequent
WebRequest.Create(url)s get the request sent so much more quickly than the
initial one.
2) As part of processing the conversation on the tester side, it reads from
the response with async completion. When there is no more to read, the
completion function parses the xml returned and loops through the data
returned. As part of processing the return data, new requests can be
initiated. It's in one of these, that things seem to get synchronous again.
There's only 1 part of the conversation that's not initiated from the client
side. Usually it's client sends A and expects response B. But in the jabber
authentication phase, client sends credentials and the server respond with
success, *then* the server asks the client a question (what protocol level is
supported). The server's question comes in the next response going to the
client.
The conversation looks something like this:
Client connect-> Server
Client <- connid Server
Client login -> Server
Client <- success Server
Client directory request -> Server
Client <- version request Server
Client <- directory listing Server (both in same http response)
Client version resp -> Server
(server has no answer to this, so it waits to timeout).
The thing I'm having trouble figuring out is that double-response. My i/o
completion callback gets both answers and processes the version request
first. This results in sending the version response - which *should* also be
asynch, but what I'm seeing is that my callback doesn't go ahead to process
the 2nd part of the packet until after the version response call times out.
It's like I'm only allowed to be processing 1 async completion callback at a
time.
Can anyone shed any light on that?
Thanks
Mark
We've tried to implement the jabber xep-0124 http tunneling extension using
the HttpListener class on the server side (basically other jabber
conversations get wrapped in an http request, and the connection gets kept
open with 1 request outstanding all the time).
We've also tried to implement a test harness in C# with buckets of async i/o
completions and callback delegates. Looking over the test harness, there are
some interesting questions I'm scratching my head about:
1) Each tester uses System.Net.WebRequest.Create (url) to initiate a contact
and the BeginGetResponse() method to asynchronously wait for the response.
Request.KeepAlive is set to false. The initial WebRequest.Create(url) takes
a long time (~ 13 seconds) to get a connection to the destination server but
subsequent message sends are generally much faster. With KeepAlive set to
false, is the framework keeping the connection open anyway? Is it keeping
some of the info cached? I'm wondering why subsequent
WebRequest.Create(url)s get the request sent so much more quickly than the
initial one.
2) As part of processing the conversation on the tester side, it reads from
the response with async completion. When there is no more to read, the
completion function parses the xml returned and loops through the data
returned. As part of processing the return data, new requests can be
initiated. It's in one of these, that things seem to get synchronous again.
There's only 1 part of the conversation that's not initiated from the client
side. Usually it's client sends A and expects response B. But in the jabber
authentication phase, client sends credentials and the server respond with
success, *then* the server asks the client a question (what protocol level is
supported). The server's question comes in the next response going to the
client.
The conversation looks something like this:
Client connect-> Server
Client <- connid Server
Client login -> Server
Client <- success Server
Client directory request -> Server
Client <- version request Server
Client <- directory listing Server (both in same http response)
Client version resp -> Server
(server has no answer to this, so it waits to timeout).
The thing I'm having trouble figuring out is that double-response. My i/o
completion callback gets both answers and processes the version request
first. This results in sending the version response - which *should* also be
asynch, but what I'm seeing is that my callback doesn't go ahead to process
the 2nd part of the packet until after the version response call times out.
It's like I'm only allowed to be processing 1 async completion callback at a
time.
Can anyone shed any light on that?
Thanks
Mark