In web 1.0 events posted from browser back to application can get scattered on multiple connections i.e. on different sockets.
This behaviour required some added extra infos and code to reorder events and process them in the original sequence.
web 2.0 is based on http 1.1 so nothing of this kind is required now?
The HTTP/1.1 server does support persistent connections, but keep in mind that it is not the only communication mechanism in place.
Regular event traffic like this:
- user takes an action
- browser sends event
- server receives event
- server processes event
- server sends response
- Browser receives response
- Browser processes response
…all goes through the normal persistent connection, as long as it stays connected.
What you can’t see from this description is that there is still a bit of asynchronousity (sp?) built in there. HTTP/1.1 requires that the responses be sent in the same order as the requests came in, so if the requests were 1, 2, 3 and request 2 takes a long time to process, request 3 has to wait too.
The asynchronous bit comes in at the very last step though… for some internal reasons, we can’t guarantee that only one update command will be sent per control, per event. Therefore, refreshing controls is done asynchronously after the event loop cycles and only once per control that needs it.
In a future version, things that are sent to the browser out-of-band will be transmitted through another Independent socket. It will be a one-way channel though… server > browser.
1 Like
Thank you.
Web 2.0 is better than 1.0.
Great.
P.S.
In my case the traffic was limited to steps 1…4