DOCSLIB.ORG

Large Scale Multimedia Messaging Service Center with Optimized Database Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Large Scale Multimedia Messaging Service Center with Optimized Database Implementation IT 12 056 Examensarbete 30 hp November 2012 Large Scale Multimedia Messaging Service Center with Optimized Database Implementation Erdem Aksu Institutionen för informationsteknologi Department of Information Technology Abstract Large Scale Multimedia Messaging Service Center with Optimized Database Implementation Erdem Aksu Teknisk- naturvetenskaplig fakultet UTH-enheten The standardization forum 3GPP has specified Multimedia Messaging Service (MMS) standard including an MMS Relay-Server that allows users to send and receive Besöksadress: messages including multimedia contents like text, images, audio and video. A large Ångströmlaboratoriet Lägerhyddsvägen 1 scale Multimedia Message Service Relay-Server implementation needs an efficient Hus 4, Plan 0 database solution. The database should be able to support storage and manipulation of data for millions of transactions. Consistency and availability should be ensured Postadress: under heavy traffic load to prevent data losses and service delays. In this thesis, I Box 536 751 21 Uppsala present the implementation and extended evaluation of a store and forward mechanism for messages kept in MMS Server and I propose a solution to use Berkeley Telefon: DB as a back-end to Mnesia DBMS to achieve higher storage efficiency. I show that it 018 – 471 30 03 is feasible to replace database back-end of Mnesia with Berkeley DB while keeping Telefax: transparency to application level and having an efficient message store in terms of 018 – 471 30 00 higher throughput under heavy traffic. Hemsida: http://www.teknat.uu.se/student Handledare: Martin Kjellin Ämnesgranskare: Tore Risch Examinator: Lisa Kaati IT 12 056 Sponsor: Mobile Arts AB Tryckt av: Reprocentralen ITC ii Preface I would like to address special thanks to my advisor, Martin Kjellin for his support, ad- vice and attentive guidance throughout this thesis work. I also would like to thank Lars Kari for being a valuable source of ideas and for his insightful comments that helped me accomplish this thesis. I would like to express my gratitude to Tore Risch, my reviewer at Uppsala University, for reviewing my work and sharing his worthwhile opinions and also to Lisa Kaati, my examiner at Uppsala University, for her invaluable guidance that helped me complete this work. Furthermore, I would like to express my thanks to all my colleagues in Mobile Arts for their assistance, motivation and the opportunity they gave me to work on this thesis. Finally, my warmhearted thanks go to my adored mother and father. Their love and valuable support gave me the highest motivation and courage to achieve my goal. I am grateful to all people who supported me. Without their help, it would not have been possible to successfully complete this study. iii iv Contents 1 Introduction 1 1.1 Motivation and Problem Statement . 1 1.2 Method . 4 1.3 MMSC Development . 5 1.4 Limitations . 6 1.5 Alternative Approaches . 6 1.6 Contributions . 7 1.7 Thesis Structure . 8 2 Background 9 2.1 Erlang/OTP . 9 2.2 Mnesia . 10 2.3 Berkeley DB . 11 2.4 Port Drivers . 12 2.5 Multimedia Message Service (MMS) . 12 2.6 Store and Forward . 14 2.7 MA Framework . 15 2.8 Related Work . 15 3 Design and Implementation 19 3.1 Transparency . 19 3.2 Abstraction Level . 20 3.3 Berkeley DB - Dets Interface . 21 3.4 MMSC Design . 22 3.4.1 MMSC Front-End . 24 3.4.2 MMSC Back-End . 27 4 Evaluation 35 4.1 Test Platform Setup . 35 4.2 Functional Testing . 36 4.2.1 Functions of Mnesia Exports . 36 4.2.2 Functions of System Components . 36 4.3 Performance Testing . 37 v 4.3.1 mnesia meter . 37 4.3.2 mnesia tpcb . 40 5 Conclusions and Future work 45 5.1 Discussion . 45 5.2 Future Work . 46 Appendices 51 A DB Driver Implementation 51 A.1 Erl driver Usage . 51 A.2 BDB Library Usage . 52 B TPC-B Test Outputs 55 B.1 TPC-B on BDB Back-End . 55 B.2 TPC-B on DETS Back-End . 71 vi List of Figures 2.1 Supervision Tree . 10 2.2 Implementation of MMSM Interface Using WAP Gateway [4] . 13 2.3 Implementation of MMSM Interface Using HTTP Based Protocol Stack [4] 13 2.4 Example MMS Transaction Flow . 14 3.1 Dets Table States . 21 3.2 BDB-Erlang Communication . 22 3.3 Transaction Call Flow of MMS . 23 3.4 Data Flow Diagram of MMSC . 24 3.5 Entity Relationship between mmsc subscriber and mmsc profile . 26 3.6 MMSC Back-End Modules and Interactions . 28 3.7 MM Notification Module State Machine . 34 4.1 Test Environment Setup . 36 4.2 Column Chart for mnesia meter Results . 40 4.3 Column Chart for mnesia tpcb Results . 43 vii viii List of Abbreviations BDB Berkeley DB ESME External Short Messaging Entity GSM Global System for Mobile Communications IMSI International Mobile Subscriber Identity MA Mobile Arts MM Multimedia Message MMS Multimedia Message Service MMSC Multimedia Message Service Center MSISDN Mobile Subscriber ISDN Number SMS Short Message Service ix x Chapter 1 Introduction As capabilities of mobile networks and mobile phones evolve, demand on services pro- vided by telecommunication systems increase. Increasing demands makes services to be provided to rapidly growing number of users. Multimedia Messaging Service is a popular and ubiquitous service provided by mobile operators widely around the world. The stan- dardization forum 3GPP specified Multimedia Message Service (MMS) [6, 7] which allows to interchange a set of media types including text, image, audio, video and possible future formats of media, between service users. Likewise Short Message Service (SMS), MMS provides a non real-time service which does not require the realtime delivery of messages to recipients. Since the terminals of MMS are mobile phones, these devices might be turned of or they might lack signal reception and this aspect leads to other needs of mechanisms to deliver messages, one of which brings the requirement to store multimedia messages before delivery. This thesis work studies possible approaches to come up with an efficient storage mechanism that is going to be applied on a combined implementation of MMS Relay-Server where MMS Relay functionality implemented on the front-end and supports services like interaction with MMS Clients and messaging activities with other available messaging services, whereas MMS Server functionality implemented on the back-end that provides storage services for MM messages. 1.1 Motivation and Problem Statement Scalability in telecommunication systems is a significant aspect since the number of users of a service can grow arbitrarily. While number of users of a system differs from opera- tor to operator, various parameters like population of service areas, culture, economy, legal regulations play important role on prevalence and popularity of the service. Efficiency is a key fact to achieve scalability of a system by increasing the throughput. An efficient MMS Relay-Server should handle incoming traffic by processing and transmitting mes- sages. Since transmission of messages are dependent on human interaction, under heavy traffic load, MMS Server requires persistent storage of messages. Furthermore, while pro- cessing messages, subscriber based information is required. Thus subscriber database is 1 needed to keep user data. Having persistent storage requirements, database accesses ap- pears to be the bottleneck that affect the system throughput. Thus, system throughput of MMS Relay-Server can be increased with an efficient storage back-end implementation. The Multimedia Message Service Center (MMSC) presented in this work combines MMS Relay and MMS Server and operates as a single entity. MMSC is is divided into two subordinate components and these components are referred as front-end and back-end. MMSC front-end and MMSC back-end undertakes MMS Relay and MMS Server function- alities, respectively. A subscriber database for MMSC is not needed to be developed from scratch but the data model should be designed and implemented using an existing commer- cial implementation of subscriber database framework which was provided to me by the company Mobile Arts AB which supported and supervised this work. On the other hand, for handling transmission of multimedia messages (MMs), new mechanism needed to be developed for storing and forwarding. Although MMS is a non real-time messaging ser- vice like SMS, MMS comes with a significantly different delivery mechanism than SMS. A subordinate application under MMSC back-end needs to be developed to implement this delivery mechanism. This application requires an efficient database implementation and it should be based on persistent copies. Since the time between arrival and delivery of a MM is arbitrary, MMSC has to keep the MM without causing cumulative delays under contin- uous traffic. Persistent storage options brings overhead of disk access but disks provide required space to store large amounts of data. To achieve efficiency, I investigate the per- sistent storage options that can ensure consistency for MMSC back-end. To carry out this thesis work, Erlang/OTP is chosen as development platform. Erlang packages comes with Open Telecom Platform (OTP) which includes Mnesia DBMS which makes Mnesia ready to use by system developers since it does not require any integra- tion using external interfaces. Thus, I focus on persistent storage options of Mnesia DBMS. Mnesia provides non-relational, key/value database service to Erlang developers which also brings possibility to choose which physical storage media to be used. Mnesia supports two kinds of disk and one memory based storage options. For any replica of the table on any given Erlang Run-Time System, that is called a ”node” in OTP context, the storage type is defined by providing type and node list as an option to table creation function of Mnesia. Possible options are disc copies, disc only copies and ram copies.
Load more

Recommended publications
  • Chapter Xviii
    CHAPTER XVIII MOBILE TRAIN RADIO COMMUNICATIONS - GSM-R 18.0 GSM-R : 18.1 Introduction: Mobile Train Radio communication is a digital wireless network based on GSM-R (Global System for Mobile Communication-Railway) designed on EIRENE (European Integrated Railway Radio Enhanced Network) Functional requirement specification (FRS) and System Requirement specification ( SRS) The Basic features of GSM-R are Point to Point call Allows user to make a distinct call. Voice Broadcast call Allows groups of user to receive common information. Voice Group call Allows groups of user to make calls within /among the groups. Emergency call Allows user to call controller by short code or button during emergency. Functional addressing Allows a user or an application to be reached by means of a number, which identifies the relevant function and not the physical terminal. Location dependent addressing Provides the routing of mobile originated calls to the correct controller e.g. relative to the geographic area. eMLPP (enhanced Multi-Level Allows resource preemption for priority calls Precedence and Preemption) Fig.1 illustrates the system architecture. In this architecture a mobile station (MS) communicate with a base station subsystem (BSS) through the radio interface. The BSS is connected to the network switching subsystem (NSS) using the A interface. Fig.-1 Interface Interfaces Description Um Radio link between MS and BTS- Air interface Abis Between BTS and BSC, PCM 2 Mb ps Ater Between BSC and TCU, PCM 2 Mb ps A Between TCU and MSC, PCM 2 Mb ps B Between MSC and VLR, C Between MSC and HLR D Between HLR and VLR E Between two MSCs 18.1.1 The system consists of following sub systems : a) Mobile Station (MS) b) Base Station Sub system (BSS) c) Network and switching sub system (NSS) d) Operating sub system (OSS) e) Dispatcher f) Cab Radio g) Power Supply Arrangement 18.2 Radio interface and frequency used in GSM-R : The Radio link uses both FDMA (Frequency Division Multiple Access) and TDMA (Time Division multiple Access) .
    [Show full text]
  • 16 Aug 2007 Open Mobile Alliance OMA-RD IM-V1 0-20070816-C
    Instant Messaging Requirements Candidate Version 1.0 – 16 Aug 2007 Open Mobile Alliance OMA-RD_IM-V1_0-20070816-C 2007 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. [OMA-Template-ReqDoc-20050506-I] OMA-RD_IM-V1_0-20070816-C Page 2 (57) Use of this document is subject to all of the terms and conditions of the Use Agreement located at http://www.openmobilealliance.org/UseAgreement.html. Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice. You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner. Information contained in this document may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document. Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification.
    [Show full text]
  • MCP Q4`18 Release Notes Version Q4-18 Mirantis Cloud Platform Release Notes Version Q4`18
    MCP Q4`18 Release Notes version q4-18 Mirantis Cloud Platform Release Notes version Q4`18 Copyright notice 2021 Mirantis, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. No part of this publication may be reproduced in any written, electronic, recording, or photocopying form without written permission of Mirantis, Inc. Mirantis, Inc. reserves the right to modify the content of this document at any time without prior notice. Functionality described in the document may not be available at the moment. The document contains the latest information at the time of publication. Mirantis, Inc. and the Mirantis Logo are trademarks of Mirantis, Inc. and/or its affiliates in the United States an other countries. Third party trademarks, service marks, and names mentioned in this document are the properties of their respective owners. ©2021, Mirantis Inc. Page 2 Mirantis Cloud Platform Release Notes version Q4`18 What’s new This section provides the details about the features and enhancements introduced with the latest MCP release version. Note The MCP integration of the community software projects, such as OpenStack, Kubernetes, OpenContrail, and Ceph, includes the integration of the features which the MCP consumers can benefit from. Refer to the MCP Q4`18 Deployment Guide for the software features that can be deployed and managed by MCP DriveTrain. MCP DriveTrain • Encryption of sensitive data in the Reclass model • Galera verification and restoration pipeline • Jenkins version upgrade • Partitioning table for the VCP images Encryption of sensitive data in the Reclass model SECURITY Implemented the GPG encryption to protect sensitive data in the Git repositories of the Reclass model as well as the key management mechanism for secrets encryption and decryption.
    [Show full text]
  • LIST of NOSQL DATABASES [Currently 150]
    Your Ultimate Guide to the Non - Relational Universe! [the best selected nosql link Archive in the web] ...never miss a conceptual article again... News Feed covering all changes here! NoSQL DEFINITION: Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontally scalable. The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply such as: schema-free, easy replication support, simple API, eventually consistent / BASE (not ACID), a huge amount of data and more. So the misleading term "nosql" (the community now translates it mostly with "not only sql") should be seen as an alias to something like the definition above. [based on 7 sources, 14 constructive feedback emails (thanks!) and 1 disliking comment . Agree / Disagree? Tell me so! By the way: this is a strong definition and it is out there here since 2009!] LIST OF NOSQL DATABASES [currently 150] Core NoSQL Systems: [Mostly originated out of a Web 2.0 need] Wide Column Store / Column Families Hadoop / HBase API: Java / any writer, Protocol: any write call, Query Method: MapReduce Java / any exec, Replication: HDFS Replication, Written in: Java, Concurrency: ?, Misc: Links: 3 Books [1, 2, 3] Cassandra massively scalable, partitioned row store, masterless architecture, linear scale performance, no single points of failure, read/write support across multiple data centers & cloud availability zones. API / Query Method: CQL and Thrift, replication: peer-to-peer, written in: Java, Concurrency: tunable consistency, Misc: built-in data compression, MapReduce support, primary/secondary indexes, security features.
    [Show full text]
  • Location Update Procedure
    Location Update Procedure In order to make a mobile terminated call, The GSM network should know the location of the MS (Mobile Station), despite of its movement. For this purpose the MS periodically reports its location to the network using the Location Update procedure. Location Area (LA) A GSM network is divided into cells. A group of cells is considered a location area. A mobile phone in motion keeps the network informed about changes in the location area. If the mobile moves from a cell in one location area to a cell in another location area, the mobile phone should perform a location area update to inform the network about the exact location of the mobile phone. The Location Update procedure is performed: When the MS has been switched off and wants to become active, or When it is active but not involved in a call, and it moves from one location area to another, or After a regular time interval. Location registration takes place when a mobile station is turned on. This is also known as IMSI Attach because as soon as the mobile station is switched on it informs the Visitor Location Register (VLR) that it is now back in service and is able to receive calls. As a result of a successful registration, the network sends the mobile station two numbers that are stored in the SIM (Subscriber Identity Module) card of the mobile station. These two numbers are:- 1. Location Area Identity (LAI) 2. Temporary Mobile Subscriber Identity (TMSI). The network, via the control channels of the air interface, sends the LAI.
    [Show full text]
  • Multimedia Messaging Service (MMS); Functional Description; Stage 2 (3GPP TS 23.140 Version 5.4.0 Release 5)
    ETSI TS 123 140 V5.4.0 (2002-09) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional description; Stage 2 (3GPP TS 23.140 version 5.4.0 Release 5) R GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS 3GPP TS 23.140 version 5.4.0 Release 5 1 ETSI TS 123 140 V5.4.0 (2002-09) Reference RTS/TSGT-0223140v540 Keywords GSM, UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: [email protected] Copyright Notification No part may be reproduced except as authorized by written permission.
    [Show full text]
  • Couchbase Server Manual 2.1.0 Couchbase Server Manual 2.1.0
    Couchbase Server Manual 2.1.0 Couchbase Server Manual 2.1.0 Abstract This manual documents the Couchbase Server 2.1.0 series, including installation, monitoring, and administration interface and associ- ated tools. For the corresponding Moxi product, please use the Moxi 1.8 series. See Moxi 1.8 Manual. External Community Resources. Download Couchbase Server 2.1 Couchbase Developer Guide 2.1 Client Libraries Couchbase Server Forum Last document update: 05 Sep 2013 23:46; Document built: 05 Sep 2013 23:46. Documentation Availability and Formats. This documentation is available online: HTML Online . For other documentation from Couchbase, see Couchbase Documentation Library Contact: [email protected] or couchbase.com Copyright © 2010-2013 Couchbase, Inc. Contact [email protected]. For documentation license information, see Section F.1, “Documentation License”. For all license information, see Appendix F, Licenses. Table of Contents Preface ................................................................................................................................................... xiii 1. Best Practice Guides ..................................................................................................................... xiii 1. Introduction to Couchbase Server .............................................................................................................. 1 1.1. Couchbase Server and NoSQL ........................................................................................................ 1 1.2. Architecture
    [Show full text]
  • THE NOTION of DESIGN EMERGENCE EVOLVING YOUR SOFTWARE Who Are We
    THE NOTION OF DESIGN EMERGENCE EVOLVING YOUR SOFTWARE Who Are we 陈永胜 [email protected] @yeongsheng yeongsheng-tan !2 EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE “THE BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGE FROM SELF-ORGANIZING TEAMS.” – PRINCIPLES BEHIND THE AGILE MANIFESTO AGENDA ‣ EMERGENT DESIGN ‣ CHOOSE YOUR POISON ‣ SWITCHING OUT AN ARCHITECTURAL LAYER ‣ WHEN RUBBER HITS THE ROAD ‣ SHOW ME THE CODE ‣ Q&A LISTEN, LEARN, UNDERSTAND, ADAPT EMERGENT DESIGN EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE KNOWLEDGE CREATION & PRESERVATION KNOWLEDGE CREATION KNOWLEDGE PRESERVATION EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE WHEN DO YOU HAVE BEST KNOWLEDGE? KNOWLEDGE VS TIME 100 75 50 Knowledge 25 0 AUG SEP OCT NOV DEC Time EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE HYPOTHETICAL KNOWLEDGE VS TIME 100 75 50 Knowledge 25 0 AUG SEP OCT NOV DEC Time EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE REALITY KNOWLEDGE VS TIME 100 75 50 Knowledge 25 0 AUG SEP OCT NOV DEC Time EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE WHAT WE SHOULD STRIVE FOR KNOWLEDGE VS TIME 100 75 50 Knowledge 25 0 AUG SEP OCT NOV DEC Time EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE TRADITIONAL VS EMERGENT Design Implement the initial design (try to make all decisions) TRADITIONAL EMERGENT Design Reflect and (decide an Design/Code Decide Design/Code initial Direction direction) Reflect and Design/Code Decide Direction EVOLVING YOUR SOFTWARE - THE NOTION OF DESIGN EMERGENCE MAKE IT WORK
    [Show full text]
  • Designing a Modern XMPP Service with Ejabberd
    ejabberd architecture and challenges in designing a modern messaging service 17th November 2015 Mickaël Rémond <[email protected]> Introduction ejabberd is scalable and versatile enough to adapt to most of the realtime messaging jobs you will want to handle. For many tasks, like corporate messaging, you can consider ejabberd as a standard package. However, to reach high level of scalability and flexibility, you need to consider ejabberd as an XMPP framework. As such, to build your modern messaging system, you need to: Be familiar with XMPP - Prerequisite. Learn ejabberd architecture Learn ejabberd API Work on solution design. Take control of your messaging platform and design it ! ejabberd: Routing messages in a statefull world ejabberd is a message router. Its role is to support real time messaging feature by moving messages from clients to other clients. In that sense it is stateless. However, to integrate in a statefull world, ejabberd has to support statefull features: Stateless: ejabberd is an XMPP server: Its goal is to route XMPP packets between JID. Statefull: In most case ejabberd depends on data (user base, contact list, …) or produce data (message archive, ...) Goal: deploy an ejabberd that is as stateless as possible, by leveraging backends. What are ejabberd backends ? Backends are pluggable modules you can configure to define where you would like to store part or all of your data. Backends provide the data to the feature modules of ejabberd. They can be read-write or read-only if you do not need some of the ejabberd associated features: For example, if you handle user management elsewhere in your infrastructure, you can use a user back-end that can only authenticate users but not create them.
    [Show full text]
  • Signaling Gateway with Multiple Imsi with Multiple Msisdn (Mimm
    (19) & (11) EP 1 665 838 B1 (12) EUROPEAN PATENT SPECIFICATION (45) Date of publication and mention (51) Int Cl.: of the grant of the patent: H04W 8/18 (2009.01) 10.03.2010 Bulletin 2010/10 (86) International application number: (21) Application number: 04781142.7 PCT/US2004/026410 (22) Date of filing: 13.08.2004 (87) International publication number: WO 2005/018245 (24.02.2005 Gazette 2005/08) (54) Signaling gateway with multiple imsi with multiple msisdn (mimm) service in a single sim for multiple roaming partners Signalisierungs-Gateway mit einem Mehrfach-Imsi-Mit-Mehrfach-MSISDN (MIMM) Dienst in einem einzigen SIM für mehrere Roaming-Partner Passerelle de signalisation àa imsi multiples et services multiples msisdn (mimm) dans un seul sim pour multiples partenaires itinerants (84) Designated Contracting States: (72) Inventor: JIANG, Yue, Jun AT BE BG CH CY CZ DE DK EE ES FI FR GB GR San Jose, CA 95128 (US) HU IE IT LI LU MC NL PL PT RO SE SI SK TR (74) Representative: Wallis, Helen Frances Mary et al (30) Priority: 13.08.2003 US 495202 P Olswang LLP 90 High Holborn (43) Date of publication of application: London WC1V 6XX (GB) 07.06.2006 Bulletin 2006/23 (56) References cited: (73) Proprietor: Roamware, Inc. WO-A-00/79761 WO-A-01/65884 San Jose, CA 95128 (US) WO-A-03/019969 WO-A2-02/41641 US-A- 5 930 701 US-A- 5 943 620 US-A- 6 014 561 US-A1- 2003 064 723 Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the Implementing Regulations.
    [Show full text]
  • CV 4567 Technical Lead / System Architect / Senior Erlang Developer / Senior UI/UX Developder/ Designer
    CV_4567 Technical lead / System architect / Senior Erlang Developer / Senior UI/UX developder/ designer Free for offers. For now I am fully concentrated on Erlang and on all that connected to it. My last position is Technical Lead within experience of managing and building client-server application for both side: server or client. My experience is: Software Developer Skill: over 14 years Erlang Developing: over 6 years High-load Developing: over 10 years Big-Data Developing: 4 years Qt/QML Interfaces Developing: 5 years Web/UI/UX Designer Skill: over 16 years Designer Skill: over 23 years Management Skill: over 14 years And other, other, other ... I know and have comprehension of different: - in design: minimalism style vs. have no any ability to create something - in development: reinvent the wheel vs. have no any wishes for to do something - in management: the answer to the problem vs. fitting answer Career Owner / Technical lead, Erlang Web Developer, Senior UI/UX/Designer September 2012 - Aktuell I am supporting this project for my own experiments and gathering results of it. Full stack Erlang Web developer 1. Library for Yaws 2. HTML Render Engine for Yaws 3. Mnesia clustering 4. Trademark naming 5. Design: branding/UI/UX/Web Technical lead / System architect / Senior Erlang Developer / Senior UI/UX developder/designer Mai 2016 - April 2018 I've done for this company (all is HIPAA-compliant): 1) Architectural projecting: -- protocol for instant messenger via HTTPS -- message DB structure -- cluster architecture -- search engine emulation
    [Show full text]
  • Distributed Event Handler
    Distributed Event Handler Creation of a distributed event handler with priority handling and synchronized timing ROBIN OLAUSSON JIMMY WESTERLUND Degree project in Information and Software systems Stockholm, Sweden 2013 TRITA-ICT-EX-2013:163 Distributed Event Handler Creation of a distributed event handler with priority handling and synchronized timing ROBIN OLAUSSON, JIMMY WESTERLUND Bachelor Thesis at ICT Examiner: Johan Montelius (School of ICT) Abstract During the start up of a project, we found out that an event handler was needed. This event handler needed to be redundant and able to ensure that events with dependencies to each other, where executed in a specified correct order. Policies where written to ensure that the end result, if able to fulfill these, was the product that was needed. The result is an event handler written in Erlang, which ensures that all events given to it will be executed in the order specified. Even though not fulfilling all policies there are plans for future work with solutions on how this will be fixed. In conclusion, even though the event handler is not a complete product, this report presents a solution to the general event handling problem. Referat Ditribuerad Händelsehanterare Under uppstarten av ett projekt fick vi reda p˚aatt det beh¨ovdes en h¨andelsehanterare. H¨andelsehanteraren skulle vara redundant och kunna s¨akerst¨alla att h¨andelser beroende av varandra, k¨ordes i den ordning som specifiserats. Policies skrevs ner f¨or att f¨ors¨akra att om h¨andelsehanteraren kunde uppfylla dessa, var detta produkten som efters¨oktes. Re- sultatet blev en h¨andelsehanterare skriven i Erlang, vilken f¨ors¨akrar att samtliga event givna, blev utf¨orda i den spec- ifierade ordningen.
    [Show full text]