async i/o completion routines, threading question

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

.

Relevant Pages

  • Re: breaking the model
    ... > The forms data then is in the Request object. ... HTTP Request; in this case, the form POST Request from the Page. ... client and server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Resolving record with enumerated type
    ... In a CPU BFM package, ... because data goes in two directions (request from the ... from the server to the client), you'll need some way to orchestrate ...
    (comp.lang.vhdl)
  • Re: NadaNet file server coming soon...
    ... Applesoft BASIC running under ProDOS, in less than 300 lines, ... After each command is completed by the server, ... client the result code, the AUX TYPE, ... forgoes queueing (since one client can't have more than one request ...
    (comp.sys.apple2)
  • Re: Kerberos with Windows Integrated authentication
    ... behaviour if your Web server is in the client broweser's Internet zone. ... referencing it by computer name rather than FQDN), the browser will request ... Obviously, if you want to use Kerberos for authentication, you will either ...
    (microsoft.public.windows.server.security)
  • Re: Performance Issue with Runtime Image
    ... >> the client, closes the connection, then dies. ... request before even accepting the next incoming connection. ... The client program is unaffected so presumably the server is ...
    (comp.lang.smalltalk.dolphin)
Loading