2005-11-17 Assigned to NTT DOCOMO, INC. reassignment NTT DOCOMO, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DOCOMO COMMUNICATIONS LABORATORIES USA, INC.
In one aspect of the invention, a configurable reliable messaging system is provided. The configurable reliable messaging system comprises a communication subsystem capable of configurably transmitting and receiving a message across a network using at least one of a plurality of network links, a plurality of internet protocols and a plurality of transport protocols. The configurable reliable messaging system also comprises a reliability subsystem capable of configurably logging the message, detecting a plurality of failures, notifying a remote entity interconnected with the configurable reliable messaging system via the network of the plurality of failures, and recovering from the plurality of failures. In addition, the configurable reliable messaging system comprises a control module capable of configuring the communication subsystem and the reliability subsystem based on a set of input parameters.
This application is related to application Ser. No. 10/179,994, filed Jun. 24, 2002, entitled "System and Method for Making Mobile Applications Fault Tolerant," naming as inventors Nayeem Islam and Shahid Shoaib, and application Ser. No. 10/243,083, filed Sep. 13, 2002, entitled "Method For Dynamically Switching Fault Tolerance Schemes," naming as inventors Shahid Shoaib and Nayeem Islam.
The present invention relates generally to fault tolerant distributed computing systems, and in particular, to a reliable messaging system for distributed systems that is self configurable to provide various levels of fault tolerance.
The successful completion of applications depends on the fault free operation of critical system components. In distributed computing systems, these critical system components typically include application processes, devices (clients or servers) on which application processes execute and the communication mechanism used to communication between them. However, any of these components may fail during operation. Such failures may have implications for a user ranging from mere annoyance to significant financial losses. Therefore, from a user's perspective, there is a need for system reliability. Reliability is the property of a computing system that allows it to run continuously without crashing. In situations where it may not be possible to avoid all component failures, reliability from a user perspective can be provided by masking these failures. Fault tolerance allows a system to run and offer its services to a user even in the presence of failures.
Messaging is considered a key communication mechanism in distributed systems, where it is a popular choice for applications that require a high degree of reliability, e.g. web services, remote procedure calls and e-commerce transactions. Messaging allows applications to communicate to each other via message passing, ensuring that messages are delivered according to application specified delivery semantics, such as at most once, at least once and exactly once.
A message-based communication system that is fault tolerant, referred to as a reliable messaging system, ensures the reliable delivery of messages according to specified delivery semantics despite device (client or server) and network failures. This is accomplished by making the reliable messaging system fault tolerant to various types of failures, which may require implementing different fault tolerance schemes for fault detection or recovery. Additionally, a reliable messaging system may support asynchronous operation, which imposes no limit on the time it takes to send or receive messages over a network. Asynchronous operation allows interconnected devices to communicate with each other even if one of the devices is temporarily unavailable using point to point messaging or a centralized messaging or queuing server.
Fault tolerance usually requires some sort of redundancy, e.g., an application may have to save its state periodically to stable storage in order to ensure that it can recover from failures. Research has shown that there is a significant trade-off between the level of fault tolerance, which includes reliability guarantees and recovery speed, and the system performance during failure free operation. This trade-off results from the varying amounts of computing overhead associated with message logging, fault detection and recovery operations for different fault tolerance schemes. Accordingly, an application may wish to specify precise fault tolerance and performance requirements for a reliable messaging system. These requirements may vary over the course of execution of an application and may differ among applications.
In addition, reliable messaging systems will need to operate in computing environments that may have great heterogeneity among the networks, applications/services and devices forming part of these environments. For example, a wireless environment may include changing networks, changing network conditions, including frequent disconnections, asymmetric networks and networks with unpredictable delay and loss characteristics. In addition, various applications executing within a wireless environment may impose changing service characteristics and service requirements for reliability and fault tolerance. Also, wireless environments may include heterogeneous devices having different processing power, changing load, storage, memory and battery resources.
Traditional techniques for implementing reliable messaging for distributed systems have primarily focused on static reliable messaging systems. These systems are unable to adapt to changing conditions in a heterogeneous environment. Known reliable messaging systems can provide only limited levels of fault tolerance and rely on fixed transport protocols, usually the Transport Control Protocol (TCP), which may not be optimized for a heterogeneous or wireless environment.
Therefore, there is a need for an improved reliable messaging system that can provide dynamic re-configurability and fault tolerance in a heterogeneous computing environment.
In another aspect of the invention, a method for configuring a reliable messaging system is provided. The reliable messaging system includes a control module. The reliable messaging system also includes a communication subsystem having communication components, which are capable of configurably transmitting and receiving a message across a network using at least one of a plurality of network links, a plurality of internet protocols and a plurality of transport protocols. The reliable messaging system further includes a reliability subsystem having reliability components, which are capable of configurably logging the message, detecting a plurality of failures, notifying a remote entity interconnected with the configurable reliable messaging system via the network of the plurality of failures, and recovering from the plurality of failures. The method comprises using the control module, selecting a group of the reliability components for an implementation of the reliable messaging system based on a set of input parameters. The method also comprises instantiating the communication components and the selected group of reliability components. In addition, the method comprises using the control module, configuring the communication components and the selected group of reliability components. Furthermore, the method comprises using the control module, determining an order for routing messages between the set of components based on the set of input parameters.
FIGS. 5 a–5 c illustrate communications between components of the reliable messaging system of FIG. 1.
Reference will now be made in detail to the present disclosed embodiments with reference to the accompanying drawings.
FIG. 1 illustrates an embodiment of a configurable reliable messaging system 10 according to the present invention, which utilizes a component based software architecture to implement reliable messaging. In particular, the reliable messaging system 10 includes a communication subsystem 12, a reliability subsystem 14, and a control module 16. The reliable messaging system 10 interfaces with an application program 18 using a set of APIs 20 via the control module 16.
The application program 18 uses the reliable messaging system 10 to communicate with other remote entities. For instance, the reliable messaging system 10 can execute in a distributed system, as shown in FIG. 2. A distributed system is a group of computing devices interconnected with a communication network which function together to implement an application. The distributed system 21 of FIG. 2 includes an access network 22 connected to a client device 24 and a server device 26. A client application 18 c, such as a web browser responsible for presenting the data on the client 24, interfaces with a reliable messaging system ("RMS") 10 c that executes on the client 24. A server application 18 s, such as a database engine that manages data storage and retrieval on the server 26, interfaces with the reliable messaging system 10 s that executes on the server 26. The client and server applications 18 c and 18 s can communicate with each other by sending and receiving messages across the access network 22 via reliable messaging systems 10 c and 10 s. In addition, the client 24 includes a persistent storage 28 and the server 26 includes a persistent storage 30 to allow the reliable messaging systems 10 s and 10 c to perform message logging operations.
While the distributed system 21 of FIG. 2 illustrates a client-server model, it should be understood that this model is meant to be illustrative, rather than limiting. A configurable reliable messaging system according to the present invention can execute in other types of distributed computing environments as well. For example, multiple client devices may communicate to each other via the reliable messaging system 10 of FIG. 1 in a peer-to-peer or adhoc networking mode and multiple server devices also may communicate to each other via the reliable messaging system 10 for back end processing.
As described in further detail below, the reliable messaging system 10 of FIG. 1 is self configurable in (i) the selection of the components that comprise the communication subsystem 12 and the reliability subsystem 14, (ii) the specific implementations of the selected components and (iii) the routing of messages between these components. This configurability allows the reliability messaging system 10 to adapt itself in real time to handle different types of applications, networks and devices.
As indicated above, the reliable messaging system 10 of FIG. 1 includes a communication subsystem 12, which is responsible for end-to-end delivery of data. For example, as shown in FIG. 2, the reliable messaging systems 10 c and 10 s are responsible for delivery of data between the client 24 and the server 26. Referring again to FIG. 1, the components of the communication subsystem 12 include a network interface layer 40, an internet layer 42 and a transport layer 44.
The network interface layer 40 provides access to different physical network links, such as the access network 22 of FIG. 2, for transmitting and receiving data. The network interface layer 40 formats data into network-specific packets. It provides the internet layer 42 with a consistent interface to different types of access networks, such as a wired local access network ("LAN"), cellular network, Bluetooth, IRDA, 802.11b (Wi-Fi) wireless LAN, and General Packet Radio Service (GPRS) mobile telephone network.
The internet layer 42 handles the movement of data across an internet, which is a set of interconnected networks. Specifically, the internet layer 42 provides the ability to transmit data between heterogeneous physical networks that interconnect a source and destination device. For example, the access network 22 of FIG. 2 may include a 802.11B wireless LAN network or a third generation cellular network (UMTS) as part of a hybrid network comprising of different access technologies. The internet layer preferably uses the Internet Protocol ('IP") for routing individual data packets between individual network nodes using an IP addressing scheme. The Internet Protocol can also break up or fragment application messages into smaller manageable data packets called datagrams for transmission across networks that can only handle smaller data packets. The datagrams can then be re-assembled at a destination node to reconstruct the sent messages. The internet layer can further process error and control messages, such as ICMP. However, those skilled in the art will recognize that other types of protocols may be used instead of IP, such as Novell NetWare's IPX.
The transport layer 44 manages the flow of data between the application 18 and the reliable messaging system 10. It performs flow control to slow data transfer in case of limited network bandwidth and verifies the correct delivery of data. If transmission errors or data loss are detected, the transport layer 44 can ask for data to be retransmitted. The transport layer can utilize various transport protocols, including reliable HTTP (HTTPR), which supports reliable messaging, as well as TCP, SCTP, UDP, SMTP, HTTP.
The reliability subsystem 14 addresses problems related to making the communications subsystem 12 fault tolerant in the presence of network, device and application failures. The reliability subsystem 14 includes a log manager module 46, failure detector module 48, notification manager module 50 and recovery manager module 52.
The log manager module 46 takes care of message logging during normal system operation. For example, the log manager module of the reliable messaging system 10 c of FIG. 2 can log messages received from the server 26 to the persistent storage 28 on the client 24, while the log manager module of the reliable messaging system 10 s can log messages received from the client 24 to persistent storage 30 on the server 26.
Message logging is desirable because fault tolerance is attained by redundancy. The log manager module 46 can execute various logging schemes or algorithms. For example, both the client 24 and the server 26 of FIG. 2 may have multiple options regarding the direction of message logging, including for outgoing messages only, for incoming messages only, or for both directions. In addition, the client 24 may have options for the timing of message logging operations, such as logging messages before sending an outgoing message, after sending an outgoing message or asynchronously. Likewise, the server 26 may log messages before or after delivering an incoming message to the application or asynchronously.
Different logging schemes can have different fault tolerance versus performance trade-offs. No one logging scheme will work best for all applications. In order to meet changing requirements of fault tolerance and performance for the application 18, the log manager module 46 can dynamically switch message logging schemes in real time at the direction of the control module 16, as described in further detail below.
Referring again to FIG. 1, the failure detector module 48 is used to detect different classes of failures, such as application process failures, client and server device failures, network failures and transport failures. Timely and accurate failure detection facilitates graceful recovery from failures.
As noted above, the failure detector module 48 can detect application process failures. For example, the failure detector module 48 can periodically poll the operating system process table to determine if the application 18 has crashed or fails to respond within a given time period. This behavior will be detected by the failure detector module 48 and will be treated as an application process failure. The failure detector module 48 can also signal to the control module 16 that the application 18 has failed. As described in greater detail further below, the control module 16 can then direct the notification manager module 50 and the recovery manager module 52 to take appropriate steps in order to mask the failure of the application 18.
The failure detector module 48 can also detect local device and remote device failures. In particular, the failure of a local device that executes the reliable messaging system 10 can only be detected locally once the device is turned back on. For example, referring to FIG. 2, the failure detector module of the reliable messaging system 10 c may detect that the client 24 (local device) has failed once the client 24 device restarts and a communicating peer, such as the server 26, notifies the client 24 of the client's failure. The server 26 can determine that the client 24 has failed using a timeout mechanism that periodically polls the client 24. Likewise, by periodically polling the server 26, the failure detector module of the reliable messaging system 10 c can detect a failure of the server 26 (remote device) once the server has crashed or fails to respond in a given interval. Furthermore, the reliable messaging system 10 s can similarly detect a local failure of the server 26 once the server 26 restarts as well as a failure of a remote device, such as client 24, using simple timeout mechanisms.
In addition, network link failures can be detected by the failure detector module 48 of FIG. 1. In particular, the failure detector module 48 can detect whether a network link of the reliable messaging system 10 has crashed or ceases to respond within a given interval to polling requests. Alternatively, the failure detector module 48 can detect a network link failure if the packet loss rate or data transmission delay for the network link increases above a predetermined threshold value. This threshold value may vary for different types of networks and can be specified by the systems deployer.
The failure detector module 48 further can detect a failure at the transport layer 44. A transport protocol is defined to have failed if the network link has not crashed, but the transport protocol itself is giving unacceptable performance. For example, the failure detector module 48 can detect a failure a failure at the transport layer 44 if a network link shows acceptable signal strength above a given signal threshold, but the data transmission delay, or number of retransmissions increases above a predetermined threshold value.
The notification manager module 50 works in conjunction with the failure detector module 48 to notify remote entities that the application 18 has failed. Specifically, once the control module 16 receives notice from the failure detector module 48 that the application 18 has failed, the control module can direct the notification manager module 50 to broadcast a failure notification to particular remote entities. For example, referring to FIG. 2, the notification manager module of the reliable messaging system 10 s on the server 26 can notify the reliable messaging system 10 c on the client 24 that the application 18 s has failed. As described in greater detail further below in connection with the reliability options of Table 1, the application 18 can request which remote entities are notified of its failure.
In addition, the notification manager module 50 can notify remote entities if the failure detector module 48 has detected that a network link or transport has failed. This can be accomplished once the recovery manager 52 has recovered from the network link failure or transport failure in question.
The recovery manager module 52 of FIG. 1 is responsible for recovery from different types of failures. Different recovery mechanisms may be used by the recovery manager module 52 depending upon the type of failure detected and the logging scheme used by the log manager module 46.
Consequently, the recovery manager module 52 can recover from application process failures. In particular, the recovery manager module 52 will ensure that, if a local application has failed, any incoming messages are delivered to the application after it restarts. Likewise, in case of a remote application failure, the recovery manager module 52 will ensure that any outbound messages are received by the remote application once it restarts. Referring to FIG. 2, if the client application 18 c fails for example, the recovery manager module of the reliable messaging system 10 c will request that the log manager of the reliable messaging system 10 c queue all incoming messages and will ensure that those messages are delivered to the client application 18 c once it restarts. If the server application 18 s fails, the recovery manager module of the reliable messaging system 10 c will request that the log manager of the reliable messaging system 10 c queue all outbound messages from the client 24 and will ensure that they are received by the server application 18 s once it restarts.
In addition, when the server application 18 s has failed, the recovery manager module of the reliable messaging system 10 s on the server 26 can notify the client application 18 c of alternate servers executing a server application which provides the services requested from application 18 s. Also, the recovery manager module of the reliable messaging system 10 c on the server 24 can seek an alternate server in response to a notification that the server application 18 s has failed.
Referring again to FIG. 1, the recovery manager module 52 can also recover from device failures. In particular, the recovery manager module 52 will ensure that, if a local device has failed, any incoming messages are delivered to a local application once it restarts after the local device itself comes back up. Likewise, in case of a remote device failure, the recovery manager module 52 will ensure that any outbound messages are received by a remote application once it restarts after the remote device itself comes back up.
For example, if the client 24 of FIG. 2 fails, the recovery manager module of the reliable messaging system 10 c will ensure any incoming messages are delivered to the client application 18 c once it restarts after the client 24 itself comes back up. Likewise, the recovery manager module of the reliable messaging system 10 s will ensure that any outbound messages are received by the client application 18 c once it restarts after the client 24 itself comes back up. If the server 26 of FIG. 2 fails, the recovery manager module of the reliable messaging system 10 s will ensure any incoming messages are delivered to, and the recovery manager module of the reliable messaging system 10 c will ensure that any outbound messages are received by, the server application 18 s once it restarts after the server 26 itself comes back up.
Alternatively, in case the server 26 has failed, the recovery manager module of the reliable messaging system 10 c on the client 24 can find an alternate server connected to the access network 22, which can continue to provide the same services as the crashed server 26. The reliable messaging system 10 c will then send outbound messages to the new alternate server instead of the server 26.
Referring again to FIG. 1, the recovery manager module 52 further can recover from a network link failure. In particular, the recovery manager module 52 can select a different access network for communicating with remote entities once a network link failure has been detected by the failure detector 48. The selection criteria for choosing a new access network can be specified by the system deployer.
Additionally, in order to recover from a transport failure, the recovery manager module 52 may select another transport protocol to use for the transport layer 44 once a transport failure has been detected by the failure detector 48. The criteria for selecting an appropriate transport protocol may be specified by the system deployer.
The control module 16 provides an interface to the application 18. Generally, the control module 16 provides the application 18 with a core set of application programming interfaces ("APIs") 20 that can be used for communicating with the reliable messaging system 10. In particular, the set of APIs 20 allow the application 18 to specify input parameters for the reliable messaging system 10. The input parameters correspond to different options for performance and fault tolerance of the reliable messaging system 10. As described in greater detail further below, an application 18 may specify different options for performance and fault tolerance for the reliable messaging system 10 in various levels of granularity, such as per message and per message type. In addition, those skilled in the art will recognize that different users may have their own peculiar requirements for fault tolerance and/or performance from a particular application. Therefore, an application may specify different sets of input parameters depending on the identity of a current user or on a per user basis.
Table 1 shows several reliability related options that the application 18 of FIG. 1 may specify for the reliable messaging system 10. The term local application refers to the application 18 and the term local device refers to the device, whether client or server, which executes the application 18. The term remote device refers to a device interconnected to the local device via a network. A remote application is an application that executes on a remote device for providing services requested by the local application. The term logging server refers to a dedicated remote device that is capable of logging messages. Where an entry for an option is designated by the term "X," a particular value may be specified corresponding to a range of values available for the option.
As shown in Table 1, the application 18 may choose various types of failures to be detected by the reliable messaging system 10, including local and remote application failures, remote device failures, and network failures, including network link and transport failures. The application 18 also may specify whether the reliable messaging system 10 should notify remote entities of particular types of failures as well as a destination for any such notification. The application 18 may further choose whether it wishes to recover from local and remote application failures, local and remote device failures, and network failures, including network link and transport failures. In addition, the application 18 may request a device for logging messages, including the local device, a remote device, and a centralized network logging server.
Furthermore, the application 18 can specify values for reliability options of Table 1 on a per message basis or a per message type basis. In particular, the application 18 can specify different recovery and failure detection options for individual messages or for each class of messages handled by the reliable messaging system 10.
The following sample APIs may be used to by an application to specify input parameters corresponding to the reliability options shown in Table 1.
Table 2 shows several performance options that the application 18 may specify for the reliable messaging system 10. In particular, the application 18 may set threshold values for the mean (M(T)) and variance (V(T)) of wait times for user interface events at the application 18. Wait times measure the time intervals that the application 18 must wait for a system response after issuing a request. Accordingly, the threshold values for M(T) and V(T) relate to acceptable response times for fulfilling a user's request. Furthermore, the application 18 may specify the threshold values for the mean and variances of wait times per message or per message type.
The following sample APIs may be used to the application 18 to specify input parameters corresponding to the performance options discussed above.
Table 3 shows several network stack options that the application 18 may customize for the reliable messaging system 10. Specifically, the application 18 may specify a network link to be accessed locally by the network interface layer 40, a protocol to be used locally by the internet layer 42 and a transport protocol to be used locally by the transport layer 44 of the reliable messaging system 10. The application 18 can specify each of these network stack options per message or per message type.
The following sample APIs may be used to by the application 18 to specify input parameters corresponding to the network stack options discussed above. The "autoSwitch" parameters allow the application 18 to specify that the reliable messaging system 10 is permitted to switch from the requested transport layer protocol, the internet layer protocol and the network link if necessary.
Table 4 shows several delivery options for the reliable messaging system 10 that the application 18 may select from. For example, the application 18 may specify that it requires at least once, at most once or exactly once delivery of messages. It also may specify different delivery options per message type or per message.
Table 5 shows several synchrony options that the application 18 may specify for the reliable messaging system 10. For example, the application 18 may select either asynchronous or synchronous operation of the reliable messaging system 10. These options may be selected by the application 18 per message type or per message.
In addition, the following sample APIs may be used to by the application 18 to specify input parameters corresponding to the delivery and synchrony options discussed above.
The application 18 also can configure the reliable messaging system 10 using the "sendMessage" method call for requesting that the reliable messaging system send messages and the "recvMessage" method call for retrieving messages received by the reliable messaging system.
The set of APIs 20 provide flexibility in how the reliable messaging system is configured. Based on the reliability, performance, network, synchrony, and delivery options specified by the application 18, the control module 16 can instantiate and configure a customized implementation of the reliable messaging system 10. In particular, the control module 16 can select the components of the communication and reliability subsystems 12 and 14 for a particular instantiation of the reliable messaging system 10 depending on the fault tolerance and performance options specified by the application 18.
FIG. 3 illustrates an exemplary set of input parameters 60 c corresponding to the reliability options of Table 1 that the application 18 c of FIG. 2 can specify. Specifically, input parameters 60 c specify that the application 18 c wants to be able to detect and recover from local application (client application 18 c) and remote application (server application 18 s) failures, remote device (server 26) failures, and network (network 22) failures, including network link and transport failures. The application 18 c also wants message logging to be done on the remote device (server 26), but not on the local device (client 24). Furthermore, the application 18 c does not want to notify any remote entities of the failures detected by the reliable messaging system 10 c. Based on these input parameters 60 c, the control module 16 c of the reliable messaging system 10 c selects and dynamically instantiates an implementation 62 c of the reliable messaging system 10 c, as shown in FIG. 3. In the implementation 62 c, the notification manager module of the reliable messaging system 10 c has not been instantiated and is not part of the implementation because the application 18 c did not request failure notification as a reliability option.
FIG. 4 illustrates another instance 72 c of the reliable messaging system 10 c. In this instance, the application 18 c has requested failure detection and notification but no recovery and message logging. Accordingly, the control module 16 c of the reliable messaging system 10 c instantiates the notification manager module 50 c and the failure detector module 48 c of the reliable messaging system 10 c. However, the recovery manager module and the log manager module of the reliable messaging system 10 c have not been instantiated and are not part of the instance 72 c of the reliable messaging system 10 c.
In another example, the client application 18 c of FIG. 2 can specify that it will not tolerate mean wait times above a predetermined threshold value for M(T), according to the performance options of Table 2. However, the application 18 c can also request message logging on both the client 24 and the server 26 according to the options shown in Table 1 in order to ensure that messages are delivered in despite failures of the network 22, client 24 and server 26. In this case, if the client 24 determines that the mean wait time for the application 18 c are above the predetermined threshold value for M(T), it can attempt to lower it by sacrificing part of the requested fault tolerance. Specifically, if the client 24 can determine whether the computational cost of logging messages is lower at the server 26 than at the client 24, the control module 16 c of the reliable messaging system 10 c can ignore the client message logging option specified by the application 18 c, such that only the instantiation of the reliable messaging system 10 s at the server 26 will include a log manager module. By refusing to instantiate a log manager module at the client 24, the control module 16 c can lower the overall response time for responding to a user request from the client 24, thereby lowering the mean wait time.
These examples illustrate how the architecture of the reliable messaging system 10 permits the control module 16 to select different components for an instance of the reliable messaging system based on application specified input parameters corresponding to the reliability and performance options shown in Tables 1 and 2.
In addition, once selected components of the reliable messaging system 10 have been instantiated, the control module 16 of FIG. 1 can configure these components based on the specified options for performance and fault tolerance. In particular, the control module 16 can determine which protocols or algorithms to execute for the instantiated components. Also, the control module 16 can dynamically switch different algorithms or protocols running in one or more components at runtime based on the input parameters specified by the application 18.
For example, the control module 16 can select different message logging schemes for log manager module 46 based on the threshold values for the mean and variances of wait times specified by the application 18 for the performance options shown in Table 2, as disclosed in application Ser. No. 10/243,083, entitled "METHOD FOR DYNAMICALLY SWITCHING FAULT TOLERANCE SCHEMES," naming as inventors Shahid Shoaib and Nayeem Islam, filed Sep. 13, 2002.
Likewise, the control module 16 can select different transport protocols for the transport layer 44 and different network links for the network interface layer 40 based on the network, delivery and synchrony options specified by the application 18. Additionally, if the application 18 fails to specify a transport protocol, the control module 16 may select a protocol for the transport layer 44 based on the type of network link specified. Alternatively, the application 18 can choose to become completely independent of communications semantics, specifying only the data that it wants to send, the intended destination, any delivery semantics and the type of reliability and fault tolerance for various types of failures. In this case, it can be the job of the reliable messaging system 10 to select an appropriate transport protocol and access network based on the reliability and delivery options specified.
Moreover, if operating conditions change, the control module 16 can instruct the communication subsystem 12 to switch transport protocols or access networks to optimize the performance and degree of reliability of the reliable messaging system 10 based on a pre defined set of criteria. For example, if the current network link for the network interface layer 44 changes, the control module 16 may examine a set of predefined criteria or rules in order to determine whether to effect a change at the transport layer 44. Such criteria may include an indication that a TCP protocol performs poorly on a wireless network link or that SMS is the preferred protocol for a cellular network link.
As a result, the reliable messaging system 10 provides the application 18 with a network and transport independent interface. Whereas traditional communication models compel an application itself to select and use underlying transport protocols, the reliable messaging system 10 of FIG. 1 allows the application 18 to become completely independent of communications semantics. Accordingly, the application 18 can communicate and host data across different types of networks and transports using a variety of different network or transport protocols.
Therefore, the reliable messaging system 10 can configure itself based on the input parameters specified by the application 18 using the APIs 20. In particular, the control module 16 can instantiate selected components of the reliability subsystem 14 and can configure the components of the reliability subsystem 14 and communication subsystems 12 with different algorithms or protocols. The control module 16 can switch fault tolerance schemes, network links, and protocols transparently to the application 18. Since different components of the reliable messaging system 10 may be instantiated and individually configured by the control module 16, the reliable messaging system 10 separates functional and non-functional code. In other words, the components of the reliability and communication subsystems 12 and 14, which comprise functional mechanisms for implementing various fault tolerance and performance policies, are distinct from the policy making control module 16.
In addition to selecting and configuring components of the reliability and communication subsystems 14 and 12 for different instantiations of the reliable messaging system 10, the control module 16 can also direct the routing order for messages between the instantiated components of the reliable messaging system 10. For example, as shown in FIG. 5 a, the control module can request that an incoming message received by the network interface layer at step 100 is routed first to the internet layer at step 101, then to the transport layer at step 102, then to the log manager module where it can be logged at step 103, then to the control module at step 104 and finally to the application at step 106 via the API's at step 105. Alternatively, as shown in FIG. 5 b, the control module can request that, once an incoming message received by the network interface layer at step 110 is routed to the internet layer at step 111 and the transport layer at step 112, the message is to be delivered to the control module at step 113 and then to application at step 115 via the API's at step 114 before the message is delivered to the log manager module at step 116 for logging. Likewise, as shown in FIG. 5 c, the control module can request that an incoming message received by the network interface layer at step 120 is routed first to the log manager module at step 121 and then to the internet layer at step 122, the transport layer 44 at step 123, the control module at step 124 and finally to the application at step 126 via the API's at step 125.
The control module 16 of FIG. 1 can also coordinate the execution of the components of the communication subsystem 12 and the reliability subsystem 14. For example, the control module 16 can act as a coordinator for all messages passed between the components of the reliable messaging system 10, such that different components can only communicate with each other through the control module 16. In other words, every communication between components of the reliable messaging system 10 must pass through the control module 16. Alternatively, the control module 16 can delegate coordination to the other components of the reliable messaging system 10 such that components can communicate directly with each other. In this case, the control module 16 acts as an observer and will intervene only to reconfigure the reliable messaging system 10.
For example, as described above, the failure detector module 48 can signal to the control module 16 that the application 18 has failed. The control module 16 can then direct the notification manager module 50 to notify remote network entities of the application process failure and the recovery manager module 52 to ensure delivery of incoming or outgoing messages. Alternatively, the architecture of the reliable messaging system 10 also allows the failure detector module 48 to communicate directly with the notification manager module 50 and the recovery manager module 52 in order to mask the failure of the application 18.
a control module capable of configuring said communication subsystem and said reliability subsystem based on a set of input parameters in order to achieve different levels of reliability with respect to the communication subsystem.
2. The system of claim 1 wherein said configurable reliable messaging system interfaces with an application via said control module using a set of application programming interfaces for specifying said input parameters.
wherein said control module can separately configure said network interface layer, said internet layer and said transport layer based on said input parameters.
wherein the control module can separately configure the network interface layer, the internet layer and the transport layer based on the input parameters, and further wherein said control module can selectively instantiate and configure said log manager module, failure detector module, notification manager module and recovery manager module based on said input parameters.
5. The system of claim 4 wherein said input parameters comprise at least one of a reliability option, a performance option, a network stack option, a delivery option and a synchrony option.
6. The system of claim 5 wherein said reliability option includes a failure detection parameter for specifying whether to detect said requested failure, a recovery parameter for specifying whether to recover from said requested failure, a notification parameter specifying whether to notify said remote entity of said requested failure and a message logging parameter specifying a device connected with said network for logging said message.
7. The system of claim 5 wherein said performance option includes at least one of a parameter specifying a mean of wait times for user interface events of said application and a parameter specifying a variance of wait times for user interface events of said application.
8. The system of claim 5 wherein said network stack option includes at least one of a parameter specifying said requested transport protocol, a parameter specifying said requested internet protocol and a parameter specifying said requested network link.
9. The system of claim 5 wherein said delivery option includes at least one of a first parameter for specifying at least once delivery of said message, a second parameter for specifying at most once delivery of said message, and a third parameter for specifying exactly once delivery of said message.
10. The system of claim 5 wherein said synchrony option includes at least one of a parameter for specifying asynchronous operation of said configurable reliable messaging system and a parameter for specifying synchronous operation of said configurable reliable messaging system.
11. The system of claim 5 wherein said application can specify said input parameters on at least one of a per message basis and a per message class basis.
using said control module, determining an order for routing messages between said set of components based on said set of input parameters.
13. The method of claim 12 further comprising interfacing said reliable messaging system with an application using a set of application programming interfaces for specifying said input parameters.
configuring a transport layer for managing data communication with said application using a requested transport protocol of said plurality of transport protocols.
interfacing said reliable messaging system with an application using a set of application programming interfaces for specifying said input parameters.
16. The method of claim 15 wherein said input parameters comprise at least one of a reliability option, a performance option, a network stack option, a delivery option and a synchrony option.
17. The method of claim 16 wherein said reliability option includes a failure detection parameter for specifying whether to detect said requested failure, a recovery parameter for specifying whether to recover from said requested failure, a notification parameter specifying whether to notify said remote entity of said requested failure and a message logging parameter specifying a device connected with said network for logging said message.
18. The method of claim 16 wherein said performance option includes at least one of a parameter specifying a mean of wait times for user interface events of said application and a parameter specifying a variance of wait times for user interface events of said application.
19. The method of claim 16 wherein said network stack option includes at least one of a parameter specifying said requested transport protocol, a parameter specifying said requested internet protocol and a parameter specifying said requested network link.
20. The method of claim 16 wherein said delivery option includes at least one of a first parameter for specifying at least once delivery of said message, a second parameter for specifying at most once delivery of said message, and a third parameter for specifying exactly once delivery of said message.
21. The method of claim 16 wherein said synchrony option includes at least one of a parameter for specifying asynchronous operation of said configurable reliable messaging system and a parameter for specifying synchronous operation of said configurable reliable messaging system.
22. The method of claim 16 wherein said application can specify said input parameters on at least one of a per message basis and a per message class basis.
A. S. Tanenbaum and M. V. Steen, Distributed Systems: Principles and Paradigms, Prentice Hall, 2002, pp. 28-31, 36-37, 100-105, 362-363, 376-377.
A. Sears, J. S. Jacko and M. S. Borella, Internet Delay Effects: How Users Perceive Quality, Organization, and Ease of Use of Information, 1997. http://www.acm.org/sigchi/chi97/proceedings/short-talk/als2.htm.
Ben Schneiderman, Designing The User Interface: Strategies for Effective Human Computer Interaction, Addison Wesley Longman, 1998, pp. 71-80.
Duncan Mackenzie, Reliable Messaging with MSMQ and .NET, Microsoft Developer Network, 2002. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetasync2.asp.
E. N. Elnozahy, D. B. Johnson and Y. M. Wang, A Survey of Rollback-Recovery Protocols in Message-Passing Systems, Technical Report CMU-CS-960181, Carnegie Mellon University, 1996. http://citeseer.nj.nec.com/elnozahy96survey.html.
IBM MQSeries Overview, IBM, 2002. http://www-3.ibm.com/software/ts/mqseries/library/whitepapers/mqover/.
Java Message Service, API for accessing enterprise messaging systems from Java Programs, Version 1.1, Sun Microsystems, Apr. 12, 2002. http://java.sun.com/Download5.
S. Michiels, F. Matthijs, D. Walravens and P. Verbaeten, DiPS: A Unifying Approach for Developing System Software, The 8<SUP>th </SUP>Workshop on Hot Topics in Operating Systems (HotOS-VIII). May 2001.


Join artist and educator Kristin Webster weekly for an hour and a half of exploration, experimentation, and joy-filled art making! We will learn about art supplies, artists, and techniques in this series of water-media classes. Each month we will focus on a different aspect of painting with watercolors or acrylics.


Show off your love of one of Pink Floyd's greatest albums with this Dark Side of the Moon coffee mug! Black ceramic mug features the band and the prism art work from the cover of their 1973 album Dark Side of the Moon. Sure to make a great gift for your favorite Pink Floyd fan! Officially licensed.


The famous Pushkar camel fair describes the rich culture of Rajasthan. The enchantment of Pushkar fair cannot be compared with any other festivals in India. The drowsy tiny parish, Pushkar in Rajasthan becomes alive with a fusion of colors and energetic burst of activity at the time of the fair.
Pushkar, a small town in Rajasthan is a great place to visit for spiritually inclined people to have a glimpse of colorful mythology of the Hindu religion. It is surrounded by hills on three sides and sand dunes on the other; this sacred town of the Hindus is blessed with over 400 temples and 52 bathing ghats.
The Pushkar Camel Fair is celebrated for five days from Kartik Ekadasi to Kartik Poornima (usually between late October and November). In 2017, the official dates for the Pushkar Fair are October 23 to November 04. It is the time when Rajasthani farmers gather to buy and sell their camels, cattle and horses.
According to the hindu mythology, it is the time when the Hindu god Brahma sprung up the Pushkar Lake, On this day devotees take a bath in the Pushkar lake.
It is a majestic occurrence in which more than 400,000 people and 50,000 animals such as camels, horses, cows, goats, and sheep participate and millions of exhibitors come to enjoy in delight from all over the world. Pushkar Fair is the largest cattle fair in the country; especially meant for enjoyment and merry-making.
This annual Pushkar Camel fair brings together farmers, livestock, traders and villagers from all over Rajasthan. This huge gathering contains a Technicolor parade of dancers, musicians, magicians, dancers, acrobats, snake charmers and carousel rides to entertain the crowd. Men in huge dazzling turbans, women in pleated Ghagaras and colorful bangles give the fair an utmost charm of a festival.
Here you can take part in some fun activities, such as a game of tug of war, a cricket match, a competition for the longest moustache, a camel beauty-pageant and a turban-tying contest purely for foreign visitors.
The main highlight of the Fair is the beauty completion of decorated Camels. The camels are dressed up like a groom, they washed spanky clean, shaved and decorated with the jewelry like Silver bells and bangles, after that they entered into beauty contests. Best camel wins the Prize.
Beautifully decorated camels perform parade, race and dance to attract the buyers. In another completion the camel accommodate the maximum number of peoples on his back.
This fair would be incomplete without different stalls and arts, crafts bazaar. The stalls and sellers exhibited the picture of colorful Rajasthan in front of the curious tourists. You can also get a taste of Rajasthani food at stalls. Tourists can enjoy some delicious vegetarian food like daal baati choorama, Mirchi ke pakode, Dal Ki Kachori, Malpue etc.
Another highlight of this fair is the International Hot Air Balloon Festival. This is also held during the fair. You can witness this huge Camel fair from the sky in a Hot Air Balloon.
Body painting is also an attraction of the fair. The experts offer various designed tattoos to the peoples. The bright colored tents, traditional costumes and the sand dunes are a complete treat.
So come and enjoy this grand Camel Mela in Rajasthan.
Author hippyPosted on April 10, 2017 April 16, 2017 Categories LeisureLeave a comment on Going Goa this Monsoon!
A rendezvous with India's Mini-Switzerland, Khajjiar, in Himachal is simply breathtaking.
"Often called India's Switzerland, the exquisite glade of Khajjiar, 1960 m has a circumference of about 5 km. Along its fringes, thick forests of deodar climb the slopes, the snow-line rests above these woods…," says the government run website, which intrigued and hooked me to this quaint and resplendent valley.
Still not heard of Khajjiar?
Khajjiar is tucked away in one of Himachal's most northern fringes of Dhauladhar circuit, away from the squalor of cities and untamed urbanization. Not many tourists are aware of this valley. Usual crowd heading to Himachal would go to the done-to-death 'Shimla—Kullu-Manali' route. But if you want something different and quiet, you should head to the Dhauladhar circuit. The nearest commercial town to Khajjiar is Pathankot, but that's more than 100 kms away. Pathankot is also the nearest railway head if one wants to reach Khajjiar from New Delhi.
Hence, I decided to plan our journey to Khajjiar through a combination of railway and road trips. We took the Dhauladhar express from Old Delhi railway station. The train departs at 7.30 pm and arrives at Pathankot railway station next day at 8.20 am. Quite interestingly, we had to struggle our way through Delhi's maddening traffic to catch this train. We caught hold of the train by a whisker. The moment we reached Old Delhi railway station, it was already 7.15 pm and we had to just rush our way through the crowd to the platform.
However, after we stepped onto the train, we actually thought, our trip to Khajjiar is still on. The train was surprisingly on time and we arrived at Pathankot for our onward journey to Khajjiar. We had arranged for a pick up through our hotel (Mini Swiss, Khajjiar); and as we stepped out of Pathankot station, we occupied the cab. Some friendly conversations ensued with the driver and in a moment, we could see the beginning of the hills.
After an hour's drive, we stopped at a Dhaba (restaurant) for our refreshments and breakfast. We didn't have much though – just a hot piping Aloo Parantha, dipped generously with butter – and a cup of tea. Zarak, our two year old had to have his mouthful as well and his mother generously helped him have his baby food. The uphill journey began to unveil gradually, as we curved our way through pine and deodar covered forests and ridges in the Himalayas.
After a drive of over 90 kms we realized, we have reached Dalhouise. We knew that this hill station was on our itinerary and hence we didn't quite get down to hover around a bit. Our excitement was obviously palpable and we managed to hold on to it tightly. At 1.30 pm we arrived at our hotel in Khajjiar. Hotel Mini Swiss is not one of those three or four star hotels that packs in all amenities and facilities, but nonetheless provides a comfortable accommodation, with friendly staffs. It is one of the very few resorts in this area – Hotel Royal Residency and the government owned resort – being the other ones. A quick shower in the mildly cold waters, a cup of tea and we were ready to head to the majestic meadows of Khajjiar valley. The meadows were in fact a stone's throw from our hotel and comes across as a pristine undulating landscape with a lake at the centre.
The meadows were surrounded by a sheath of deodar trees throughout and buzzing with activities (I was told this ground looks completely different and covered by snow in the winters). It was a bright sunny noon and quite expectedly, tourists have thronged this place from nearby state of Punjab, Delhi and far off places such as Kolkata and Tamil Nadu. One could stroll around this verdant landscape for hours, have food or snacks from hordes of roadside stalls or take a slow pony rides. We bargained for it and got a deal of Rs 200 for a roundabout trip of the meadows.
The lake at the centre of this landscape looked quite dry and could have been managed well by the tourism department. It appeared bit scruffy. Tourism plays a vital role in Himachal's economy. It is one of the three major mainstays for the state's gross domestic product, the first two being hydro-power and horticulture.
Nonetheless, we spent a good two – three hours here and enjoyed the sun, breathed in the fresh air and experienced the mist and the clouds. We gave another activity – zorbing – a miss though.
Next day, we headed to the heart of Chamba valley. The town, at a distance of 26 km from Khajjiar, has a brisk population and we could see exciting people in the festive mood. It was Dusherra and locals were seen gathering in large numbers in the main market ground.
However, we parked our cab, got down, and went around the town. Our first disappointment – the Museum was closed as it was Dusherra; dejected we went around strolling to see the Lakshmi Narayan temple. It looked quite resplendent, and we did manage to click few images capturing its architectural magnificence. There were few steady tourists around and they chatted blithely, taking selfies.
We began our day next, early with a quick breakfast and headed for the trekking point in Khajjiar. The trek was marked distinctly and by the time we reached, we could see a bevy of tourists already lined up for the trek. The trek was a sharp 4 km up hill and we joined in our excitement to reach the peak. All the hard work and efforts paid off when we got to see the view of the nearby hills and forest cover from atop the misty and cloudy peak.
Done with our adventure and achievement, we headed straight to the historical town of Dalhousie. The town had an insane old world charm to it – the post office, church, schools and the ambience was magical. The weather was brilliant to say the least. It seemed, we are walking on the clouds. We got down at the chowk and took a stroll sampling a dish of locally made Momos.
A walk down little further and we spotted Sunil. He is the town's most popular 'two wheeler restaurant'. If you have been to Dalhousie, chances are you may have come across Sunil. He can be easily seen selling fast food items at a brisk pace to tourists near the Dalhousie chowk. He usually sells omlette, french toast and hot piping noodles in his humble mobile scooter. He doesn't have a printed menu, unlike a physical restaurant. All his food items are named in the body of his yellow scooter. He proudly flaunts a framed article of his interview given to a popular Hindi newspaper.
Sunil was surrounded by customers, when we caught hold of him. How long have you been selling here, I asked, curiously?
"20 years," pat comes his reply. In Dalhousie, you can also spend time and shop at the local Tibetian market and visit the Church.


text:
Q: Install GMP library on Mac OS X 10.9 and Xcode My question is as simple as the title. I have a Macbook Pro with OS X Mavericks (10.9.4) and Xcode (5.1.1). I need to install the GMP arbitrary precision libraries so that I can just get to write GMP-enabled programs from within Xcode.

*

*I downloaded the package from the official website

*I extracted it to my desktop

*./configure --prefix=/usr/local --enable-cxx

*make

*make check

*sudo make install
But when I go to Xcode and just #include <gmpxx.h> it doesn't find it. Also adding -lgmp to my linker flags causes an error.
I also tried using homebrew with brew install gmp but that didn't work either (same symptohms)
What is the correct way to solve this problem?

A: You need to ensure that you have an include path -I/usr/local/include, before you can include <gmpxx.h> (or <gmp.h> for that matter).
Also, adding -lgmp is insufficient, since that's only the C interface. You want to link with -lgmpxx (the C++ library), and possible specify the path to that library with -L/usr/local/lib.
You can run otool -L /usr/local/lib/libgmpxx.dylib, to ensure that libgmp.dylib is already linked to it. Which it should be.

A: Set the Header Search Path and Library Search Path in the Xcode Project Settings to /usr/local/include and /usr/local/lib respectively as, by default, these paths are not searched by Xcode.

redpajama_set_name: RedPajamaStackExchange


text:
Шърми (Shermy) е от ранните герои в поредицата карикатури Peanuts на Чарлс М. Шулц. Въпреки че казва единствената реплика в първата карикатура и е една от главните фигури в началните години, но е засенчен от новите герои, които са по-усъвършенствани, като Лайнъс и Луси например. Неговото премахване от поредицата е дори по-бързо, от колкото това на други герои- Пати и Вайълет. Още през късните години на 1950-те, неговите изобразявания стават забележимо по-редки. Главната физическа отличителна черта на Шърми е късата му тъмна коса, която обикновено е с подстрижка тип "канадска ливада".

Шърми има само една реплика в диалог от 1965 в специалния телевизионен анимационен епизод A Charlie Brown Christmas. След като е избран за пастир в драматизацията на историята за Коледа, той се оплаква: "Всяка Коледа е същото- аз винаги съм пастира.".

Шърми на практика изчезва от поредицата карикатури като основен герой през 1970. Веднъж е споменат през 1977 в карикатура, в която Чарли Браун и Луси дискутират играчите в техния бейзболен отбор.

Герои от "Фъстъци"

redpajama_set_name: RedPajamaWikipedia


text:
A View from the Bridge
Written by Arthur Miller
Directed by Charlotte Gwinner
Presented by Liverpool Playhouse & Everyman
Liverpool Playhouse
27 March - 19 April 2014
Photograph by Stephen Vaughan
This classic play, written in 1954, is still highly relevant today given the extreme xenophobia prevalent around the world, directed towards immigrants, whether they be legal or illegal newcomers to a country.
Set in the dock areas of Brooklyn, populated predominantly by working class people, the industrial noise pounding away outside the theatre (renovation work is being carried out at a building nearby) added unintended poignancy to the impressive production by Playhouse Associate Director Charlotte Gwinner, winner of the national Quercus Award, presented to a director of outstanding promise.
If this is a measure of what she can create Gwinner is on a winner in the world of theatre.
Longshoreman Eddie Carbone (a sterling performance by Lloyd Hutchinson), with the persuasion of his wife Beatrice (Julia Ford), allows her two Italian cousins Rodolpho (Andy Apollo) and Marco (Daniel Coonan), both smuggled into the USA from Sicily, to stay at their home and work on the long ships.
But Eddie's amiable attitude towards them soon turns to displeasure, particularly Rodolpho, when he starts to woo his adopted niece, virginal 17-year-old Cathy (Shannon Tarbet), who falls under his spell.
Eddie becomes increasingly bitter about their blossoming relationship, displaying emotions of anger, jealousy (Eddie's affections for Cathy are not entirely reputable), and the impending loss of seeing her leave the household.
Eddie utters on two or three occasions "No one gives me respect", but he has little respect for himself, set in his ways and leading a life of little scope or ambition.
Like a lover spurned for someone else, he cries out "Who is this guy?", in reference to Rodolpho, ridiculing him for his multi-faceted skills, including his singing prowess on the boats and, most annoyingly to Eddie, his dress making flair.
Eddie who has lost his sexual attraction for Beatrice (the reverse is also probably true), becomes disillusioned with his refusal to let Cathy become a young woman and venture forth in life.
He becomes increasingly estranged from his family and friends, as well as his lawyer cum confidant Alfieri (Bruse Alexander) - who is the narrator of the story - losing sense of who he is and what he stood for, is dealt an untimely blow but not at the hands of who you might suspect.

redpajama_set_name: RedPajamaCommonCrawl


text:
Podcast: Can We Prevent Rape On College Campuses?
Ep. 22 Special guest Dr. John Foubert addresses an innovative program on college campuses.
Dr. John Foubert is the national president of One in Four, a professor at Oklahoma State University author of several books including most recently How Pornography Harms.
One In Four is a national nonprofit dedicated to sexual assault prevention, focusing on college campuses and military bases. This organization conducts prevention presentations to teach men and women alike about the harms of rape. Research shows that these programs lead to a 40% decline in sexual assault behavior by male participants and that it increases bystander intervention among women.
In this podcast episode, Dr. Foubert explains the success of this sexual assault prevention program and some of the root cultural influences that make it necessary to combat false beliefs about rape.
1) SUBSCRIBE to our podcast. It's available on iTunes and on Google Play, and this episode is also available for direct download.
2) DOWNLOAD the existing episodes.
3) RATE it (we'd love 5 stars!).
4) SHARE this with your friends, networks, social media, etc.
Read Dr. Foubert's Book: How Pornography Harms
Connect with One in Four: OneInFourUSA.org
Learn more: www.johnfoubert.com
Haley Halverson
Vice President of Advocacy and Outreach
Haley Halverson is the Vice President of Advocacy and Outreach at the National Center on Sexual Exploitation where she develops and executes national campaigns to change policies and raise awareness. Most notably, she promotes corporate social responsibility by constructing annual activism campaigns like the Dirty Dozen List, which names 12 mainstream private companies that facilitate sexual exploitation. Her advocacy work has contributed to instigating policy improvements in the native online advertising, retail, and hotel industries.
She is a member of the Washington DC Mayor's Advisory Committee on Child Abuse and Neglect, September 2018-2019. This Committee advises DC Mayor Muriel Bowser on the multi-faceted continuum of the District of Columbia's child welfare services, including prevention, early intervention, treatment, and sources of permanency.
Haley regularly speaks and writes on topics including child sexual abuse, sex trafficking, prostitution, sexual objectification, the exploitation of males, and more. She has presented before officials at the United Nations, as well as at several national symposia before influencers from the Department of Justice, Department of Health and Human Services, the Federal Bureau of Investigation, and Croatian government officials. She has provided training to Arlington County Child & Family Services on the social media grooming, recruitment, and advertising for sex trafficking. She has a Master of Arts in Government from Johns Hopkins University where she received honors for her thesis regarding the online commercial sexual exploitation marketplace.
Previously, Haley served for two years as Director of Communications for the National Center on Sexual Exploitation where she oversaw strategic messaging development, press outreach, email marketing, and social media marketing.
Prior to working at NCOSE, Haley wrote for Media Research Center. Haley graduated from Hillsdale College (summa cum laude) with a double major, and conducted a senior thesis on the abolitionist argument regarding prostitution. During her studies, she studied abroad at Oxford University and established a background in policy research through several internships in the DC area.
Haley has appeared on, or been quoted in, several outlets including the New York Times, NBC's The Today Show, BBC News, New York Post, USA Today, Chicago Tribune, Fox News, San Francisco Chronicle, the Washington Post, Yahoo News, Voice of America, Dr. Drew Midday Live, The DeMaio Report, the New York Daily News, the Washington Examiner, USA Radio Network, the Washington Times, CBC News, The Rod Arquette Show, The Detroit News, Lifezette, The Christian Post, Lifeline with Neil Boron, EWTN News Nightly, KCBS San Francisco Radio, LifeSiteNews, The Drew Mariano Show on Relevant Radio, News Talk KGVO, and American Family News.
She has written op-eds for the Washington Post, the Huffington Post, FoxNews.com, Townhall.com, Darling Magazine, the Daytona-Beach News Journal, and has been published in the Journal of Internet Law and the journal Dignity: A Journal on Sexual Exploitation and Violence. She has also contributed to a digital middle school curriculum regarding the links between sex trafficking and pornography as well as the public health impacts of sex trafficking.
Will YouTube's COPPA Improvements Address Pedophile Comments on Kids' Videos?
An Open Letter to Delta for Providing Sexually Explicit In-Flight Films
Campus Sexual Assault | college | podcast | pornography | prevention | rape | Sexploitation
RECAP: Symposium Confronting the Rise of Child-on-Child Harmful Sexual Behavior
NCOSE 2018 Impact Report: The Fall of Online Trafficking Titan Backpage; Walmart Removes Cosmo; Comcast Safer for Kids; And More!


text:
Q: Solve $8 \log(x) - x = 0$ Someone came to me recently with this seemingly simple equation to solve:
$$8 \log(x) - x = 0$$
So far, everything I have tried has been a dead end. Is there a symbolic solution to this kind of equation? If so, how do I get there?

A: $$
8\log(x)=x\Rightarrow -x/8\ e^{-x/8}=-1/8
$$
Therefore,
$$
-x/8=\mathrm{W}(-1/8)\Rightarrow x=-8\mathrm{W}(-1/8)
$$
where $\mathrm{W}$ is the Lambert W function, the inverse to $x=we^w$.
Mathematica yields $1.1553708251000778334$, and $26.093485476611910215$ as the two real solutions: N[-8 LambertW[0, -1/8], 20] and N[-8 LambertW[-1, -1/8], 20].
For those lacking a CAS like Mathematica, I have outlined an algorithm to compute Lambert W.