1 / 22

Implementing MLP

Implementing MLP. speaker. Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB. Location services. Distinctive feature of mobile services Measurements from network collected in a location server (spec: 03.71) Clients access information via HTTP/XML interface to server

marv
Download Presentation

Implementing MLP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing MLP speaker Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB

  2. Location services • Distinctive feature of mobile services • Measurements from network collected in a location server (spec: 03.71) • Clients access information via HTTP/XML interface to server • Clients are portals, resellers, operators, … which then provide info to end-users

  3. Standardization • Standardized info format from mobile net => location server • Plethora of protocols for accessing info location server => client • Location interoperability forum (LIF) founded to bring some order • Equipment manufacturers, operators, … • Mobile Location Protocol (MLP) = unifier

  4. The MLP Protocol • Mobile Location Protocol 3.0.0 based on HTTP/1.1 and XML • About half a dozen DTDs define data • Many features • Desired accuracy, max age, … • Presentation coordinate system • Varying geometric shapes in reply • Multitude of data formats • ”Every feature is optional”

  5. SIMPL2 and MLP • SIMPL2 developed by Cellpoint as an MLP compatible protocol • Removed some features • Zoning, triggering • Still had to signal that features not supported • Added some features • CLPT-specific extensions for charging records • Many changes in MLP and SIMPL2 during development • Fourteen SIMPL2 draft specifications prior to release • Seven released during May-June

  6. SIMPL2 request • <?xml version ="1.0" ?> • <!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_300.DTD"> • <svc_init ver="3.0.0"> • <hdr ver="3.0.0"> • <client> • <id>application_4</id> • <pwd>secret</pwd> • </client> • </hdr> • <slir ver="3.0.0"> • <msids> • <msid type="MSISDN">46702711038</msid> • </msids> • <geo_info> • <CoordinateReferenceSystem> • <Identifier> • <code>4326</code> • <codeSpace>www.epsg.org</codeSpace> • <edition>6.1</edition> • </Identifier> • </CoordinateReferenceSystem> • </geo_info> • </slir> • </svc_init>

  7. SIMPL2 reply • <?xml version ="1.0" ?> • <!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_300.DTD"> • <svc_result ver="3.0.0"> • <slia ver="3.0.0"> • <pos> • <msid>46702711038</msid> • <pd> • <time utc_off="+0200">20020623134453</time> • <shape> • <CircularArea srsName="www.epsg.org#4326"> • <coord> • <X>20 30 5.4W</X> • <Y>0 0 3.5N</Y> • </coord> • <radius>570</radius> • </CircularArea> • </shape> • </pd> • </pos> • </slia> • </svc_result>

  8. Implementing MLP • Integrate inets and xmerl • Act as server (MLS) • Act as proxy (MLB) • Must still handle all of MLP for proxying non-CLPT location servers • Thoroughly validate all incoming data • Requests and replies • Translate external  internal format • Dispatch to other server or compute location

  9. The bad part • Aggressive dev schedule (5-6 months x 3 people) • Goal: Release soon after MLP specification is finalized • Specification mutates quickly • Major and minor syntax and feature changes • Data formats • Error codes • Specification bug fixes • Only protocol syntax specified, not semantics • Semantics sometimes unclear

  10. The first-half score • Unsatisfactory code • Specification changes => patch upon patch • Unsatisfactory testing • Hard for developers to test such a big protocol • Hard for QA to know what worked in a given release • Time spent on reacting to trouble reports and specification changes • Release date approaching, but not release

  11. Second-half kickoff • We needed to get bugs and changes under control • Code must become easy to change • Esp. XML validation • Code must have high quality before QA begins • Fixing bugs via QA too slow and unhappy for us and QA • Must quickly resolve arguments about TRs • Many specification changes => many arguments about what was valid => lost time

  12. Abstraction • Get rid of records in crucial places • Use abstract data types instead • Encapsulate data representation in module • Can check that data are consistent when created • Operations are named => legible code, intention clear • (Programming 101 …) • Why weren’t ADTs used already? • Record notation more convenient (e.g., pattern match) • Records already provide representation independence (sort of)

  13. Quick and dirty encapsulation #request_rec{misc = Priv, subscr_i=X#subscr_rec.f3} => request_adt:set_subscriber_info(Priv, X) -module(request_adt). set_subscriber_info(Priv, X) -> #request_req{misc=Priv, subscr_i=X#subscr_rec.f3}.

  14. XML validation • Original code: traverse xml tree, check values • Rewrite for fast change • Use a rule interpreter + separate validation rule set • Easy to check that rules obey current specification • Easy to rewrite or extend without intro bugs • Pace of development made this crucial • Many draft specs => each must be integrated quickly

  15. Validation rules -define(tag_specs, [{'svc_init', blank, [{'ver', {'or', [{member, ["3.0.0"]}, {unsupported, ver}]}}]}, ... ]). apply_rule(blank, Value) -> [] == strip_whites(Value); apply_rule({'or', Rules}, Value) -> lists:any(fun(Rule) -> apply_rule(Rule, Value) end, Rules); ...

  16. Improve quality • Go for (pre-QA) automated testing • Not a new idea, but awesomely useful (again) • Wrote tester from scratch • effort paid back very quickly • Exercise all protocol features • Regression test case added when TR appears • Detects integration bugs as well • SIMPL2 ”on top of food chain”

  17. Test case specification test_series(1, 1) -> Clients = [{"service_a", "secret", ?OK}, ...], MSID = "...", [ {Expect, ?svc_init(?hdr_client(Name, Pwd), ?slir(?msids(MSID), ?default_geo_info)) || {Name, Pwd, Expect} <- Clients ]; ...

  18. Social issues • Some XP practices used (see paper) • Pair programming worked well • More refactoring should have been done • Elegance is (should not be) optional • Hard to take the time

  19. Evaluation • Worked very well in this setting • Bug fixing reduced • Bug hunting reduced • Faster turnaround • We could direct efforts to the right areas • Resolve grey areas of SIMPL2 and MLP • Tighten code • Add test cases • ”Virtuous circle”

  20. Performance evaluation • Measured SIMPL2 by running test suite • Single request at a time on unloaded system • Varying cases rather than weighted to normal • Results: • 15% time in scanning and parsing • 8% in validation • 18% in port_command, port_close, … • (tests include acting as proxy or server, Oracle access, …) • So any speedup from optimizing validation is limited

  21. Future work • Extend data driven design • Rule-driven translation from/to internal format? • Generate a validating XML parser given a validation spec? • Extend xmerl

  22. Final score • ADTs > Records • Data driven design (= validation rules) reduce complexity • Automated testing • XP-practices (pair programming) • SIMPL2 released to customer same week as final MLP specification was released • Another grisprotokoll bites the dust

More Related