In a network built of multiple, interconnected routers 'routing' determines which connection to use to send a message directly to its destination or one step closer to its destination.
The Dispatch router is an AMQP message router that provides advanced interconnect capabilities. It allows flexible routing of messages between any AMQP-enabled endpoints, whether they be clients, servers, brokers or any other entity that can send or receive standard AMQP messages.
A messaging client can make a single AMQP connection into a messaging bus built of Dispatch routers and, over that connection, exchange messages with one or more message brokers, and at the same time exchange messages directly with other endpoints without involving a broker at all.
The router is an intermediary for messages but it is not a broker. It does not take responsibility for messages. It will, however, propagate settlement and disposition across a network such that delivery guarantees are met. In other words: the router network will deliver the message, possibly via several intermediate routers, and it will route the acknowledgement of that message by the ultimate receiver back across the same path. This means that responsibility for the message is transfered from the original sender to the ultimate receiver as if they were directly connected. However this is done via a flexible network that allows highly configurable routing of the message transparent to both sender and receiver.
There are some patterns where this enables "brokerless messaging" approaches that are preferable to brokered approaches. In other cases a broker is essential (in particular where you need the separation of responsibility and/or the buffering provided by store-and-forward) but a dispatch network can still be useful to tie brokers and clients together into patterns that are difficult with a single broker.
For a "brokerless" example, consider the common brokered implementation of the request-response pattern, a client puts a request on a queue and then waits for a reply on another queue. In this case the broker can be a hindrance - the client may want to know immediatly if there is nobody to serve the request, but typically it can only wait for a timeout to discover this. With a dispatch network, the client can be informed immediately if its message cannot be delivered because nobody is listening. When the client receives acknowledgement of the request it knows not just that it is sitting on a queue, but that it has actually been received by the server.
For an exampe of using dispatch to enhance the use of brokers, consider using an array of brokers to implement a scalable distributed work queue. A dispatch network can make this appear as a single queue, with senders publishing to a single address and receivers subscribing to a single address. The dispatch network can distribute work to any broker in the array and collect work from any broker for any receiver. Brokers can be shut down or added without affecting clients. This elegantly solves the common difficulty of "stuck messages" when implementing this pattern with brokers alone. If a receiver is connected to a broker that has no messages, but there are messages on another broker, you have to somehow transfer them or leave them "stuck". With a dispatch network, all the receivers are connected to all the brokers. If there is a message anywhere it can be delivered to any receiver.
The router is meant to be deployed in topologies of multiple routers, preferably with redundant paths. It uses link-state routing protocols and algorithms (similar to OSPF or IS-IS from the networking world) to calculate the best path from every point to every other point and to recover quickly from failures. It does not need to use clustering for high availability; rather, it relies on redundant paths to provide continued connectivity in the face of system or network failure. Because it never takes responsibility for messages it is effectively stateless. Messages not delivered to their final destination will not be acknowledged to the sender and therefore the sender can re-send such messages if it is disconnected from the network.
Simplifies connectivity
An endpoint can do all of its messaging through a single transport connection
Avoid opening holes in firewalls for incoming connections
Provides messaging connectivity where there is no TCP/IP connectivity
A server or broker can be in a private IP network (behind a NAT firewall) and be accessible by messaging endpoints in other networks (learn more).
Simplifies reliability
Reliability and availability are provided using redundant topology, not server clustering
Reliable end-to-end messaging without persistent stores
Use a message broker only when you need store-and-forward semantics
Can be deployed stand-alone or in a network of routers
Supports arbitrary network topology - no restrictions on redundancy
Automatic route computation - adjusts quickly to changes in topology
Provides remote access to brokers or other AMQP servers
Security
This section introduces some key concepts about the router.
The router is an application layer program running as a normal user program or as a daemon.
The router accepts AMQP connections from clients and creates AMQP connections to brokers or AMQP-based services. The router classifies incoming AMQP messages and routes the messages between message producers and message consumers.
The router is meant to be deployed in topologies of multiple routers, preferably with redundant paths. It uses link-state routing protocols and algorithms similar to OSPF or IS-IS from the networking world to calculate the best path from every message source to every message destination and to recover quickly from failures. The router relies on redundant network paths to provide continued connectivity in the face of system or network failure.
A messaging client can make a single AMQP connection into a messaging bus built with routers and, over that connection, exchange messages with one or more message brokers connected to any router in the network. At the same time the client can exchange messages directly with other endpoints without involving a broker at all.
The router connects clients, servers, AMQP services, and other routers through network connections.
The router provides listeners that accept client connections. A client connecting to a router listener uses the same methods that it would use to connect to a broker. From the client’s perspective the router connection and link establishment are identical to broker connection and link establishment.
Several types of listeners are defined by their role.
Role |
Description |
normal |
The connection is used for AMQP clients using normal message delivery. |
inter-router |
The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. |
route-container |
The connection is a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the remote resource has created a connection. |
The router can also be configured to create outbound connections to messaging brokers or other AMQP entities using connectors. A connector is defined with the network address of the broker and the name or names of the resources that are available in that broker. When a router connects to a broker through a connector it uses the same methods a normal messaging client would use when connecting to the broker.
Several types of connectors are defined by their role.
Role |
Description |
normal |
The connection is used for AMQP clients using normal message delivery. On this connector the router will initiate the connection but it will never create any links. Links are to be created by the peer that accepts the connection. |
inter-router |
The connection is assumed to be to another router in the network. Inter-router discovery and routing protocols can only be used over inter-router connections. |
route-container |
The connection is to a broker or other resource that holds known addresses. The router will use this connection to create links as necessary. The addresses are available for routing only after the router has created a connection to the remote resource. |
AMQP addresses are used to control the flow of messages across a network of routers. Addresses are used in a number of different places in the AMQP 1.0 protocol. They can be used in a specific message in the to and reply-to fields of a message’s properties. They are also used during the creation of links in the address field of a source or a target.
|
Note
|
Addresses in this discussion refer to AMQP protocol addresses and not to TCP/IP network addresses. TCP/IP network addresses are used by messaging clients, brokers, and routers to create AMQP connections. AMQP protocol addresses are the names of source and destination endpoints for messages within the messaging network. |
Addresses designate various kinds of entities in a messaging network:
Endpoint processes that consume data or offer a service
Topics that match multiple consumers to multiple producers
Entities within a messaging broker:
Queues
Durable Topics
Exchanges
The syntax of an AMQP address is opaque as far as the router network is concerned. A syntactical structure may be used by the administrator who creates addresses but the router treats them as opaque strings.
The router maintains several classes of address based on how the address is configured or discovered.
Address Type |
Description |
mobile |
The address is a rendezvous point between senders and receivers. The router aggregates and serializes messages from senders and distributes messages to receivers. |
link route |
The address defines a private messaging path between a sender and a receiver. The router simply passes messages between the end points. |
Routers consider addresses to be mobile such that any users of an address may be directly connected to any router in a network and may move around the topology. In cases where messages are broadcast to or balanced across multiple consumers, the address users may be connected to multiple routers in the network.
Mobile addresses are rendezvous points for senders and receivers. Messages arrive at the mobile address and are dispatched to their destinations according to the routing defined for the mobile address. The details of these routing patterns are discussed later.
Mobile addresses may be discovered during normal router operation or configured through management settings.
Mobile addresses are created when a client creates a link to a source or destination address that is unknown to the router network.
Suppose a service provider wants to offer my-service that clients may use. The service provider must open a receiver link with source address my-service. The router creates a mobile address my-service and propagates the address so that it is known to every router in the network.
Later a client wants to use the service and creates a sending link with target address my-service. The router matches the service provider’s receiver having source address my-service to the client’s sender having target address my-service and routes messages between the two.
Any number of other clients can create links to the service as well. The clients do not have to know where in the router network the service provider is physically located nor are the clients required to connect to a specific router to use the service. Regardless of how many clients are using the service the service provider needs only a single connection and link into the router network.
Another view of this same scenario is when a client tries to use the service before service provider has connected to the network. In this case the router network creates the mobile address my-service as before. However, since the mobile address has only client sender links and no receiver links the router stalls the clients and prevents them from sending any messages. Later, after the service provider connects and creates the receiver link, the router will issue credits to the clients and the messages will begin to flow between the clients and the service.
The service provider can connect, disconnect, and reconnect from a different location without having to change any of the clients or their connections. Imagine having the service running on a laptop. One day the connection is from corporate headquarters and the next day the connection is from some remote location. In this case the service provider’s computer will typically have different host IP addresses for each connection. Using the router network the service provider connects to the router network and offers the named service and the clients connect to the router network and consume from the named service. The router network routes messages between the mobile addresses effectively masking host IP addresses of the service provider and the client systems.
Mobile addresses may be configured using the router autoLink object. An address created via an autoLink represents a queue, topic, or other service in an external broker. Logically the autoLink addresses are treated by the router network as if the broker had connected to the router and offered the services itself.
For each configured mobile address the router will create a single link to the external resource. Messages flow between sender links and receiver links the same regardless if the mobile address was discovered or configured.
Multiple autoLink objects may define the same address on multiple brokers. In this case the router network creates a sharded resource split between the brokers. Any client can seamlessly send and receive messages from either broker.
Note that the brokers do not need to be clustered or federated to receive this treatment. The brokers may even be from different vendors or be different versions of the same broker yet still work together to provide a larger service platform.
Link route addresses may be configured using the router linkRoute object. An link route address represents a queue, topic, or other service in an external broker similar to addresses configured by autoLink objects. For link route addresses the router propagates a separate link attachment to the broker resource for each incoming client link. The router does not automatically create any links to the broker resource.
Using link route addresses the router network does not participate in aggregated message distribution. The router simply passes message delivery and settlement between the two end points.
Addresses have semantics associated with them that are assigned when the address is provisioned or discovered. The semantics of an address control how routers behave when they see the address being used. Address semantics include the following considerations:
Routing pattern - balanced, closest, multicast
Routing mechanism - message routed, link routed
Routing patterns define the paths that a message with a mobile address can take across a network. These routing patterns can be used for both direct routing, in which the router distributes messages between clients without a broker, and indirect routing, in which the router enables clients to exchange messages through a broker.
Pattern |
Description |
Balanced |
An anycast method which allows multiple receivers to use the same address. In this case, messages (or links) are routed to exactly one of the receivers and the network attempts to balance the traffic load across the set of receivers using the same address. This routing delivers messages to receivers based on how quickly they settle the deliveries. Faster receivers get more messages. |
Closest |
An anycast method in which even if there are more receivers for the same address, every message is sent along the shortest path to reach the destination. This means that only one receiver will get the message. Each message is delivered to the closest receivers in terms of topology cost. If there are multiple receivers with the same lowest cost, deliveries will be spread evenly among those receivers. |
Multicast |
Having multiple consumers on the same address at the same time, messages are routed such that each consumer receives one copy of the message. |
The fact that addresses can be used in different ways suggests that message routing can be accomplished in different ways. Before going into the specifics of the different routing mechanisms, it would be good to first define what is meant by the term routing:
In a network built of multiple, interconnected routers 'routing' determines which connection to use to send a message directly to its destination or one step closer to its destination.
Each router serves as the terminus of a collection of incoming and outgoing links. Some of the links are designated for message routing, and others are designated for link routing. In both cases, the links either connect directly to endpoints that produce and consume messages, or they connect to other routers in the network along previously established connections.
Message routing occurs upon delivery of a message and is done based on the address in the message’s to field.
When a delivery arrives on an incoming message-routing link, the router extracts the address from the delivered message’s to field and looks the address up in its routing table. The lookup results in zero or more outgoing links onto which the message shall be resent.
Message routing can also occur without an address in the message’s to field if the incoming link has a target address. In fact, if the sender uses a link with a target address, the to field shall be ignored even if used.
Link routing occurs when a new link is attached to the router across one of its AMQP connections. It is done based on the target.address field of an inbound link and the source.address field of an outbound link.
Link routing uses the same routing table that message routing uses. The difference is that the routing occurs during the link-attach operation, and link attaches are propagated along the appropriate path to the destination. What results is a chain of links, connected end-to-end, from source to destination. It is similar to a virtual circuit in a telecom system.
Each router in the chain holds pairs of link termini that are tied together. The router then simply exchanges all deliveries, delivery state changes, and link state changes between the two termini.
The endpoints that use the link chain do not see any difference in behavior between a link chain and a single point-to-point link. All of the features available in the link protocol (flow control, transactional delivery, etc.) are available over a routed link-chain.
Messages may be delivered with varying degrees of reliability.
At most once
At least once
Exactly once
The reliability is negotiated between the client and server during link establishment. The router handles all levels of reliability by treating messages as either pre-settled or unsettled.
Delivery |
Handling |
pre-settled |
If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination. |
unsettled |
Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled. |
The router uses the SSL protocol and related certificates and SASL protocol mechanisms to encrypt and authenticate remote peers. Router listeners act as network servers and router connectors act as network clients. Both connection types may be configured securely with SSL and SASL.
The router Policy module is an optional authorization mechanism enforcing user connection restrictions and AMQP resource access control.
The default configuration file is installed in {CMAKE_INSTALL_PREFIX}/etc/qpid-dispatch/qdrouterd.conf. This configuration file will cause the router to run in standalone mode, listening on the standard AMQP port (5672). Dispatch Router looks for the configuration file in the installed location by default. If you wish to use a different path, the "-c" command line option will instruct Dispatch Router as to which configuration to load.
To run the router, invoke the executable: qdrouterd [-c my-config-file]
For more details of the configuration file see the qdrouterd.conf(5) man page.
qdstat is a command line tool that lets you view the status of a Dispatch Router. The following options are useful for seeing what the router is doing:
| Option | Description |
|---|---|
-l |
Print a list of AMQP links attached to the router. Links are unidirectional. Outgoing links are usually associated with a subscription address. The tool distinguishes between endpoint links and router links. Endpoint links are attached to clients using the router. Router links are attached to other routers in a network of routbers. |
-a |
Print a list of addresses known to the router. |
-n |
Print a list of known routers in the network. |
-c |
Print a list of connections to the router. |
--autolinks |
Print a list of configured auto-links. |
--linkroutes |
Print a list of configures link-routes. |
For complete details see the qdstat(8) man page and the output of
qdstat --help
.
qdmanage is a general-purpose AMQP management client that allows you to not only view but modify the configuration of a running dispatch router.
For example you can query all the connection entities in the router:
$ qdmanage query --type connection
To enable logging debug and higher level messages by default:
$ qdmanage update log/DEFAULT enable=debug+
In fact, everything that can be configured in the configuration file can also be created in a running router via management. For example to create a new listener in a running router:
$ qdmanage create type=listener port=5555
Now you can connect to port 5555, for exampple:
$ qdmanage query -b localhost:5555 --type listener
For complete details see the qdmanage(8) man page and the output of
qdmanage --help
. Also for details of what can be configured see the
qdrouterd.conf(5) man page.
The router can operate stand-alone or as a node in a network of routers. The mode is configured in the router section of the configuration file. In stand-alone mode, the router does not attempt to collaborate with any other routers and only routes messages among directly connected endpoints.
If your router is running in stand-alone mode, qdstat -a will look like the following:
$ qdstat -a Router Addresses class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc =============================================================================================================== local $_management_internal closest 1 0 0 0 0 0 0 0 0 local $displayname closest 1 0 0 0 0 0 0 0 0 mobile $management 0 closest 1 0 0 0 1 0 0 1 0 local $management closest 1 0 0 0 0 0 0 0 0 local temp.1GThUllfR7N+BDP closest 0 1 0 0 0 0 0 0 0
Note that there are a number of known addresses. $management is the address of the router’s embedded management agent. temp.1GThUllfR7N+BDP is the temporary reply-to address of the qdstat client making requests to the agent.
If you change the mode to interior and restart the processs, the same command will yield additional addresses which are used for inter-router communication:
$ qdstat -a Router Addresses class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc ================================================================================================================= local $_management_internal closest 1 0 0 0 0 0 0 0 0 local $displayname closest 1 0 0 0 0 0 0 0 0 mobile $management 0 closest 1 0 0 0 1 0 0 1 0 local $management closest 1 0 0 0 0 0 0 0 0 local qdhello flood 1 0 0 0 0 0 0 0 10 local qdrouter flood 1 0 0 0 0 0 0 0 0 topo qdrouter flood 1 0 0 0 0 0 0 0 1 local qdrouter.ma multicast 1 0 0 0 0 0 0 0 0 topo qdrouter.ma multicast 1 0 0 0 0 0 0 0 0 local temp.wfx54+zf+YWQF3T closest 0 1 0 0 0 0 0 0 0
The term "mobile subscriber" simply refers to the fact that a client may connect to the router and subscribe to an address to receive messages sent to that address. No matter where in the network the subscriber attaches, the messages will be routed to the appropriate destination.
To illustrate a subscription on a stand-alone router, you can use the examples that are provided with Qpid Proton. Using the simple_recv.py example receiver:
$ python ./simple_recv.py -a <IP_ADDRESS>/my-address
This command creates a receiving link subscribed to the specified address. To verify the subscription:
$ qdstat -a Router Addresses class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc =============================================================================================================== local $_management_internal closest 1 0 0 0 0 0 0 0 0 local $displayname closest 1 0 0 0 0 0 0 0 0 mobile $management 0 closest 1 0 0 0 2 0 0 2 0 local $management closest 1 0 0 0 0 0 0 0 0 mobile my-address 0 closest 0 1 0 0 0 0 0 0 0 local temp.75_d2X23x_KOT51 closest 0 1 0 0 0 0 0 0 0
You can then, in a separate command window, run a sender to produce messages to that address:
$ python ./simple_send.py -a <IP_ADDRESS>/my-address
Dynamic reply-to can be used to obtain a reply-to address that routes back to a client’s receiving link regardless of how many hops it has to take to get there. To illustrate this feature, see below a simple program (written in C++ against the qpid::messaging API) that queries the management agent of the attached router for a list of other known routers' management addresses.
#include <qpid/messaging/Address.h> #include <qpid/messaging/Connection.h> #include <qpid/messaging/Message.h> #include <qpid/messaging/Receiver.h> #include <qpid/messaging/Sender.h> #include <qpid/messaging/Session.h> using namespace qpid::messaging; using namespace qpid::types; using std::stringstream; using std::string; int main() { const char* url = "amqp:tcp:<IP_ADDRESS>:5672"; std::string connectionOptions = "{protocol:amqp1.0}"; Connection connection(url, connectionOptions); connection.open(); Session session = connection.createSession(); Sender sender = session.createSender("mgmt"); // create reply receiver and get the reply-to address Receiver receiver = session.createReceiver("#"); Address responseAddress = receiver.getAddress(); Message request; request.setReplyTo(responseAddress); request.setProperty("x-amqp-to", "amqp:/_local/$management"); request.setProperty("operation", "DISCOVER-MGMT-NODES"); request.setProperty("type", "org.amqp.management"); request.setProperty("name, "self"); sender.send(request); Message response = receiver.fetch(); Variant content(response.getContentObject()); std::cout << "Response: " << content << std::endl << std::endl; connection.close(); }
The equivalent program written in Python against the Proton Messenger API:
from proton import Messenger, Message def main(): host = "<IP_ADDRESS>:5672" messenger = Messenger() messenger.start() messenger.route("amqp:/*", "amqp://%s/$1" % host) reply_subscription = messenger.subscribe("amqp:/#") reply_address = reply_subscription.address request = Message() response = Message() request.address = "amqp:/_local/$management" request.reply_to = reply_address request.properties = {u'operation' : u'DISCOVER-MGMT-NODES', u'type' : u'org.amqp.management', u'name' : u'self'} messenger.put(request) messenger.send() messenger.recv() messenger.get(response) print "Response: %r" % response.body messenger.stop() main()
This feature was introduced in Qpid Dispatch 0.4. This feature was significantly updated in Qpid Dispatch 0.6.
Link-routing is an alternative strategy for routing messages across a network of routers. With the existing message-routing strategy, each router makes a routing decision on a per-message basis when the message is delivered. Link-routing is different because it makes routing decisions when link-attach frames arrive. A link is effectively chained across the network of routers from the establishing node to the destination node. Once the link is established, the transfer of message deliveries, flow frames, and dispositions is performed across the routed link.
The main benefit to link-routing is that endpoints can use the full link protocol to interact with other endpoints in far-flung parts of the network. For example, a client can establish a receiver across the network to a queue on a remote broker and use link credit to control the flow of messages from the broker. Similarly, a receiver can establish a link to a topic on a remote broker using a server-side filter.
Why would one want to do this? One reason is to provide client isolation. A network like the following can be deployed:
Public Network +-----------------+ | +-----+ | | B1 | Rp | | | +/--\-+ | | / \ | | / \ | +----/--------\---+ / \ / \ / \ Private Net A / \ Private Net B +--------------/--+ +---\-------------+ | +---/-+ | | +--\--+ | | B2 | Ra | | | | Rb | C1 | | +-----+ | | +-----+ | | | | | | | | | +-----------------+ +-----------------+
The clients in Private Net B can be constrained (by firewall policy) to only connect to the Router in their own network. Using link-routing, these clients can access queues, topics, and other AMQP services that are in the Public Network or even in Private Net A.
For example, The router Ra can be configured to expose queues in broker B2 to the network. Client C1 can then establish a connection to Rb, the local router, open a subscribing link to "b2.event-queue", and receive messages stored on that queue in broker B2.
C1 is unable to create a TCP/IP connection to B1 because of its isolation (and because B2 is itself in a private network). However, with link routing, C1 can interact with B2 using the AMQP link protocol.
Note that in this case, neither C1 nor B2 have been modified in any way and neither need be aware of the fact that there is a message-router network between them.
Starting with the configured topology shown above, how is link-routing configured to support the example described above?
First, router Ra needs to be told how to make a connection to the broker B2:
connector { name: broker role: route-container host: <B2-url> port: <B2-port> saslMechanisms: ANONYMOUS }
This route-container connector tells the router how to connect to an external AMQP container when it is needed. The name "broker" will be used later to refer to this connection.
Now, the router must be configured to route certain addresses to B2:
linkRoute { prefix: b2 dir: in connection: broker } linkRoute { prefix: b2 dir: out connection: broker }
The linkRoute tells router Ra that any sender or receiver that is attached with a target or source (respectively) whos address begins with "b2", should be routed to the broker B2 (via the route-container connector).
Note that receiving and sending links are configured and routed separately. This allows configuration of link routes for listeners only or senders only. A direction of "in" matches client senders (i.e. links that carry messages inbound to the router network). Direction "out" matches client receivers.
Examples of addresses that "begin with b2" include:
b2
b2.queues
b2.queues.app1
When the route-container connector is configured, router Ra establishes a connection to the broker. Once the connection is open, Ra tells the other routers (Rp and Rb) that it is a valid destination for link-routes to the "b2" prefix. This means that sender or receiver links attached to Rb or Rp will be routed via the shortest path to Ra where they are then routed outbound to the broker B2.
On Rp and Rb, it is advisable to add the identical configuration. It is permissible for a linkRoute configuration to reference a connection that does not exist.
This configuration tells the routers that link-routing is intended to be available for targets and sources starting with "b2". This is important because it is possible that B2 might be unavailable or shut off. If B2 is unreachable, Ra will not advertize itself as a destination for "b2" and the other routers might never know that "b2" was intended for link-routing.
The above configuration allows Rb and Rp to reject attaches that should be routed to B2 with an error message that indicates that there is no route available to the destination.
This feature was introduced in Qpid Dispatch 0.6. It is a significant improvement on an earlier somewhat experimental feature called Waypoints.
Auto-link is a feature of Qpid Dispatch Router that enables a router to actively attach a link to a node on an external AMQP container. The obvious application for this feature is to route messages through a queue on a broker, but other applications are possible as well.
An auto-link manages the lifecycle of one AMQP link. If messages are to be routed to and from a queue on a broker, then two auto-links are needed: one for sending messages to the queue and another for receiving messages from the queue. The container to which an auto-link attempts to attach may be identified in one of two ways:
The name of the connector/listener that resulted in the connection of the container, or
The AMQP container-id of the remote container.
Here is an example configuration for routing messages deliveries through a pair of queues on a broker:
connector { name: broker role: route-container host: <hostname> port: <port> saslMechanisms: ANONYMOUS } address { prefix: queue waypoint: yes } autoLink { addr: queue.first dir: in connection: broker } autoLink { addr: queue.first dir: out connection: broker } autoLink { addr: queue.second dir: in connection: broker } autoLink { addr: queue.second dir: out connection: broker }
The address
entity identifies a namespace queue. that will be used
for routing messages through queues via autolinks. The four autoLink
entities
identify the head and tail of two queues on the broker that will be connected
via auto-links.
If there is no broker connected, the auto-links shall remain
inactive. This can be observed by using the qdstat
tool:
$ qdstat --autolinks AutoLinks addr dir phs extAddr link status lastErr ======================================================== queue.first in 1 inactive queue.first out 0 inactive queue.second in 1 inactive queue.second out 0 inactive
If a broker comes online with a queue called queue.first, the auto-links will attempt to activate:
$ qdstat --autolinks AutoLinks addr dir phs extAddr link status lastErr =========================================================================== queue.first in 1 6 active queue.first out 0 7 active queue.second in 1 failed Node not found: queue.second queue.second out 0 failed Node not found: queue.second
Note that two of the auto-links are in failed state because the queue does not exist on the broker.
If we now use the Qpid Proton example application simple_send.py
to send
three messages to queue.first via the router:
$ python simple_send.py -a <IP_ADDRESS>/queue.first -m3 all messages confirmed
and then look at the address statistics on the router:
$ qdstat -a Router Addresses class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc ======================================================================================================== mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0 mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
we see that queue.first appears twice in the list of addresses. The
phs
, or phase column shows that there are two phases for the
address. Phase 0 is for routing message deliveries from producers to
the tail of the queue (the out
auto-link associated with the queue).
Phase 1 is for routing deliveries from the head of the queue to
subscribed consumers.
Note that three deliveries have been counted in the "in" and "out"
columns for phase 0. The "in" column represents the three messages
that arrived from simple_send.py
and the out
column represents the three
deliveries to the queue on the broker.
If we now use simple_recv.py
to receive three messages from this address:
$ python simple_recv.py -a <IP_ADDRESS>:5672/queue.first -m3 {u'sequence': int32(1)} {u'sequence': int32(2)} {u'sequence': int32(3)}
We receive the three queued messages. Looking at the addresses again, we see that phase 1 was used to deliver those messages from the queue to the consumer.
$ qdstat -a Router Addresses class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc ======================================================================================================== mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0 mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
Note that even in a multi-router network, and with multiple producers and consumers for queue.first, all deliveries will be routed through the queue on the connected broker.
Here is an extension of the above example to illustrate how Qpid Dispatch Router can be used to create a distributed queue in which multiple brokers share the message-queueing load.
connector { name: broker1 role: route-container host: <hostname> port: <port> saslMechanisms: ANONYMOUS } connector { name: broker2 role: route-container host: <hostname> port: <port> saslMechanisms: ANONYMOUS } address { prefix: queue waypoint: yes } autoLink { addr: queue.first dir: in connection: broker1 } autoLink { addr: queue.first dir: out connection: broker1 } autoLink { addr: queue.first dir: in connection: broker2 } autoLink { addr: queue.first dir: out connection: broker2 }
In the above configuration, there are two instances of queue.first on brokers 1 and 2. Message traffic from producers to address queue.first shall be balanced between the two instance and messages from the queues shall be balanced across the collection of subscribers to the same address.
Since configurable entities in the router can also be accessed via the
management protocol, we can remotely add a shard to the above example
using qdmanage
:
qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3 qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3 qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3
Sometimes, greater flexibility is needed with regard to the addressing
of a waypoint. For example, the above sharded-queue example requires
that the two instances of the queue have the same name/address.
Auto-links can be configured with an independent externalAddr
that
allows the waypoint to have a different address than that which is
used by the senders and receivers.
Here’s an example:
connector { name: broker role: route-container host: <hostname> port: <port> saslMechanisms: ANONYMOUS } address { prefix: queue waypoint: yes } autoLink { addr: queue.first externalAddr: broker_queue dir: in connection: broker } autoLink { addr: queue.first externalAddr: broker_queue dir: out connection: broker }
In the above configuration, the router network provides waypoint routing for the address queue.first, where senders and receivers use that address to send and receive messages. However, the queue on the broker is named "broker_queue". The address is translated through the auto-link that is established to the broker.
In this example, the endpoints (senders and receivers) are unaware of the broker_queue address and simply interact with queue.first. Likewise, the broker is unaware of the queue.first address and behaves as though a sender and a receiver is attached each using the address broker_queue.
The qdstat
tool shows the external address for auto-links.
$ qdstat --autolinks AutoLinks addr dir phs extAddr link status lastErr =========================================================== queue.first in 1 broker_queue 6 active queue.first out 0 broker_queue 7 active
The Policy module is an optional authorization mechanism enforcing user connection restrictions and AMQP resource access control.
Policy is assigned when a connection is created. The connection properties AMQP virtual host, authenticated user name, and connection remote host are passed to the policy engine for a connection allow/deny decision. If the connection is allowed then the user is assigned to a group that names a set of AMQP resource limits that are enforced for the lifetime of the connection.
|
Note
|
Policy limits are applied only to incoming user network connections. Policy limits are not applied to interrouter connections nor are they applied to router connections outbound to waypoints. |
A vhost is typically the name of the host to which the client AMQP connection is directed. For example, suppose a client application opens connection URL:
amqp://bigbroker.example.com:5672/favorite_subject
The client will signal virtual host name bigbroker.example.com to the router during AMQP connection startup. Router Policy intercepts the virtual host bigbroker.example.com and applies a vhost policy with that name to the connection.
A router may be configured with a total connection limit. This limit controls the maximum number of simultaneous incoming user connections that are allowed at any time. It protects the router from file descriptor resource exhaustion in the face of many incoming client connections. This limit is specified and enforced independently of any other Policy settings.
Vhost policy defines users and assigns them to user groups. Each user group defines the remote hosts from which the members may connect to the router network, and what resources in the router network the group members are allowed to access.
Vhost policy also defines connection count limits to control the number of users that may be simultaneously connected to the vhost.
|
Note
|
A vhost user may be assigned to one user group only. |
A default vhost may be defined. The default vhost policy is used for connections whose vhost is otherwise not defined in the policy database.
Example 2 illustrates how the default vhost feature can be used to apply a single vhost policy set of restrictions to any number of vhost connections.
Policy configuration is specified in two schema objects.
policy = { <global settings> } vhost = { id: vhost-name <connection limits> groups: { group-name: { <user group settings> } } }
The policy object is a singleton. Multiple vhost objects may be created as needed.
| attribute | default | description |
|---|---|---|
maxConnections |
65535 |
Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. |
enableVhostPolicy |
false |
Enable vhost policy connection denial, and resource limit enforcement. |
policyDir |
"" |
Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed. |
defaultVhost |
"$default" |
Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of defaultVhost or by not defining a vhost object named $default. |
| attribute | default | description |
|---|---|---|
id |
Vhost name must be unique. |
|
maxConnections |
65535 |
Maximum number of concurrent client connections allowed. |
maxConnectionsPerUser |
65535 |
Maximum number of concurrent client connections allowed for any user. |
maxConnectionsPerRemoteHost |
65535 |
Maximum number of concurrent client connections allowed for any remote host. |
allowUnknownUser |
false |
Allow unknown users who are not members of a defined user group. Unknown users are assigned to the $default user group and receive $default settings. |
groups |
A map where each key is a user group name and the value is a Vhost User Group Settings map. |
This object is the data value contained in entries in the policy/groups map.
| Section/Attribute | default | description |
|---|---|---|
Group Membership |
||
users |
"" |
Comma separated list of authenticated users in this group. |
Connection Restrictions |
||
remoteHosts |
"" |
List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard *. An empty list denies all access. |
AMQP Connection Open Limits |
||
maxFrameSize |
2^31-1 |
Largest frame that may be sent on this connection. (AMQP Open, max-frame-size) |
maxSessions |
65535 |
Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max) |
AMQP Session Begin Limits |
||
maxSessionWindow |
2^31-1 |
Incoming capacity for new sessions measured in octets. AMQP Begin, incoming-window measured in AMQP frames is calculated by (maxSessionWindow / maxFrameSize). (AMQP Begin, incoming-window) |
AMQP Link Attach |
||
maxMessageSize |
0 |
Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size) |
maxSenders |
2^31-1 |
Maximum number of sending links that may be created on this connection. |
maxReceivers |
2^31-1 |
Maximum number of receiving links that may be created on this connection. |
allowDynamicSource |
false |
This connection is allowed to create receiving links using the Dynamic Link Source feature. |
allowAnonymousSender |
false |
This connection is allowed to create sending links using the Anonymous Sender feature. |
allowUserIdProxy |
false |
This connection is allowed to send messages with a user_id property that differs from the connection’s authenticated user id. |
sources |
"" |
List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. |
targets |
"" |
List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. |
Policy provides several conventions to make writing rules easier.
Remote host rules may consist of a single asterisk character to specify all hosts.
remoteHosts: *
The asterisk must stand alone and cannot be appended to a host name or to an IP address fragment.
The rule definitions for sources
and targets
may include the username
substitution token
{user}
or a trailing asterisk.
The username substitution token is replaced with the authenticated user name for the connection. Using this token, an administrator may allow access to some resources specific to each user without having to name each user individually. This token is substituted once for the leftmost occurrence in the link name.
The asterisk is recognized only if it is the last character in the link name.
sources: tmp_{user}, temp*, {user}-home-*
This section shows policy examples designed to illustrate some common use cases.
Policy is disabled when no policy configuation objects are defined. Any number of connections are allowed and all users have access to all AMQP resources in the network.
This example shows how to keep users from overwhelming the router with connections. Any user can create up to ten connections and the router will limit the aggregated user connection count to 100 connections total. No other restrictions apply.
This example also shows how to use a default vhost policy effectively. Only one vhost policy is defined and all user connections regardless of the requested vhost use that policy.
policy { maxConnections: 100 (1) } vhost { name: $default (2) maxConnectionsPerUser: 10 (3) allowUnknownUser: true (4) groups: { $default: { remoteHosts: * (5) sources: * (6) targets: * (6) } } }
The global maxConnections limit of 100 is enforced.
No normal vhost names are defined; user is assigned to default vhost $default.
The vhost maxConnectionsPerUser limit of 10 is enforced.
No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default.
The user is allowed to connect from any remote host.
The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules.
This example shows how an admin group may be created and restricted to accessing a vhost only from localhost. The admin users are allowed to connect to any AMQP resources while normal users are restricted.
In this example a user connects to vhost example.com.
vhost { name: example.com (1) allowUnknownUser: true (3) groups: { admin: { users: alice, bob (2) remoteHosts: <IP_ADDRESS>, ::1 (4) sources: * (5) targets: * (5) }, $default: { remoteHosts: * (6) sources: news*, sports*, chat* (7) targets: chat* (7) } } }
A connection to vhost example.com locates this vhost rule set.
If one of users alice or bob is connecting then she or he is assigned to the admin user group.
Any other user is not defined by a user group. However, since the allowUnknownUser setting is true then this user is assigned to the $default user group.
Users in the admin user group must connect from localhost. Connections for an admin user from other hosts on the network are denied.
Users in the admin user group are allowed to access any resource offered by the vhost service.
Other users are allowed to connect from any host.
Other users have source and target name lists that restrict the resources they are allowed to access.
Policy provides a mechanism to control how much system buffer memory a user connection can potentially consume. The formula for computing buffer memory consumption for each session is set directly by maxSessionWindow.
By adjusting maxSessions, and maxSessionWindow an administrator can prevent a user from consuming too much memory by buffering messages in flight.
|
Note
|
The settings passed into the AMQP protocol connection and session negotiations. Normal AMQP session flow control limits buffer consumption in due course with no processing cycles required by the router. |
In this example normal users, the traders, are given smaller buffer allocations while high-capacity, automated data feeds are given a higher buffer allocation. This example skips the details of settings unrelated to buffer allocation.
vhost { name: traders.com (1) groups: { traders: { users: trader-1, trader-2, ... (2) maxFrameSize: 10000 (3) maxSessionWindow: 5000000 (3) maxSessions: 1 (4) ... }, feeds: { users: nyse-feed, nasdaq-feed (5) maxFrameSize: 60000 (6) maxSessionWindow:<PHONE_NUMBER> (6) maxSessions: 3 (7) ... } } }
These rules are for vhost traders.com.
The traders group includes trader-1, trader-2, and any other user defined in the list.
maxFrameSize and maxSessionWindow allow for at most 5,000,000 bytes of data to be in flight on each session.
Only one session per connection is allowed.
In the feeds group two users are defined.
maxFrameSize and maxSessionWindow allow for at most 1,200,000,000 bytes of data to be in flight on each session.
Up to three sessions per connection are allowed.
Dispatch Router should, in theory, work with any client that is compatible with AMQP 1.0. The following clients have been tested:
| Client | Notes |
|---|---|
qpid::messaging |
The Qpid messaging clients work with Dispatch Router as long as they are configured to use the 1.0 version of the protocol. To enable AMQP 1.0 in the C++ client, use the \{protocol:amqp1.0} connection option. |
Proton Reactor |
The Proton Reactor API is compatible with Dispatch Router. |
Proton Messenger |
Messenger works with Dispatch Router. |
AMQP addresses are used to control the flow of messages across a network
of routers. Addresses are used in a number of different places in the
AMQP 1.0 protocol. They can be used in a specific message in the to
and reply-to
fields of a message’s properties. They are also used
during the creation of links in the address
field of a source
or
a target
.
Addresses designate various kinds of entities in a messaging network:
Endpoint processes that consume data or offer a service
Topics that match multiple consumers to multiple producers
Entities within a messaging broker:
Queues
Durable Topics
Exchanges
The syntax of an AMQP address is opaque as far as the router network is concerned. A syntactical structure may be used by the administrator that creates addresses, but the router treats them as opaque strings. Routers consider addresses to be mobile such that any address may be directly connected to any router in a network and may move around the topology. In cases where messages are broadcast to or balanced across multiple consumers, an address may be connected to multiple routers in the network.
Addresses have semantics associated with them. When an address is created in the network, it is assigned a set of semantics (and access rules) during a process called provisioning. The semantics of an address control how routers behave when they see the address being used.
Address semantics include the following considerations:
Routing pattern - direct, multicast, balanced
Undeliverable action - drop, hold and retry, redirect
Reliability - N destinations, etc.
Routing patterns constrain the paths that a message can take across a network.
| Pattern | Description |
|---|---|
Direct |
Direct routing allows for only one consumer to use an address at a time. Messages (or links) follow the lowest cost path across the network from the sender to the one receiver. |
Multicast |
Multicast routing allows multiple consumers to use the same address at the same time. Messages are routed such that each consumer receives a copy of the message. |
Balanced |
Balanced routing also allows multiple consumers to use the same address. In this case, messages are routed to exactly one of the consumers, and the network attempts to balance the traffic load across the set of consumers using the same address. |
The fact that addresses can be used in different ways suggests that message routing can be accomplished in different ways. Before going into the specifics of the different routing mechanisms, it would be good to first define what is meant by the term routing:
In a network built of multiple routers connected by connections (i.e., nodes and edges in a graph), routing determines which connection to use to send a message directly to its destination or one step closer to its destination.
Each router serves as the terminus of a collection of incoming and outgoing links. The links either connect directly to endpoints that produce and consume messages, or they connect to other routers in the network along previously established connections.
Message routing occurs upon delivery of a message and is done based on
the address in the message’s to
field.
When a delivery arrives on an incoming link, the router extracts the
address from the delivered message’s to
field and looks the address up
in its routing table. The lookup results in zero or more outgoing links
onto which the message shall be resent.
| Delivery | Handling |
|---|---|
pre-settled |
If the arriving delivery is pre-settled (i.e., fire and forget), the incoming delivery shall be settled by the router, and the outgoing deliveries shall also be pre-settled. In other words, the pre-settled nature of the message delivery is propagated across the network to the message’s destination. |
unsettled |
Unsettled delivery is also propagated across the network. Because unsettled delivery records cannot be discarded, the router tracks the incoming deliveries and keeps the association of the incoming deliveries to the resulting outgoing deliveries. This kept association allows the router to continue to propagate changes in delivery state (settlement and disposition) back and forth along the path which the message traveled. |
Dispatch Router is an AMQP router and as such, it provides extensions, code-points, and semantics for routing over AMQP. This page documents the details of Dispatch Router’s use of AMQP.
The following Message Annotation fields are defined by Dispatch Router:
| Field | Type | Description |
|---|---|---|
x-opt-qd.ingress |
string |
The identity of the ingress router for a message-routed message. The ingress router is the first router encountered by a transiting message. The router will, if this field is present, leave it unaltered. If the field is not present, the router shall insert the field with its own identity. |
x-opt-qd.trace |
list of string |
The list of routers through which this message-routed message has transited. If this field is not present, the router shall do nothing. If the field is present, the router shall append its own identity to the end of the list. |
x-opt-qd.to |
string |
To-Override for message-routed messages. If this field is present, the address in this field shall be used for routing in lieu of the to field in the message properties. A router may append, remove, or modify this annotation field depending on the policy in place for routing the message. |
x-opt-qd.phase |
integer |
The address-phase, if not zero, for messages flowing between routers. |
The following Capability values are used in Sources and Targets.
| Capability | Description |
|---|---|
qd.router |
This capability is added to sources and targets that are used for inter-router message exchange. This capability denotes a link used for router-control messages flowing between routers. |
qd.router-data |
This capability is added to sources and targets that are used for inter-router message exchange. This capability denotes a link used for user messages being message-routed across an inter-router connection. |
The following dynamic-node-properties are used by Dispatch in Sources.
| Property | Description |
|---|---|
x-opt-qd.address |
The node address describing the destination desired for a dynamic source. If this is absent, the router will terminate any dynamic receivers. If this address is present, the router will use the address to route the dynamic link attach to the proper destination container. |
The following AMQP addresses and address patterns are used within Dispatch Router.
| Pattern | Description |
|---|---|
|
An address that references a locally attached endpoint. Messages using this address pattern shall not be routed over more than one link. |
|
An address that references an endpoint attached to a specific router node in the network topology. Messages with addresses that follow this pattern shall be routed along the shortest path to the specified router. Note that addresses of this form are a-priori routable in that the address itself contains enough information to route the message to its destination. The 0 component immediately preceding the router-id is a placeholder for an area which may be used in the future if area routing is implemented. |
|
A mobile address. An address of this format represents an endpoint or a set of distinct endpoints that are attached to the network in arbitrary locations. It is the responsibility of the router network to determine which router nodes are valid destinations for mobile addresses. |
| Address | Description |
|---|---|
|
The management agent on the attached router/container. This address would be used by an endpoint that is a management client/console/tool wishing to access management data from the attached container. |
|
The management agent at Router.E in area 0. This address would be used by a management client wishing to access management data from a specific container that is reachable within the network. |
|
The router entity in each of the connected routers. This address is used to communicate with neighbor routers and is exclusively for the HELLO discovery protocol. |
|
The router entity in each of the connected routers. This address is used by a router to communicate with other routers in the network. |
|
The router entity at the specifically indicated router. This address form is used by a router to communicate with a specific router that may or may not be a neighbor. |
Qpid Dispatch is manageable remotely via AMQP. It is compliant with the emerging AMQP Management specification (draft 9).
Differences from the specification:
The name
attribute is not required when an entity is created. If
not supplied it will be set to the same value as the system-generated
"identity" attribute. Otherwise it is treated as per the standard.
The REGISTER
and DEREGISTER
operations are not implemented. The router
automatically discovers peer routers via the router network and makes
their management addresses available via the standard GET-MGMT-NODES
operation.
Unresolved directive in book.adoc - include::{generated_book}/schema.adoc[]
The console is an HTML based web site that displays information about a qpid dispatch router network.
The console requires an HTML web server that can serve static html, javascript, style sheets, and images.
The console only provides limited information about the clients that are attached to the router network and is therfore more appropriate for administrators needing to know the layout and health of the router network.
The following need to be installed before running a console:
One or more dispatch routers. See the documentation for the dispatch router for help in starting a router network.
A websockets to tcp proxy.
A web server. This can be any server capable of serving static html/js/css/image files.
To install a websockets to tcp proxy:
sudo dnf install python-websockify websockify localhost:5673 localhost:5672
This will start the proxy listening to ws traffic on port 5673 and translating it to tcp on port 5672. One of the routers in the network needs to have a listener configured on port 5672. That listener’s role should be normal. For example:
listener { host: <IP_ADDRESS> role: normal port: amqp saslMechanisms: ANONYMOUS }
The files for the console are located under the console/stand-alone directory in the source tree * index.html * plugin/
Copy these files to a directory under the the html or webapps directory of your web server. For example, for apache tomcat the files should be under webapps/dispatch. Then the console is available as http://localhost:8080/dispatch
Enter the address of the websockets to tcp proxy that is connected to a router in the network.
The Autostart checkbox, when checked, will automatically log in with the previous host:port the next time you start the console.
On the overview page, aggregate information about routers, addresses, and connections is displayed.
This page displays the router network in a graphical form showing how the routers are connected and information about the individual routers and links.
Displays detailed information about entities such as routers, links, addresses, memory.
This page displays graphs of numeric values that are on the list page.
This page displays the json schema that is used to manage the router network.
Apache Qpid, Messaging built on AMQP; Copyright © 2015 The Apache Software Foundation; Licensed under the Apache License, Version 2.0; Apache Qpid, Qpid, Qpid Proton, Proton, Apache, the Apache feather logo, and the Apache Qpid project logo are trademarks of The Apache Software Foundation; All other marks mentioned may be trademarks or registered trademarks of their respective owners


java.lang.Object greenfoot.World MyWorld
public class MyWorld
Write a description of class MyWorld here.
| Field Summary | |
|---|---|
int |
hor
|
int |
i
Constructor for objects of class MyWorld. |
int |
noRocaH1
Constructor for objects of class MyWorld. |
int |
noRocaH2
Constructor for objects of class MyWorld. |
int |
noRocaV1
Constructor for objects of class MyWorld. |
int |
noRocaV2
Constructor for objects of class MyWorld. |
int |
ver
|
int |
x
|
int |
y
Constructor for objects of class MyWorld. |
| Constructor Summary | |
|---|---|
MyWorld()
|
| Method Summary | |
|---|---|
void |
colocarRoca(int hor,
int ver)
|
void |
crearLaberinto()
|
boolean |
sePuedePonerRocaV(int lugar,
int nRoca)
|
| Methods inherited from class greenfoot.World |
|---|
act, addObject, getBackground, getCellSize, getColorAt, getHeight, getObjects, getObjectsAt, getWidth, numberOfObjects, removeObject, removeObjects, repaint, setActOrder, setBackground, setBackground, setPaintOrder, showText, started, stopped |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
|---|
public int hor
public int i
public int noRocaH1
public int noRocaH2
public int noRocaV1
public int noRocaV2
public int ver
public int x
public int y
| Constructor Detail |
|---|
public MyWorld()
| Method Detail |
|---|
public void colocarRoca(int hor, int ver)
public void crearLaberinto()
public boolean sePuedePonerRocaV(int lugar, int nRoca)


System Architect Symbol details for "Subject Identifier"
domain (Association)
- From Class:
"Identifier Domain"
- To Class:
"Identifier In Domain"
- From Class:
"Identifier Domain"
- To Class:
"Identifier In Domain"
Identifier Domain (Class)
- Child Diagrams:
-
Identifier Domain (
OMT Object Model)
- Description:
Means by which an "Agent" may collect two or more "Identifiers In Domain".
Identifier In Domain (Class)
- Child Diagrams:
-
Identifier In Domain (
OMT Object Model)
- Description:
"Subject Identifier" which is unique within an "Identifier Domain".
SI/Uniqueness (Generalization Node)
- Base Class:
"Subject Identifier"
- Definitions Used:
-
Subject Identifier (Class)
subject (Association)
- From Class:
Subject
- To Class:
"Subject Identifier"
- From Class:
Subject
- To Class:
"Subject Identifier"
Subject (Class)
- Description:
"Percept" consisting of one or more persistent physical objects.
- Comment:
-
The definition above, as for others, has been distilled from what has been suggested in the past,
including:
The "Object" of interest to an "Agent" (CBS v2).
One or a collection of physical objects.
"Percept" which is a physical object and / or a collection of physical objects.
Persistent perceivable object.
Extension of one or more "Concepts" which is perceived or inferred to exist in the universe.
Subject Contact (Class)
- Child Diagrams:
-
Subject Contact (
OMT Object Model)
- Description:
"Subject Identifier" being a means by which the Subject may receive communications.
Subject Identifier (Class)
- Description:
Assigned symbol or term to discriminate the "Subject" from others.
- Comment:
-
May not uniquely discriminate a "Subject" from all others. Any "Subject Property" or "Subject
Identifier" may be used for discrimination. A Subject Identifier is unique only where it occurs as a
"Unique Identifier In Domain".
subject identifier for (Association)
- From Class:
"Subject Identifier"
- To Class:
"Subject Identifier State"
- From Class:
"Subject Identifier"
- To Class:
"Subject Identifier State"
Subject Identifier State (Class)
- Child Diagrams:
-
Subject Identifier State (
OMT Object Model)
- Description:
"Subject Identifier" in a state which it is currently or has been previously.
- Comment:
Note that there are both subtypes (comprising all the possible states) and a "power type" of
"Subject Identifier State Type". The latter's contents are identical to the subtypes; it exists in
order to control topics such as access and permission to amend.
Subject Name (Class)
- Child Diagrams:
-
Subject Name (
OMT Object Model)
- Description:
"Subject Identifier" being a specific and ordered combination of words and titles not in a specific
"Identifier Domain".
- Comment:
From PJR July 97. Note that there is no suggestion that a Name is unique.
- Definitions Used:
-
Name (Class Attribute)


A partner beyond expectation
HORIZON Bank believes that as the name suggests which can only be observed when it lies on the sea surface. Like that we observe your business and know how to help you get the most out of it. Our bankers have an in-depth knowledge of your community . our bank is the most most popular bank among business community.we have more than 100+ branches across the world
| We're here to help you! |
|


Today we are announcing our Call for Proposals and ticket sales. Speaking at Write the Docs is a fantastic way to share your ideas with our wonderful community of documentarians.
Although the general focus of Write the Docs is on documentation, there's a strong emphasis on the software industry. Within that thematic scope, we love having wide-ranging content that will stretch people in new directions.
Some of our favorite talks are ones that make people see the world in a new way. Teaching entirely new ideas to others can be magical, and we are always delighted with the breadth of knowledge that our community brings together.
We love talks that deliver hard-earned knowledge based on real-world experience and research. Whether it's a story about spreading the documentarian gospel in your company or tips and tricks for writing that you've learned, come share it with people who are eager to know.
We believe that tech writing and documentation don't always get the respect and consideration they deserve. Come share the problems with documentation your company overcame, or how you ensure documentation is an organizational priority.
You can read our full Call for Proposals on the website.
Write the Docs is a community event, organized and run by volunteers. The conference does not generate any income, and all revenue from ticket sales and sponsorships goes towards improving the conference. We believe that everyone who cares about this topic has a place at our event.
This year, our ticket prices will ensure that the absolute cost of the conference is covered, with revenue from sponsorships used to extend the conference and make it substantially more awesome.
If you can't afford these prices and still wish to attend, please email us at<EMAIL_ADDRESS>and we can work something out.
As with the previous years, we have tiered pricing to make it fair for everyone. Please buy the ticket that best fits your situation.
Tickets are on sale now. Buy them now.
Purchase this ticket if a company is paying for your attendance.
Purchase this ticket if you are paying for yourself, work at a non-profit, or at a company with less than 10 employees.
Purchase this ticket if you are currently enrolled as a student, or don't currently have a source of income.
We hope you will join us at Write the Docs again this year. Whether as a speaker or attendee, you can bet it will be another delightful year.


{% extends "base_settings.html" %} {% block developerappstab %}class="active"{% endblock%} {% block setting_content %}
| Name | Client ID |
|---|---|
| {{ application.name }} | {{ application.client_id }} |
Developer applications are used for enhanced access to the NeuroVault API.
Register an application to get started.


This class is the master class for all Fedex request objects. It gets
all of the common SOAP objects created via suds and populates them with
values from a FedexConfig object, along with keyword arguments via __init__.
|
|
__init__(self,
config_obj,
wsdl_name,
*args,
**kwargs)
This constructor should only be called by children of the class. |
source code
|
|
|
|
|
|
|
__set_client_detail(self)
Sets up the ClientDetail node, which is required for all shipping
related requests. |
source code
|
|
|
|
__set_transaction_detail(self,
*args,
**kwargs)
Checks kwargs for 'customer_transaction_id' and sets it if present. |
source code
|
|
|
|
__set_version_id(self)
Pulles the versioning info for the request from the child request. |
source code
|
|
|
|
|
|
|
__check_response_for_fedex_error(self)
This checks the response for general Fedex errors that aren't related
to any one WSDL. |
source code
|
|
|
|
|
|
|
create_wsdl_object_of_type(self,
type_name)
Creates and returns a WSDL object of the specified type. |
source code
|
|
|
|
|
|
Inherited from object :
__delattr__ ,
__format__ ,
__getattribute__ ,
__hash__ ,
__new__ ,
__reduce__ ,
__reduce_ex__ ,
__repr__ ,
__setattr__ ,
__sizeof__ ,
__str__ ,
__subclasshook__
|


Hello {{ .Name }},
Your TRISA network registration has been approved! Your organization has been granted identity certificates validating your membership to other TRISA members via the TRISA Global Directory. Attached to this email are PKCS12 encrypted certificates so that you can implement the TRISA protocol using mTLS with other network members to exchange Travel Rule compliance information.
The primary details of your directory entry are as follows:
To decrypt your certificates, you will need the PKCS12 password that you
received when you first submitted your registration. To decrypt the unzipped certificates on the
command line, you can use openssl
as follows (you will be prompted to enter your password):
$ openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nodes
For more information on integrating with the TRISA network, please see our documentation at trisatest.net. If you have any questions, you may contact us at<EMAIL_ADDRESS>or join us on our Slack channel. Please do not reply directly to this email.
Best Regards,
TRISA Global Directory Service Team


This is just a quick writeup on how to use GIS files to visualize some data from Open Data. The idea was to visualize the water consumption of the different wards of Toronto. I have a bit of an easy point to make. My guess is that that the richer you are the more water you consume. The water consumption of each ward is available here. The data is water consumption for each ward from 2000 to 2013.
First I read in the data for 2000 and 2013.
water.2000 = read.csv('CoT_Water_Consumption/Water_Consumption_2000.csv', header = T)
water.2013 = read.csv('CoT_Water_Consumption/Water_Consumption_2013.csv', header = T)
There is data for commercial accounts and residential accounts. The ammounts are all in metres cubed. Here’s a quick look at the data for the first 3 wards.
| city.ward | year | residential.accounts | annual.residential.usage | average.residential.usage |
|---|---|---|---|---|
| 1 | 2000 | 8001 | 3205060 | 400.58 |
| 2 | 2000 | 9909 | 3567371 | 360.01 |
| 3 | 2000 | 10389 | 2821739 | 271.61 |
| city.ward | year | commercial.accounts | annual.commercial.usage | average.commercial.usage |
|---|---|---|---|---|
| 1 | 2000 | 148 | 4730288 | 31961.41 |
| 2 | 2000 | 245 | 12607962 | 51461.07 |
| 3 | 2000 | 97 | 3094197 | 31898.94 |
Here is a quick plot of average water consumption over the years. I faceted the data according to whether it was residential or commercial use.
So the ammount of average water consumption looks like it has been going down over the years. This is a little unexpected and heartening for me. I was also interested in seeing how the water consumption varies throughout the different wards of Toronto. Who is using the most water? I thought a good visualization of this would be to construct a heat map of the water consumption. To do this I used the GIS information for ward boundaries available at open data Toronto.
First read in the shape file and rotate it so that the topmost boundary is more or less flat.
library(maptools)
ward.map = readShapeSpatial('gcc/icitw_wgs84.shp',
proj4string = CRS("+proj=longlat +datum=WGS84") )
ward.map = elide(ward.map, rotate=13)
Next I use fortify to turn the spatial object into a data frame. Then I use ggplot to map it and the polygons that are the ward boundaries.
library(rgeos)
ward.map.df = fortify(ward.map, region = "SCODE_NAME")
ward.map.df$id = as.integer(ward.map.df$id) #fixes ward labels
ggplot(data=ward.map.df, aes(x=long, y=lat, group=group)) +
geom_polygon(fill = NA, colour = 'black') +
map.theme #theme for map plots not defined here
This looks very basic. I’ll add the ward numbers to each ward and make that heat map. The first step is to merge the water data and map data together. I also find the centroids of each polygon and label them according to the ward. I will use this labeling to identify the wards in the final plot.
# merge the water data and map data together
total.df = merge(ward.map.df, water, by.x = 'id', by.y = 'city.ward')
total.df = total.df[order(total.df$order), ]
#find centroids of polygons for ward labelling
centroids = as.data.frame(gCentroid(ward.map, byid = T))
# keep track of which polygon the centroid is in
centroids[['id']] = ward.map@data$SCODE_NAME
Now I can make that heat map. Here are the residential maps. (I didn’t include the code for the 2013 map since it would be redundant.)
total.df.2000 = total.df[total.df$year==2000,]
pAverageResidential <- ggplot(data = total.df.2000, aes(x = long, y = lat, group = group)) +
geom_polygon(aes(fill = average.residential.usage), color = 'red', alpha = 0.6) +
scale_fill_gradient(name = 'Average residential\nusage in metres cubed',
low = "cyan3", high = "blue3") +
labs(title = "Average Toronto Residential Water Usage in 2000")
pAverageResidential +
map.theme + #theme for a map plot I defined earlier
geom_text(aes(x=x,y=y, group=NULL, label=id), data = centroids, size=2) #ward labels
So water consumption throughout Toronto has gone down but still the downtown core definitely seems to be using the most water. And in particular, ward 20, the Trinity-Spadina area of Toronto is using quite a bit more water per person than the rest of Toronto. I really don’t have any good idea why this might be. I initially thought the wealthier areas of Toronto would consume more water. The simplest factor I had in mind was swimming pools. But it looks like this does not matter so much.
Here are the maps for commercial water consumption. It looks like ward 2, Etobicoke, is the heavy user of water commercially. Any ideas why this would be the case?


{% extends 'base.html' %} {% block content %}
you are now emulating {{ user.username }}.
{% else %}Hi {{ user.username }}! Try emulating a user from the menu. Make sure you've created another user in the db first!
{% endif %} {% else %}Doesn't look like you've logged in yet. Login from nav menu.
{% endif %}


COVID National Park Info
About
NATIONAL PARKS
in the
PANDEMIC
Choose a state to see the coronavirus information and parks you can visit!
Please select...
Alabama
Alaska
Arizona
Arkansas
California
Colorado
Connecticut
Delaware
Florida
Georgia
Hawaii
Idaho
Illinois
Indiana
Iowa
Kansas
Kentucky
Louisiana
Maine
Maryland
Massachusetts
Michigan
Minnesota
Mississippi
Missouri
Montana
Nebraska
Nevada
New Hampshire
New Jersey
New Mexico
New York
North Carolina
North Dakota
Ohio
Oklahoma
Oregon
Pennsylvania
Rhode Island
South Carolina
South Dakota
Tennessee
Texas
Utah
Vermont
Virginia
Washington
West Virginia
Wisconsin
Wyoming
Search
State
Deaths:
Positive Cases:
Current Hospitilizations:
Recovered:


↜About Us↝
======= <<<<<<< HEAD <<<<<<< HEAD ======= >>>>>>> d184dd4cfc38c1e43d2aeda89f18e2bc678ed50a <<<<<<< HEAD↜About Us↝
======= >>>>>>> d16f7e303373f7aa06afeff3a1c36aeb8d5b1a6a ======= >>>>>>> d16f7e303373f7aa06afeff3a1c36aeb8d5b1a6a <<<<<<< HEAD >>>>>>> d184dd4cfc38c1e43d2aeda89f18e2bc678ed50a ======= >>>>>>> d184dd4cfc38c1e43d2aeda89f18e2bc678ed50a ======= >>>>>>> d16f7e303373f7aa06afeff3a1c36aeb8d5b1a6a ======= >>>>>>> d16f7e303373f7aa06afeff3a1c36aeb8d5b1a6a >>>>>>> d184dd4cfc38c1e43d2aeda89f18e2bc678ed50a◈ About Yureka Institute
Yureka Educational institute stands today as one of the most success education provider in Galle district for nearly 10 years. We always giving our contribution toward education to uplift the knowledge of students and also to promote the rich culture of education despite being a profit oriented institute. We are currently having all the major courses focusing for Advanced Level and Ordinary Level examinations and also we are having brilliant and qualified panel of teachers who gives their best for the knowledge of students.
We are also providing good facilities for the students to make a better learning environment and concentrating on quality of teaching methods. Our aim is to develop knowledge, skills and attitude of our students by providing required educational background. As a result of that, currently we have over 1000 students who have joined to be a part of our family to get knowledge and to be winners. By providing quality services and good teaching methods with the support of our committed staff we are always willing to shape the knowledge of our students.
◈ Our Mission
Provide students with quality education and guide them towards the success to reach their highest potential.
◈ Our Vision
To be a leader in preparing qualified and exemplary educated students to the society.


 Have a project in mind? HIRE US
We are a small team of creatives who dare to solve big problems. Have a project in mind?


Maher rips Hillary Clinton's 2020 tease: 'Someone needs to put Xanax in her hot sauce'
by Joseph Wulfsohn"Real Time" host Bill Maher offered a blunt rejection to Hillary Clinton after she said "never say never" when asked about a potential 2020 run.
Earlier this week, the former Secretary of State was pressed about the possibility of her entering the Democratic field as former New York City Mayor Michael Bloomberg began filing to qualify in state primaries and later former Massachusetts Governor Deval Patrick formally launched his campaign.
“I, as I say, never, never, never say never,” Clinton told BBC Radio. “I will certainly tell you, I’m under enormous pressure from many, many, many people to think about it.”
Clinton added: “But as of this moment, sitting here in this studio talking to you, that is absolutely not in my plans."
The HBO star, however, wasn't exactly on board.
BILL MAHER SAYS TRUMP IMPEACHMENT HEARINGS COULD GIVE VOTERS 'INVESTIGATION FATIGUE'
"Just, no," Maher told an audience member who clapped in support of Clinton. "Somone needs to put some Xanax in her hot sauce."
"Here's her quote. She said, 'I say, never, never, never say never. I will certainly tell you, I’m under enormous pressure from many, many, many people to think about it.' Yes, those are Trump supporters... C'mon!"
Fox News contributor Donna Brazile offered a defense for Clinton, saying it's not her "job" as the former DNC chairwoman to "say no to anybody."
"It's my job- don't do it!" Maher exclaimed.
CLIVE OWEN CAST AS BILL CLINTON IN: 'IMPEACHMENT: AMERICAN CRIME STORY'
Last month, Maher urged both Hillary Clinton and former President Bill Clinton to not attend the Democratic convention next year.
"The Clintons... they've got to go away," Maher said. "I'm saying this a year out... They can't be at the convention. Maybe on the video, waving or something, but I’m serious.”
Maher then referred to a Twitter message posted by Rep. Justin Amash, I-Mich., who called Hillary Clinton a "Donald Trump asset" in reaction to her claim that Rep. Tulsi Gabbard, D-Hawaii, was a "Russian asset" who was being "groomed" to run as a third-party candidate in 2020.
CLICK HERE FOR THE FOX NEWS APP
"She is!" Maher agreed. "And Bill is damaged goods. And I just think they've got to go away. We can't be associating them with the Democratic Party."


{{ page.title }}
• Since March 2021, I'm part of Prof. Julia Verne's team at the Geography Department of the the University of Mainz.
• Between October 2016 and February 2021, I worked as a postdoctoral researcher at the Geography Department of the University of Bonn, in the research group of Prof. Julia Verne.
• I worked as a digital anthropologist in the ChemicalYouth group at the Anthropology Department of the University of Amsterdam from 2015 to 2016.
• In October 2016, I defended my Ph.D. (2012-2016) in Cultural Anthropology, supervised by Prof. dr. Ton Robben and Dr. Martijn Oosterbaan at Utrecht University.
• Magistra Artium (2005-2010) in Cultural Anthropology supervised by Prof. Bo Sax from the University of Heidelberg.
{{ content }}


{% extends 'layout.html' %} {% block content %}
Family Package
$30
Single Package
$8
Couple Package
$20


Statements about my dog: a statement here
| cell contents get written here |
Statements about my dog: Her bark is loud. Her color is black.
| r0c0 | r0c1 |
| r1c0 | r1c1 |
This entire paragraph will be replaced.
This survives.
This doesn't.
This survives.
This paragraph will only be given a class name if addClass is true.
This paragraph will only be given a class name if addClass is true.
This content will be substituted with the value of the "greeting" variable.
Hello World!


General support queries. User Guides: https://support.komodoplatform.com/ Support staff: Angelina#6231 gcharang#6833. If you want to ask JL777 a question, use the #ask-jl777 channel.
100 messages
Before 05-Dec-19 12:00 AM
SHossain03-Jul-19 03:32 PM
wallet.dat for same coin works without changing
CryptoPope03-Jul-19 03:34 PM
my ZEX is in the AGAMA wallet. Looking in the AppData folder I do not see a wallet.dat. Is exporting within the AGAMA wallet what you're referring to?

CryptoPopeToday at 16:18
running the agama 0.3.2a wallet. I'm attempting to get priv keys under settings. I've selected the ZEX coin and have clicked "Fetch Key's. How long should it take to show these keys?
the guide shows exactly how to get your private key for any address in native mode
CryptoPope03-Jul-19 03:42 PM
wif key = priv key correct? If so I have that.
SHossain03-Jul-19 03:42 PM
wif key = priv key
CryptoPope03-Jul-19 03:42 PM
ok
SHossain03-Jul-19 03:43 PM
that's in the title of the article i posted Export Private Keys (WIF)
Can the existence of a wallet.dat file interfere with seed word/PIN entry. In other words if I move the wallet.dat somewhere else might I get different results in a)Native mode or b) quick mode?
CryptoPope03-Jul-19 03:45 PM
do you recommend waiting for the DO wallet to complete the sync prior to importing?
SHossain03-Jul-19 03:46 PM
@TheFalseProfit Lite mode and Native mode are completely different and they DO NOT interfare with each other
@CryptoPope import keys after your wallet is 100% in sync
1
TheFalseProfit03-Jul-19 03:49 PM
I have my Native mode synched but every time I start it up it takes over an hour before it finishes "loading data please wait". I'm assuming that is normal.
SHossain03-Jul-19 03:51 PM
that is normal if you use native mode occassionally. every time you start it has to sync remaining blocks
SHossain03-Jul-19 07:04 PM
banned
TheFalseProfit03-Jul-19 10:08 PM
Why does agama always have a pre-filled PIN Name when logging in that seemingly cannot be changed? There's no wallet.dat present if that matters.
Where is it getting that pre-fill PIN from?
TheFalseProfit03-Jul-19 10:46 PM
I just used the cross asset tool on my old compromised wallet and discovered I have NINJA, PIZZA and VOTE2019. I already received my KMD in a new address. What do I do with these?(edited)
CryptoPope03-Jul-19 10:46 PM
Which wallet if preferred to claim the RFOX drop?
I'm syncing the Komodo Ocean wallet but it's taking fooorrreeevverrrr.
Thought I would give the Agama 0.5.7-3 a try.(edited)
Is it true that if I enter the seed words correctly it will ALWAYS show the same address in Lite Mode? Or can Seed words be associated with many address's? Can I assume that if the address is different I MUST have mis-entered the Seed words?(edited)
Download the 10.9GB file. Use 7-zip to unzip. I then used Winrar to unzip the next bit. Move or copy the two folders to the komodo folder in C:\Users\YOUR USER NAME\AppData\Roaming\Komodo overwriting the original folders. %appdata%komodo may also get you there.(edited)
CryptoPope03-Jul-19 11:09 PM
noted for future, thank you. I'm halfway through the sync in the qt. I'll just let it run.
TheFalseProfit03-Jul-19 11:11 PM
That info was for Agama 0.5.7-3. I have no idea whether the same blockchain works in Ocean but imagine it does. Still takes ages even after using the bootstrap. I'm not having a good day
daemonfox04-Jul-19 12:34 AM
Another spammer in KMD group... Baddy351#0056
@ me for screenshot(edited)
@Team Admin ^^
pilot23456#6430 as well
yorklab04-Jul-19 01:00 AM
Banned
Shurikn8404-Jul-19 01:41 AM
For the people that received their funds back from KMD hack how long did it take after you submitted the form, anybody contacted you or it's an automatic process? I've completed two forms now because I'm pretty sure I had screwed up the first one (3weeks ago), It's been over a week that I filled the second form and still no tokens. Anybody having the same issue? Any way to get a hold of somebody to help me out? Thanks for advice!
jl777c04-Jul-19 04:15 AM
send the small amount from old address to new
G88804-Jul-19 06:41 AM
Excatly - @Shurikn84 once i did that it was quite quick.
Yassin04-Jul-19 11:45 AM
@Deleted User
Banned for spam
sorry wrong channel
TheFalseProfit04-Jul-19 01:20 PM
On the login page of Agama Verus I have a PIN field which is autofilled and a password field. Where do I get this password because at no stage have I seen any mention of a password?
Is it true that if I enter the seed words correctly it will ALWAYS show the same address in Lite Mode? Or can Seed words be associated with many address's? Can I assume that if the address is different I MUST have mis-entered the Seed words?
I just used the cross asset tool on my old compromised wallet and discovered I have NINJA, PIZZA and VOTE2019. I already received my KMD in a new address. What do I do with these?
What is going on with these address's? I get different address's seemingly randomly when logging into Lite Mode... sometimes the same one, sometimes not. How do I access my previously shown address's?
Cryptoon04-Jul-19 01:29 PM
same private key = same address
probably a little change in your private key when typing
Nope. Guaranteed the right key. I've been messing about with this for hours now. Private key is not the password is not the wif is not the seed is not the key. Multiple installations to test some of this. Nomenclature and ergonomics is the problem.
TheFalseProfit04-Jul-19 02:02 PM
same private key=same address is correct. It's getting back to the same address without a private key that's the issue.
Nope. Guaranteed the right key I meant seed not key.
Cryptoon04-Jul-19 02:20 PM
hmm without a privkey, then how do you log in?
native mode?
TheFalseProfit04-Jul-19 02:27 PM
I have my seed which initially gave me an address and not realising I need the private key to get back to it I closed the wallet and used the address in Lite Mode. Now I cannot find a way to access that same address.
I would have thought that the seed would be enough for anything. But I haven't been able to do it.
Cryptoon04-Jul-19 02:36 PM
But you have the seed for the original address?
TheFalseProfit04-Jul-19 02:38 PM
Yes
Cryptoon04-Jul-19 02:39 PM
try to create a new wallet with new pin and use original pin
TheFalseProfit04-Jul-19 02:41 PM
By original PIN I assume you mean Seed encrypt key?
or custom PIN file name?
𝙊𝙊𝙊𝙊04-Jul-19 02:42 PM
@TheFalseProfit check the pictures I posted in #ask-a-question. It's all on the screens
TheFalseProfit04-Jul-19 02:45 PM
Cheers Oink. Cryptoon that didn't work. Just got a new address and wallet.
jon_at_work04-Jul-19 02:46 PM
Hello all, I received an email about updating my Komodo node and just wanted to know if anyone could tell me which version I should be running?
marv10105-Jul-19 08:24 AM
Hi all. Regarding the claim of the hacked-hacked KMDs... My freind did not received his coins. Who can help me or can tell me who could help me?
gcharang05-Jul-19 08:29 AM
@marv101 DM the old address, will check
Shasuj05-Jul-19 11:34 AM
hey all. i got a question. i lost my komodo in the agama wallet, it was not that much but im scared now. i want to buy another 1k $ for staking, but i really dont know which wallet to use for staking, maybe any of you got some advice ?


It's nice to have you here. Main Office is a new office management platform: Self hosted, Open Source and completely customisable.
Main Office is currently in development. Check back for updates soon.


To obtain an entry-level position as a Front End Developer that will allow me to utilize the skills and build a long-term career in development.
Some quick example text to build on the card title and make up the bulk of the card's content.
Some quick example text to build on the card title and make up the bulk of the card's content.
Some quick example text to build on the card title and make up the bulk of the card's content.
Some quick example text to build on the card title and make up the bulk of the card's content.


Joe DiMaggio was a legendary baseball player and a true American icon, born on Nov. 25, 1914 in Martinez, CA. One hundred years later, the Joe DiMaggio Hometown Hero Project was launched to celebrate and preserve his legacy through multiple initiatives.
The Project is staffed by volunteers,
allowing 100% of donations to go toward these initiatives.
These initiatives include establishing a Joe DiMaggio Museum, erecting a statue celebrating his immigrant heritage, and developing an interactive walking tour of DiMaggio-associated sites in Martinez. The Project also encompasses a mural, welcoming travelers to the birthplace of the iconic center fielder and an oral history project, capturing stories of Joe's impact on our lives.


The Contacts control can be used to display a shorthand notation for the participants in a communication. The participant’s name, short name or initials can be shown, along with an organization, and individuals belonging to the same organization can be grouped together. The status of a contact, active or passive, can be displayed to indicate their involvement in a conversation. Organizations can be labelled as “External” or “Risk”.
To use the Contacts control use the contact-group
directive. The full list of configuration attributes for this control is defined below:
medium
or small
.
primary
, secondary
, active
, and
passive
colors in #HTML format. The primary color will be used as the background
for the contact. We recommend you use colors from the Color Palette.
Contacts can be supplied either as a single object, or more typically as an array of objects.
customTooltip
object can have the following attributes :
template
: (required) The relative path to the HTML template to be displayed for the contact on hover.
tooltipPosition
: (optional) either "top" or "bottom" - default value is "bottom".
data
: (optional) The data attribute can be defined as an object to contain information for the tooltip. The values in the data object can be displayed accordingly through the template HTML.
The example at the top of the page shows usage of the ‘active’ status, the ‘passive’ status, and no status.
Organizations should be objects with the following properties:
external
or risk
.
customTooltip
object can have the following attributes :
template
: (required) The relative path to the HTML template to be displayed for the contact on hover.
tooltipPosition
: (optional) either "top" or "bottom" - default value is "bottom".
data
: (optional) The data attribute can be defined as an object to contain information for the tooltip. The values in the data object can be displayed accordingly through the template HTML.
The example at the top of the page shows usage of both the “risk” and “external” labels.
The following code was used to create the example at the top of this page:
Note: This component can be used in an Angular application by importing the HybridModule.


Active Network Elements
Click to Edit Details or Remove
[% INCLUDE html_templates/map_legend.html %]
Workgroups
Manage Workgroups
Remote Links
Remote Devices
Set Lat/Long Information for Remote Devices By Clicking on Them
Maintenances
Configuration Changes
Manage Device Configurations


Extra Light
Kanyu, zebra bullhead shark flying gurnard Steve fish orbicular batfish. Boafish kuhli loach glass knifefish pike eel, surfperch, scat tench golden trout Asiatic glassfish Pacific hake common tunny stingray slender snipe eel.
Regular
Tunny stingray slender snipe eel. Wahoo piranha tilefish pipefish combfish, wobbegong, convict blenny basking shark yellowtail horse mackerel, amago Ratfish.
Semi Bold
Stingray slender snipe eel. Wahoo piranha tilefish pipefish combfish, wobbegong, convict blenny basking shark yellowtail horse mackerel, amago Ratfish.
Bold
Kanyu, zebra bullhead shark flying gurnard Steve fish orbicular batfish. Boafish kuhli loach glass knifefish pike eel, surfperch, scat tench golden trout combfish, wobbegong, convict blenny basking shark yellowtail horse mackerel, amago Ratfish.


Delivery Service Requests¶
When enabled in traffic_portal_properties.json, delivery service requests are created when ALL users attempt to create, update or delete a delivery service. This allows users with higher level permissions (ops or admin) to review the changes for completeness and accuracy before deploying the changes. In addition, most delivery service changes require cache config updates (aka queue updates) and/or a cdn snapshot. Both of these actions are reserved for users with elevated permissions.
A list of the delivery service requests associated with your tenant can be found here:
https://traffic-portal.domain.com/#!/delivery-service-requests
Who Can Create a Delivery Service Request and How?¶
Users with the Portal role (or above) can create delivery service requests by doing one of three things:
- Creating a new delivery service
- Updating an existing delivery service
- Deleting an exiting delivery service
By performing one of these actions, a delivery service request will be created for you with a status of draft or submitted. You determine the status of your request. Only change the status of your request to submitted once the request is ready for review and deployment.
Who Can Fulfill a Delivery Service Request and How?¶
Users with elevated permissions (Operations or above) can fulfill (apply the changes) or reject the delivery service request. In fact, they can do all of the following:
Update the contents of the delivery service request¶
Optional. This will update the “Last Edited By” field to indicate who last updated the request.
Assign or unassign the delivery service request¶
Optional. Assignment is currently limited to current user. This is optional as fulfillment will auto-assign the request to the user doing the fulfillment.
Reject the delivery service request¶
Rejecting a delivery service request will set status to rejected
and the request can no longer be modified. This will auto-assign the request to the user doing the rejection.
Fulfill the delivery service request¶
Fulfilling a delivery service request will show the requested changes and, once committed, will apply the desired changes and set status to pending
. The request is pending because many types of changes will require cache config updates (aka queue updates) and/or a cdn snapshot. Once queue updates and/or cdn snapshot is complete, the request should be marked complete
.
Complete the delivery service request¶
Only after the delivery service request has been fulfilled and the changes have been applied can a delivery service request be marked as complete. Marking a delivery service as complete is currently a manual step because some changes require cache config updates (aka queue updates) and/or a cdn snapshot.
Once that is done and the changes have been deployed, the request status should be changed from pending
to complete
.
Delete the delivery service request¶
Delivery service requests with a status of draft or submitted can always be deleted entirely if appropriate.