Hi ab,

On Thu, Jul 16, 2009 at 5:27 AM, ab bc<[email protected]> wrote:
> I see that, usually, socket traffic is managed by  nsISocketTransport,
> but http/src/README says connection will call transport's AsyncWrite
> and AsyncRead, I don't understand what are these two methods implying.
> Because non of them are defined actually in the code, perhaps the
> README is too old.

yeah, that's outdated. These days, HTTP uses nsIAsync{In,Out}putstream
to wait until the socket is readable/writable, and then writes the
request body to the server.

See for the writing case for HTTP:
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/src/nsHttpConnection.cpp#785
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/src/nsHttpConnection.cpp#573
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/src/nsHttpTransaction.cpp#462

> What I figure out, the outgoing traffic could be done directly
> synchronously with
> outStream->Write, or asynchronously, with outStream->AsyncWait, then
> caller's OnSocketWritable() will be called to write the data to
> network. Am I right?

Essentially true, although the details are not quite so simple.

> The incoming traffic, usually is done by asynchronously, with a pump,
> first construct a pump through NS_NewInputStreamPump, then the
> listeners will be notified with input stream has some data.

Varies, but yeah, there's often a pump involved.

> Seems there are several layers here, seems the reading is a big
> problem to me, I can not know how asynchronous reading is happening? I
> know nsISocketTransportService is doing a poll, on its owned sockets,
> seems after that, nsISocketTransport is going to be notified by its
> OnSocketReady(), but who is putting data into the input socket?   The
> socket provider?   At least, there should be someone, do a recv()  for
> that input socket, and change some state in NSPR, to make that socket
> noticeable as readable for the Poll() in transport service?

Not really. PR_Poll normally maps to the poll() system call, or in
case of windows to select(). As that's implemented by the operating
system, the function can just check if data is available in the OS
buffers, no need to call recv.

> I wish someone can show me a good graph of the network asynchronous
> reading path, thanks a lot!

So once PR_Poll indicates that data is readable, the socket input
stream gets notified that data is available:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#1519
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#231
and if there was an asyncWatit caller, that will be notified.

In the normal case (l.e. the socket input stream was opened without
the OPEN_UNBUFFERED flag), this data is then copied into a pipe which
is where the data actually gets read from. In any case, if the caller
uses an nsIInputStreamPump, that uses asyncWait to get notified about
new data in the socket and passes it on to its stream listener.

I hope this helps,
-christian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network

Reply via email to