Problem Solution |
||
  Delta Lt dopel Some time has passed so I can reveal my solution to this problem. Only pseudo code will be included in this post. The actual code will be posted as the implementation part of the challenge in a separate thread. This post will serve as a textual method of solving the proposed problem. Many of the details of how the code will actually work will also not be included in this post. This is meant to be a high level summary of the planning stage of the solution. You must first understand the problem and how to solve it logically before code can be written. The goal of this exercise is to provide a means of passing data between two single threaded client scripts using only an HTTP POST. We must also do this without significantly affecting the performance of the client script. This problem can be broken down into smaller pieces. I will describe them in terms of the source, the messenger, and the message. The Source� Here we have our client script. We know that this script is generating data and delivering it to the user. We also know that that this data is dependent upon information being generated by a similar script on another host. The basic client script algorithm is as follows� begin loop
process_data() � These details are not relevant for solving the problem
build_xml_message() � I have chosen to use XML to pass the data. A simple single value message is sufficient to demonstrate the solution.
Response = htttp_post(xml) � Does as it says. It simply sends the message and receives a response.
If (isValid(Response)){
Process_xml()
}
end loop
--We assume that this response will come back in a negligible amount of time. We can make this assumption for two reasons.1. The target of our HTTP post will be local. 2. The target will handle message queuing and communication with the other host. -- Notice the immediate response (valid or invalid) implies there will be minimal delays to the client script. Thus we satisfy our performance requirement. The messenger� This piece is the meat of the solution. For our client to work as expected, we need a bridge that can both receive HTTP posts and distribute responses from both clients. Now to have a central server of some sort would add latency to our client requests. It would also add a level of complexity in future maintenance and over cost of the implementation. With this in mind, I have chosen to have each client run its own local messenger service. This service will act both as a server for incoming requests and a client to pass messages between hosts. The idea is that when a client posts a message, the messenger will connect to the messenger on the other client and pass the message. The messenger will then respond to the original requestor. main(){
open_listen_socket()
while(listening){
spawn_connection_thread() � when a connection comes in, we issue off a thread as to not block other incoming connections.
}
}
spawn_connection_thread(){
msg = read_socket()
if(isfromClient(msg)){
open_connection_to_messenger()
write_msg(msg)
}
if(isFromMessenger(msg)){
-- We want to add messages to a queue to ensure both ordering of responses and to ensure no messages are lost.
enqueue(msg)
}
if(qHasMessages()){
write_socket_response(dequeue())
} else{
write_socket_response(defaultMessage) � AKA Send back garbage XML so client can continue processing.
}
}
The Message�The messages themselves can remain very simple and once we achieve the passing of data, the content can be changed at will. What is important is that the messages need to contain a structure that is standard as to allow the code to determine the differences between messages. So we end up with three XML message types, request, responses, and garbage. -- Original request from client script <?xml version="1.0" encoding="UTF-8"?> <qtp-request> <submit> <dField>SOME DATA</ dField > </submit> </qtp-request> -- Response generated by the messenger <?xml version="1.0" encoding="UTF-8"?> <qtp-response> <submit> <dField>SOME DATA</ dField > </submit> </qtp-response> -- Response generated by messenger when there was no data in queue to respond to the request. <?xml version="1.0" encoding="UTF-8"?> <qtp-response> <dField>EMPTY</ dField > </qtp-response>The implementation will follow soon. I want to give anyone actually working on this some time to code his or her own solution before spoiling it. Good luck and happy coding : ) Replies:
|
||
| CyberArmy::Forum v0.6 Generated In 0.00671 seconds |
2008-03-17 12:45:10