On Jul 16, 7:26 am, Christian Biesinger <[email protected]> wrote: > 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/s...http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/s...http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/s... > > > 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/nsSock...http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSock... > 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
Excellent! Thanks a lot! I read through PR_Poll(), I did not know poll () system call, which is essentially the same as select(). Read and write is finally done through PR_Read() and PR_Write() on socket fd, that fd will be polled for read purpose. Sounds I have got through this.. Thanks a lot! _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
