China
Africa
Explore chapters and articles related to this topic
Generic Authentication Architecture and Generic Bootstrapping Architecture
Published in Giovanni Bartolomeo, Tatiana Kováčiková, Identification and Management of Distributed Data: NGN, Content-Centric Networks and the Web, 2016
Giovanni Bartolomeo, Tatiana Kováčiková
The use of Authentication Proxy (AP) is specified in 3GPP TS 33.222 (2004a). The AP in GAA is used to separate the GAA-specific authentication procedure and the Application Server (AS)–specific application logic to different logical entities. The AP is configured as a HTTP reverse proxy; that is, the fully qualified domain name (FQDN) of the AS is configured to the AP in such a way that the Internet Protocol (IP) traffic intended for the AS is directed to the AP by the network. The AP performs the GAA authentication of the UE. After the GAA authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy; that is, the AP forwards HTTP requests originating from the UE to the correct AS and returns the corresponding HTTP responses from the AS to the originating UE.
Content Delivery Network for Efficient Delivery of Internet Traffic
Published in Hassnaa Moustafa, Sherali Zeadally, Media Networks: Architectures, Applications, and Standards, 2016
Gilles Bertrand, Emile Stéphan
The redirection to a cache node can involve various mechanisms. The most common ones are the following: ■ The CDN resolves the fully qualified domain name (FQDN) of the URL used by the end user to request content and provides the IP address of the selected cache to the end user.■ The CDN uses the redirection message of an application protocol (e.g., HTTP 302 redirect) to ask the end-user’s browser to resend the content request to another URL, on the selected cache node.
Basic Session Description Protocol
Published in Radhika Ranjan Roy, Handbook of SDP for Multimedia Session Negotiations, 2018
The "o=" field gives the originator of the session (his/her username and the address of the user’s host) plus a session identifier and version number: <username> is the user’s login on the originating host, or it is "-" if the originating host does not support the concept of user identifications (IDs). The <username> MUST NOT contain spaces.<sess-id> is a numeric string such that the tuple of <username>, <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a globally unique identifier for the session. The method of <sess-id> allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) format timestamp be used to ensure uniqueness defined in RFC 5905 that obsoletes RFC 1305.<sess-version> is a version number for this session description. Its usage is up to the creating tool, as long as <sess-version> is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp be used.<nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet," but other values MAY be registered in the future (see Section 2.8).<addrtype> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 2.8).<unicast-address> is the address of the machine from which the session was created. For an address type of IP4, this is either the fully qualified domain name (FQDN) of the machine or the dotted decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully qualified domain name of the machine or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful (for example, a local address MUST NOT be included in an application-level referral that might leave the scope).
Comparison of Erlang/OTP and JADE implementations for standby redundancy in a holonic controller
Published in International Journal of Computer Integrated Manufacturing, 2019
G. T. Hawkridge, A. H. Basson, K. Kruger
Distribution in Erlang/OTP is achieved using nodes (instances of the BEAM virtual machine). Each distributed Erlang node must be given a unique name by which it can be referenced. A node can either use Erlang’s short naming scheme or long naming scheme, but all nodes must use the same naming scheme. During the case study implementation, it was found that the long naming scheme worked best for networks with domain names. The format of a long node name is (Name)@(FQDN), where (Name) is the unique node name (for that device) and (FQDN) is the Fully Qualified Domain Name of the host device. When a process sends a message to a process in a different node, the Erlang Port Mapper Daemon (EPMD) resolves the node name to the transport address for that node, i.e. the IP address and port for TCP/IP based distribution (Ericsson AB 2018a, 274).