Symbian OS Communications (779884), страница 73
Текст из файла (страница 73)
The round trip time to a server on theInternet over an ADSL connection is about 33 ms. Over a 3G GPRSconnection, this rises to 184 ms. Over a 2.5G GPRS connection, the timeis 405 ms. Setting up a TCP connection requires three packets before anydata can be transferred, but due to the protocol design, the extra costincurred is actually just over two packets worth of time, or one roundtrip. Therefore minimizing the number of times we have to bear this costoffers potentially big gains. Imagine we had a web page with 10 smallimages on it, all from the same server, and that we can use the samepersistent connection for all of them2 . In this case, we’ve saved ourselves297 ms on the ADSL line, but a massive 1656 ms over 3G and an evenbigger 3645 ms over 2.5G.Pipelining can have similar benefits.
Instead of leaving the connectionidle in one direction whilst we wait for a response, we can send severalrequests at once. To calculate the benefits, we need some bandwidthfigures for the different technologies. For ADSL, we see about 373 kb/sfrom servers on the Internet; for 3G GPRS we see about 44 kb/s; and for2.5G GPRS we see about 6 kb/s.To work out the benefit of pipelining, we’re going to assume that therequest is about 632 bytes. However, we’re going to say that each of those10 images that are coming back is about 6 kb on average.
This gives usthe following figures for the total time to download all the images:As you can see from the figures above, with both persistent connectionsand pipelining on, it can be possible by correctly setting the followingsession properties and connecting to a server that supports these features,to achieve a better performance in cases where all requests are independent and to the same server. Obviously as more servers are involved, oras some requests depend on the results of previous ones (as would beTable 11.2 A rough guide to performance using persistent connections andpipelining (times in ms)2.5G GPRS3G GPRS‘8 Mb/s’ ADSLNo persistentconnectionsor pipeliningPersistentconnectionPersistentconnectionand pipelining191201506010506518033403828565161962This isn’t necessarily the case – the server administrator can set an upper bound on howmany requests can be made over a single socket connection before the server disconnects,however this number is typically kept quite high (in the hundreds) to improve performancefor all clients, not just mobile ones.HTTP CONNECTION CONFIGURATION359the case when downloading the web page itself, rather than the imagescontained on it) then the performance gains from these features will notbe as great.
Similarly, in lower latency and higher bandwidth networksthe benefits are less pronounced – hence the inclusion of ADSL figureshere as an example. WLAN networks should give figures of a similar orderof magnitude to ADSL, especially in cases where ADSL is providing thebackhaul for the WLAN connection! Certainly in our testing the networklatency only went up by a few milliseconds when using WLAN ratherthan a direct cable connection.Here is the list of the session properties that can benefit from tuningfor your application, and the networks and servers it works with:• EMaxNumTransportHandlers – maximum allowed number ofsocket connections.
Multiple socket connections can be opened eitherto different hosts, or the same host. It depends on how many transactions have been submitted by the client. By default the maximumnumber of connections is four. What is optimal depends on theusage of an application, especially the number of servers to which itconnects.• HTTP::EHttpPipelining – in an HTTP session, application cansend multiple requests without waiting for a response.
The HTTPframework has a pipelining property, which by default is on. Somultiple requests sent to a particular host will be pipelined downa single socket connection. Note that there are some HTTP serverimplementations, or particular versions of those implementations, thathave problems with pipelining – therefore extensive testing with theservers with which you expect to interact is strongly recommended.• HTTP::EMaxNumTransactionsToPipeline – themaximumnumber of transactions allowed to be pipelined on a particularconnection.
By default there is no limit.11.11.2 AuthenticationBoth basic and digest authentication are supported. A client applicationneeds to add the authentication filter. To do this the client must implementthe interface MHTTPAuthenticationCallback:class MHTTPAuthenticationCallback• {public:• virtual TBool GetCredentialsL(const TUriC8& aURI, RString aRealm,RStringF aAuthenticationType,RString& aUsername, RString& aPassword) = 0;• inline void InstallAuthenticationL(RHTTPSession aSession);• };360HTTPCalling InstallAuthenticationL() will add the authenticationfilter in the filter queue.When a 401 response is received from the server the authenticationfilter will call GetCredentials(). The implementation of this shouldreturn the username/password information expected – a simple implementation with hard coded name and password is show in Example 11.7.TBool GetCredentialsL(const TUriC8& /*aURI*/, RString aRealm, RStringF/*aAuthenticationType*/, RString& aUsername, RString& aPassword){_LIT8(KUsername, "testName");_LIT8(KPassword, "changeMe");RStringPool stringPool = aRealm.Pool();aUsername = stringPool.OpenStringL(KUsername);aPassword = stringPool.OpenStringL(KPassword);return ETrue;}Example 11.7A simple implementation of GetCredentials()11.11.3 MultihomingAs discussed in Chapter 6, Symbian OS supports multiple, simultaneous, independent network connections, which are managed using theRConnection API.
When opening a socket, it is associated with theRConnection that is passed into the Open() call. If no connection ispassed in when the sockets are opened, the HTTP framework will triggerthe creation of the device-wide default network connection, according tothe settings in CommsDat, upon the submission of the first transaction.Some client applications may wish to use a network connection otherthan the default one – for example, they may provide a setting to allow theuser to specify that a certain connection should always be used.
To get theframework to use this connection, you need to create both an RSocketServ and an RConnection, then call RConnection::Start()with the desired IAP (see Chapter 6 for more details on this). After startingan HTTP session (but before submitting any transactions) the followingsession properties need to be set:• HTTP::EHttpSocketServ – value is the RSocketServ handle• HTTP::EHttpSocketConnection – value is the address of theRConnection objectThe RConnection object must not be a local variable and must beguaranteed to outlive the HTTP session.FILTERS361Once set, the session will use the supplied objects when openingall the sockets it uses. The client remains the owner of these objects.Therefore the framework will not restart the RConnection if it is disconnected.
An error code of KErrNotReady is a good indication that thenetwork connection has gone down. The client should monitor progressvalues from the RConnection to check for the connection going down,and if so restart the connection and resubmit the failed transaction(s).Again, chapter 6 has more details on the progress notifications feature ofRConnection.If the framework is using the default network connection, then theRSocketServ and RConnnection used to open all the sockets areowned by the framework.
It will deal with any idle time outs or disconnections that occur on the network connection.The client can monitor the network connection used by the frameworkif it so desires. The RSocketServ and RConnection can be obtainedfrom the connection properties mentioned above. Clients must respectthat the framework owns these objects and therefore their lifetime doesnot extend beyond the closure of the session.11.12Platform SecurityHTTP is a plug-in framework that runs in the client’s thread. Any clientusing the framework will need the NetworkServices capability in orderto start network connections for the HTTP stack to use, or to allow theHTTP stack to start a connection automatically when it tries to access thenetwork.11.13FiltersFilters are plug-in components which allow for customization of theHTTP framework’s behavior. They allow clients to add functionality tothe framework in an easy and seamless manner.
They are concernedwith interactions based upon the type and form of transaction data. Thetransaction travels in two directions through the chain of filters:• Down: a request sent from the client application, via each filter inturn, to the protocol handler.• Up: a response from the protocol handler, via each filter in turn, tothe client application.Data can be consumed, processed and/or modified by filters anywherebetween the client application and the protocol handler. After a session362HTTPhas been created, the set of filters used cannot be changed during itslifetime.Once a transaction has been submitted, an outgoing ESubmit eventwill be sent through the framework. Any filters that have registered forthis event can then query and/or modify the transaction before it is sentas an HTTP request to the server.It is useful to have some understanding of filters. There will be somealready loaded in the framework and they will affect its behavior.
It isuseful to check which ones are loaded, as there may be a combination ofSymbian-supplied filters and filters from the UI platforms.A number of core filters are supplied by the framework to perform thefollowing functionality:• authentication (RFC 2616 Section 14.8)• redirection (RFC 2616 Section 10.3)• validation (RFC 2616 Section 13.3).These are loaded automatically, using ECom, when the session iscreated.Each ECom-based filter can declare itself as one of three types:• implicitly loading, mandatory – the framework will fail to start up ifthis filter does not load• implicitly loading, optional – the framework will try to load thesefilters, but if they fail the framework startup continues• explicitly loading – the client must explicitly load these filters into theframework; typically these are filters, such as the authentication filter,than need some interaction with the client.Filters are declared as one of these three types in the default_datasection of the IMPLEMENTION_INFO in their ECOM registration resourcefile.
The format of the default_data section should include the string‘HTTP/ ’, followed by a ‘+ ’ for the mandatory implicitly loading filters; nothing for the optional implicitly loading filters, and a ‘- ’ for theexplicitly loading filters. Then the name of the filter should follow. Forexample, ‘HTTP/+MyVeryImportantFilter ’ would force ‘MyVeryImportantFilter ’ to load, and the framework to fail to initialize ifthe filter could not be loaded.At session creation time, any filters that are of an ‘implicitly loading’type will be loaded automatically, along with the core filters.The authentication filter, whilst being part of the core set, is of an‘explicitly loaded’ type because it requires a mixin class, MHTTPAuthenticationCallback, to be supplied when the filter is created.FILTERS363This provides a callback interface from the filter to the client, and therefore must be implemented, and therefore supplied explicitly, by theclient.In addition to the core filters there may be UI platform specificfilters already loaded into the framework, such as a GZip contentencoding filter, or a DRM handling filter.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
