Universal Plug and Play

Universal Plug and Play

UPnP (originally Universal Plug and Play) is a set of Internet Protocol-based networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices. Officially, only the abbreviations UPnP and UPnP+ are trademarked. UPnP assumes the network runs IP, and then uses HTTP on top of IP to provide device/service description, actions, data transfer and event notification. Device search requests and advertisements are supported by running HTTP on top of UDP (port 1900) using multicast (known as HTTPMU). Responses to search requests are also sent over UDP, but are instead sent using unicast (known as HTTPU). Conceptually, UPnP extends plug and play—a technology for dynamically attaching devices directly to a computer—to zero-configuration networking for residential and SOHO wireless networks. UPnP devices are plug-and-play in that, when connected to a network, they automatically establish working configurations with other devices, removing the need for users to manually configure and add devices through IP addresses. UPnP is generally regarded as unsuitable for deployment in business settings for reasons of economy, complexity, and consistency: the multicast foundation makes it chatty, consuming too many network resources on networks with a large population of devices; the simplified access controls do not map well to complex environments. == Overview == The UPnP architecture allows device-to-device networking of consumer electronics, mobile devices, personal computers, and networked home appliances. It is a distributed, open architecture protocol based on established standards such as the Internet Protocol Suite (TCP/IP), HTTP, XML, and SOAP. UPnP control points (CPs) are devices which use UPnP protocols to control UPnP controlled devices (CDs). The UPnP architecture supports zero-configuration networking. A UPnP-compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, advertise or convey its capabilities upon request, and learn about the presence and capabilities of other devices. Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) servers are optional and are only used if they are available on the network. Devices can disconnect from the network automatically without leaving state information. UPnP was published as a 73-part international standard ISO/IEC 29341 in December 2008. Other UPnP features include: Media and device independence UPnP technology can run on many media that support IP, including Ethernet, FireWire, Infrared (IrDA), home wiring (G.hn) and Radiofrequency (Bluetooth, Wi-Fi). No special device driver support is necessary; common network protocols are used instead. User interface (UI) control Optionally, the UPnP architecture enables devices to present a user interface through a web browser (see Presentation below). Operating system and programming language independence Any operating system and any programming language can be used to build UPnP products. UPnP stacks are available for most platforms and operating systems in both closed- and open-source forms. Programmatic control UPnP architecture also enables conventional application programmatic control. Extensibility Each UPnP product can have device-specific services layered on top of the basic architecture. In addition to combining services defined by the UPnP Forum in various ways, vendors can define their own device and service types. They can extend standard devices and services with vendor-defined actions, state variables, data structure elements, and variable values. == Protocol == UPnP uses common Internet technologies. It assumes the network must run Internet Protocol (IP) and then uses HTTP, SOAP and XML on top of IP, to provide device/service description, actions, data transfer and eventing. Device search requests and advertisements are supported by running HTTP on top of UDP using multicast (known as HTTPMU). Responses to search requests are also sent over UDP, but are instead sent using unicast (known as HTTPU). UPnP uses UDP due to its lower overhead, as it does not require confirmation of received data and retransmission of corrupt packets. HTTPU and HTTPMU specifications were initially submitted as an Internet Draft, but it expired in 2001; These specifications have since been integrated into the actual UPnP specifications. UPnP uses UDP port 1900, and all used TCP ports are derived from the SSDP alive and response messages. === Addressing === The foundation for UPnP networking is IP addressing. Each device must implement a DHCP client and search for a DHCP server when the device is first connected to the network. If no DHCP server is available, the device must assign itself an address. The process by which a UPnP device assigns itself an address is known within the UPnP Device Architecture as AutoIP. In UPnP Device Architecture Version 1.0, AutoIP is defined within the specification itself; in UPnP Device Architecture Version 1.1, AutoIP references IETF RFC 3927. If during the DHCP transaction, the device obtains a domain name, for example, through a DNS server or via DNS forwarding, the device should use that name in subsequent network operations; otherwise, the device should use its IP address. === Discovery === Once a device has established an IP address, the next step in UPnP networking is discovery. The UPnP discovery protocol is known as the Simple Service Discovery Protocol (SSDP). When a device is added to the network, SSDP allows that device to advertise its services to control points on the network. This is achieved by sending SSDP alive messages. When a control point is added to the network, SSDP enables that control point to actively search for devices of interest on the network or listen passively to SSDP alive messages from devices. The fundamental exchange is a discovery message containing a few essential details about the device or one of its services, such as its type, identifier, and a pointer (network location) to more detailed information. === Description === After a control point has discovered a device, it still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, it must retrieve the device's description from the location (URL) provided by the device in the discovery message. The UPnP Device Description is expressed in XML. It includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, (presentation) URLs to vendor-specific websites, etc. The description also includes a list of any embedded services. For each service, the Device Description document lists the URLs for control, eventing and service description. Each service description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time and are described in terms of their data type, range, and event characteristics. === Control === Having retrieved a description of the device, the control point can send actions to a device's service. To do this, a control point sends a suitable control message to the control URL for the service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP). Much like function calls, the service returns any action-specific values in response to the control message. The effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service. === Event notification === Another capability of UPnP networking is event notification, or eventing. The event notification protocol defined in the UPnP Device Architecture is known as General Event Notification Architecture (GENA). A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at runtime. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and their current values. These messages are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple control points, eventing is designed to keep all control points equally informed

DocuWare

DocuWare is cloud-based Software as a Service (SaaS) provider. DocuWare software provides document management, repository, and workflow automation functions (also referred to as enterprise content management (ECM) or content services). The company is headquartered in Germany and the United States. DocuWare is also the name of the flagship product offered by the company. == Company history == On October 27, 1988, DOCUNET GmbH was founded in Germering, Germany (near Munich) by President Jürgen Biffar. Since 1990, Biffar has been managing the company with his colleague, Thomas Schneck. DOCUNET AG has since been renamed and is now known as DocuWare. Since 1999, DocuWare has outsourced parts of its development to Sofia, Bulgaria. As of 2016, Nemetschek OOD had 42 employees working on the DocuWare product. DocuWare GmbH holds a 20 percent stake in Nemetschek OOD. In April 2012, an investment agreement was signed between the company and Morgan Stanley Expansion Capital LP, a Morgan Stanley Investment Management private equity fund. Its aim was promoting and accelerating the global growth of DocuWare. The legal form, AG (Public Holding Company) changed to GmbH (limited liability corporation). The company acquired U.S.-based Westbrook Technologies Inc., developer of Fortis ECM software in August 2013. In 2014, Westbrook Technologies Inc. was merged into DocuWare Corporation. At the beginning of 2016, DocuWare appointed Dr. Michael Berger as its Chief Technology Officer (CTO). Dr. Berger joined the company in 2008 as Vice President Research & Development. On January 1, 2019, Jürgen Biffar and Thomas Schneck stepped back from their operational roles after 30 years, and Dr. Michael Berger and Max Ertl started their new roles as co-presidents. On August 6, 2019, DocuWare was acquired by Ricoh. DocuWare continues to operate as a standalone subsidiary of Ricoh. In 2020, the company received approval to move its U.S. headquarters from New Windsor to Beacon, New York. === Subsidiaries === DocuWare Corporation (Beacon, NY), founded January 1, 2001 DocuWare Ltd (Nottinghamshire), founded April 1, 2005 DocuWare SARL (Paris), founded September 1, 2008 DocuWare S.L. (Barcelona), founded July 1, 2009

IDMS

The Integrated Database Management System (IDMS) is a network model (CODASYL) database management system for mainframes. It was first developed at BFGoodrich and later marketed by Cullinane Database Systems (renamed Cullinet in 1983). Since 1989 the product has been owned by Computer Associates (now CA Technologies), who renamed it Advantage CA-IDMS and later simply to CA IDMS. In 2018 Broadcom acquired CA Technologies, renaming it back to IDMS. == History == The roots of IDMS go back to the pioneering database management system called Integrated Data Store (IDS), developed at General Electric by a team led by Charles Bachman and first released in 1964. In the early 1960s IDS was taken from its original form, by the computer group of the BFGoodrich Chemical Division, and re-written in a language called Intermediate System Language (ISL). ISL was designed as a portable system programming language able to produce code for a variety of target machines. Since ISL was actually written in ISL, it was able to be ported to other machine architectures with relative ease, and then to produce code that would execute on them. The Chemical Division computer group had given some thought to selling copies of IDMS to other companies, but was told by management that they were not in the software products business. Eventually, a deal was struck with John Cullinane to buy the rights and market the product. Because Cullinane was required to remit royalties back to B.F. Goodrich, all add-on products were listed and billed as separate products – even if they were mandatory for the core IDMS product to work. This sometimes confused customers. The original platforms were the GE 235 computer and GE DATANET-30 message switching computer: later the product was ported to IBM mainframes and to DEC and ICL hardware. The IBM-ported version runs on IBM mainframe systems (System/360, System/370, System/390, zSeries, System z9). In the mid-1980s, it was claimed that some 2,500 IDMS licenses had been sold. Users included the Strategic Air Command, Ford of Canada, Ford of Europe, Jaguar Cars, Clarks Shoes UK, Axa/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Cleveland Clinic, Bank of Canada, General Electric, Aetna and BT in the UK. A version for use on the Digital Equipment Corporation PDP-11 series of computers was sold to DEC and was marketed as DBMS-11. In 1976 the source code was licensed to ICL, who ported the software to run on their 2900 series mainframes, and subsequently also on the older 1900 range. ICL continued development of the software independently of Cullinane, selling the original ported product under the name ICL 2900 IDMS and an enhanced version as IDMSX. In this form it was used by many large UK users, an example being the Pay-As-You-Earn system operated by Inland Revenue. Many of these IDMSX systems for UK Government were still running in 2013. In the early to mid-1980s, relational database management systems started to become more popular, encouraged by increasing hardware power and the move to minicomputers and client–server architecture. Relational databases offered improved development productivity over CODASYL systems, and the traditional objections based on poor performance were slowly diminishing. Cullinet attempted to continue competing against IBM's DB2 and other relational databases by developing a relational front-end and a range of productivity tools. These included Automatic System Facility (ASF), which made use of a pre-existing IDMS feature called LRF (Logical Record Facility). ASF was a fill-in-the-blanks database generator that would also develop a mini-application to maintain the tables. It is difficult to judge whether such features may have been successful in extending the selling life of the product, but they made little impact in the long term. Those users who stayed with IDMS were primarily interested in its high performance, not in its relational capabilities. It was widely recognized (helped by a high-profile campaign by E. F. Codd, the father of the relational model) that there was a significant difference between a relational database and a network database with a relational veneer. In 1989 Computer Associates continued after Cullinet acquisition with the development and released Release 12.0 with full SQL in 1992–93. CA Technologies continued to market and support the CA IDMS and enhanced IDMS in subsequent releases by TCP/IP support, two phase commit support, XML publishing, zIIP specialty processor support, Web-enabled access in combination with CA IDMS Server, SQL Option and GUI database administration via CA IDMS Visual DBA tool. CA-IDMS systems are today still running businesses worldwide. Many customers have opted to web-enable their applications via the CA-IDMS SQL Option which is part of CA Technologies' Dual Database Strategy. == Integrated Data Dictionary == One of the sophisticated features of IDMS was its built-in Integrated data dictionary (IDD). The IDD was primarily developed to maintain database definitions. It was itself an IDMS database. DBAs (database administrators) and other users interfaced with the IDD using a language called Data Dictionary Definition Language (DDDL). IDD was also used to store definitions and code for other products in the IDMS family such as ADS/Online and IDMS-DC. IDD's power was that it was extensible and could be used to create definitions of just about anything. Some companies used it to develop in-house documentation. == Overview == === Logical Data Model === The data model offered to users is the CODASYL network model. The main structuring concepts in this model are records and sets. Records essentially follow the COBOL pattern, consisting of fields of different types: this allows complex internal structure such as repeating items and repeating groups. The most distinctive structuring concept in the Codasyl model is the set. Not to be confused with a mathematical set, a Codasyl set represents a one-to-many relationship between records: one owner, many members. The fact that a record can be a member in many different sets is the key factor that distinguishes the network model from the earlier hierarchical model. As with records, each set belongs to a named set type (different set types model different logical relationships). Sets are in fact ordered, and the sequence of records in a set can be used to convey information. A record can participate as an owner and member of any number of sets. Records have identity, the identity being represented by a value known as a database key. In IDMS, as in most other Codasyl implementations, the database key is directly related to the physical address of the record on disk. Database keys are also used as pointers to implement sets in the form of linked lists and trees. This close correspondence between the logical model and the physical implementation (which is not a strictly necessary part of the Codasyl model, but was a characteristic of all successful implementations) is responsible for the efficiency of database retrieval, but also makes operations such as database loading and restructuring rather expensive. Records can be accessed directly by database key, by following set relationships, or by direct access using key values. Initially the only direct access was through hashing, a mechanism known in the Codasyl model as CALC access. In IDMS, CALC access is implemented through an internal set, linking all records that share the same hash value to an owner record that occupies the first few bytes of every disk page. In subsequent years, some versions of IDMS added the ability to access records using BTree-like indexes. === Storage === IDMS organizes its databases as a series of files. These files are mapped and pre-formatted into so-called areas. The areas are subdivided into pages which correspond to physical blocks on the disk. The database records are stored within these blocks. The DBA allocates a fixed number of pages in a file for each area. The DBA then defines which records are to be stored in each area, and details of how they are to be stored. IDMS intersperses special space-allocation pages throughout the database. These pages are used to keep track of the free space available in each page in the database. To reduce I/O requirements, the free space is only tracked for all pages when the free space for the area falls below 30%. Four methods are available for storing records in an IDMS database: Direct, Sequential, CALC, and VIA. The Fujitsu/ICL IDMSX version extends this with two more methods, Page Direct, and Random. In direct mode the target database key is specified by the user and is stored as close as possible to that DB key, with the actual DB key on which the record is stored being returned to the application program. Sequential placement (not to be confused with indexed sequential), simply places each new record at the end of the area. This option is rarely used. CALC uses a hashing algo

Computer Graphics International

Computer Graphics International (CGI) is one of the oldest annual international conferences on computer graphics. It is organized by the Computer Graphics Society (CGS). Researchers across the whole world are invited to share their experiences and novel achievements in various fields - like computer graphics and human-computer interaction. Former conferences have been held recently in Hong Kong (China), Geneva (Switzerland), Shanghai (China), Geneva (virtually), Calgary (Canada), Bintan (Indonesia) and Yokohama (Japan). == Awards == Starting in the year of 2013, CGI has given yearly a Best Paper Award and a Career Achievement Award. == Venues ==

Wide-column store

A wide-column store (or extensible record store) is a type of NoSQL database. It uses tables, rows, and columns, but unlike a relational database, the names and format of the columns can vary from row to row in the same table. A wide-column store can be interpreted as a two-dimensional key–value store. Google's Bigtable is one of the prototypical examples of a wide-column store. == Wide-column stores versus columnar databases == Wide-column stores such as Bigtable and Apache Cassandra are not column stores in the original sense of the term, since their two-level structures do not use a columnar data layout. In genuine column stores, a columnar data layout is adopted such that each column is stored separately on disk. Wide-column stores do often support the notion of column families that are stored separately. However, each such column family typically contains multiple columns that are used together, similar to traditional relational database tables. Within a given column family, all data is stored in a row-by-row fashion, such that the columns for a given row are stored together, rather than each column being stored separately. Wide-column stores that support column families are also known as column family databases. == Notable examples == Notable wide-column stores include: Apache Accumulo Apache Cassandra Apache HBase Bigtable DataStax Enterprise (uses Apache Cassandra) DataStax Astra DB (uses Apache Cassandra) Hypertable Azure Tables ScyllaDB

Deluxe Paint Animation

DeluxePaint Animation is a 1990 graphics editor and animation creation package for MS-DOS, based on Deluxe Paint for the Amiga. It was adapted by Brent Iverson with additional animation features by Steve Shaw and released by Electronic Arts. The program requires VGA graphics, MS-DOS 2.1 or higher, and a mouse. == Features == Listed from the back of the box. Complete selection of painting tools — Draw any shape you want, any way you want. Turn any image into a brush. You can rotate, flip, shear, resize, smear, and shade it. 7 levels of magnification — Paint in magnified mode if you want. Use variable zoom for detailed editing at the pixel level. 3-D perspective — Move and rotate images in full 3-D, automatically. Use color cycling and gradient fills to create great special effects. Stencils — Protect your designs from the slip of the hand or a bad idea. A stencil masks your image so you can paint "behind" and "in front of" it. Use the handy Move Dialog to animate brushes in full 3-D — automatically! Ideal for creating spinning titles for low-cost videos. 37 multi-sized fonts

Cyber and Information Domain Service

The Cyber and Information Domain Service (CIDS; German: Cyber- und Informationsraum, lit. 'Cyber and Information space', pronounced [ˈsaɪbɐ ʔʊnt ʔɪnfɔʁmaˈtsi̯oːnsʁaʊm] ; CIR) is the youngest branch of the German Armed Forces, the Bundeswehr. The decision to form an organizational unit was presented by Defense Minister Ursula von der Leyen on 26 April 2016, becoming operational on 1 April 2017. It is headquartered in Bonn. == History == In November 2015, the German Ministry of Defense activated a Staff Group within the ministry tasked with developing plans for a reorganization of the Cyber, IT, military intelligence, geo-information, and operative communication units of the Bundeswehr. On 26 April 2016, Defense Minister Ursula von der Leyen presented the plans for the new military branch to the public and on 5 October 2016 the command's staff became operational as a department within the ministry of defense. On 1 April 2017, the Cyber and Information Domain Service (CIDS) was activated as a "military organizational unit" (Organisationsbereich), indicating its status below a full service branch. The CIDS Headquarters took command of all existing electronic warfare, signals, IT, military intelligence, geoinformation, and psychological operations units. As part of a wider restructuring of higher command in the Bundeswehr in 2024, it was decided to upgrade it from a military organizational unit to the fourth full military service branch, alongside Heer (army), Luftwaffe (air force) and Deutsche Marine (navy). == Organisation == The CIDS is commanded by the Chief of the Cyber and Information Domain Service (Inspekteur des Cyber- und Informationsraum InspCIR), a three-star general position, based in Bonn. As of April 2023, it is structured as follows: Cyber and Information Domain Service Command (Kommando Cyber- und Informationsraum KdoCIR), in Bonn Reconnaissance and Effects Command (Kommando Aufklärung und Wirkung KdoAufkl/Wirk), in Gelsdorf 911th Electronic Warfare Battalion 912th Electronic Warfare Battalion, mans the Oste-class SIGINT/ELINT and reconnaissance ships 931st Electronic Warfare Battalion 932nd Electronic Warfare Battalion, provides airborne troops for operations in enemy territory Cyber-Operations Centre (Zentrum Cyber-Operationen ZSO) Central Imaging Reconnaissance (Zentrale Abbildende Aufklärung ZAbbAufkl), operating the SAR-Lupe satellites Central Bundeswehr Investigation Authority for Technical Reconnaissance (Zentrale Untersuchungsstelle der Bundeswehr für Technische Aufklärung ZU-StelleBwTAufkl) Signals Reconnaissance Centre North (Fernmeldeaufklärungszentrale Nord FmAufklZentr NORD) Signals Reconnaissance Centre South (Fernmeldeaufklärungszentrale Süd FmAufklZentr SÜD) Information Technology Services Command (Kommando Informationstechnik-Services der Bundeswehr KdoIT-SBw), in Bonn 281st Information Technology Battalion 282nd Information Technology Battalion 292nd Information Technology Battalion 293rd Information Technology Battalion 381st Information Technology Battalion 383rd Information Technology Battalion Bundeswehr Geoinformation Centre (Zentrum für Geoinformationswesen der Bundeswehr), in Euskirchen Bundeswehr Cyber-Security Centre (Zentrum für Cyber-Sicherheit der Bundeswehr ZCSBw) Bundeswehr Software Digitalisation Centre (Zentrum Digitalisierung der Bundeswehr und Fähigkeitsentwicklung Cyber- und Informationsraum ZDigBw) Bundeswehr Operational Communications Centre (Zentrum Operative Kommunikation der Bundeswehr ZOpKomBw) Training Centre CIDS (Ausbildungszentrum CIR AusbZ CIR)