When I draw a network diagram with, say, browser A communicates with http-server B which talks to a database C, I draw the nodes for A, B and C and edges between A and B and between B and C. Then I want to materialize the flow direction by adding arrows. On which side should I place the arrowheads?
alt text http://www.forteresse.net/site/stack-overflow-question/image
Variant 2 is the intuitive one, but IMHO, the variant 1 is the correct one since the data is really flowing from B towards A.
I want to indicate that the browser is accessing the http-server for reading a web page, for example A is browsing http://www.xyz.com
So, are there any references to help me on this?
If it's a diagram of "what the user is doing", the user is going from client to server.
If it's a diagram of "where data is going", the client is passing a string to the server, and the server is returning a string to the client; it can be a two way arrow.
I'd probably go with Variant 1. "The browser is accessing" is a one-way operation.
When you want to indicate that data is sent from (Client)A to (Server)B, draw the arrow from A to B. When you want to indicate that data is sent from (Server)B back to (Client)A, draw the arrow from B to A. Data can flow both ways.
In regards to your slashdot reference, when the (Client)A wants to browse to Slashdot.org, it makes a request to the server, so you would draw an arrow from (Client)A to (Server)Slashdot.org. When Slashdot receives this request, it sends back a response to your client to render Slashdot in your browser, so in that case you would draw an arrow from Server(Slashdot.org) to (Client)A.
Here is a simple reference explaining it:
http://computer.howstuffworks.com/web-server1.htm
Related
I'm trying to make a simple program in GNU Radio to help understand (and test) the encryption blocks. I have attached a screenshot of my program. Basically, it takes a picture of a cat from a .png file and sends it to another.png file. I sent it three ways so as to see how it behaved. One way went straight from file to file, one went through only encryption, and one went through encryption and decryption. With the lower half of the program (the encryption and decryption) disabled, it works on the first route, but when I enable the lower half in an attempt to simultaneously do all 3 paths, the first path only sends the top half of the cat image, and the other two don't send any data to the files at all. The image of my program can be found in the link above this post. I'm new to this so my apologies if this was a bad post, but thanks in advance for any help.
I would like to build from scratch a kind of small (extremely small and simple) MMORPG game with click movements inside a given grid (something like an online Pokemon game). When I click on a cell, the player will move to reach the pointed area (using a pathfinding algorithm such as A*). But, I have no idea about how to build the network protocol of the movement system. And, googling the subject doesn't seem to help me a lot. I need to make a choice: - either I send a message to the server each time I move from one cell to another (which isn't efficient at all because if we are in a 100ms latency network, I can only sens 10movements/sec and if I ask the server to acknowledge the movement it can only do 5moves/sec) - either I send a message each time the player wants to change its direction (it clicks on another cell). The client sends periodically its position to the server and it checks if it's coherent with the destination.
The second solution looks a lot better than the first one and I think that a real game systems must implement that strategy. Am I wrong?
Also, how can we build systems based on that solution that doesn't let a modified (hacked) client be able to send fake positions and teleport anywhere they want? Does real systems implement somethink like a "incoherent sent position" system that will try to try to detect and fix those problems?
Or, is there something simpler to implement? Thank you very much
In a realtime game I would create a panthing mechanic. I would use a formula such as: Speed * time = distance.
now if you run the same logic in the client and the server you only need to send the movement logic at the beginning and the sever can answer with a finish message when the distance is traveled. (compare at the end to prevent cheating. the server always wins)
Now if the client cancels in the movement to go somewhere else, you send a cancelation of panthing and the time that you traveled. The same goes when changing the panthing (in this case you send a new path staring at a new time and place).
Thanks to ScarletMerlin's answers I think there's a simple solution to my problem.
When the player wants to move from one position (for instance 0,0) to another (for instance 10,10), it sends a "MOVE 10 10" message to the server.
Then, only the server will apply the pathfinding algorithm and send after each move the position to the client. (for instance, by message CURRENTLY_ON X Y). Then, the client will update the position of the player.
It's a kind of automatic synchronisation from the server to the client. It also solves the problem of the first solution (one move and one ACK per movement) thanks to pipeling. For instance, if the network has a 1000ms delay and a move is set 50ms, we will just receive messages at time 1000, 1050, 1100, 1150, ... So, we will just feel the lag when the player is changing its direction.
The user will also feel some lag when changing from one direction to another but if we assume that the delay is quite low and symetric (it doesn't seems to be a too strong assumption), it won't be so much percepted (as the change direction will often arrive before the sending of the CURRENTLY_ON message and the server can interrupt its current action (going straight on) to handle the new one).
I am building a Chord DHT in Go (however the language part isn't important).
And I am trying to figure out the response behavior between nodes. If I want to send a successor request message to Node C, but it has to go to Node A -> Node B first, then arriving at Node C. What is the best way for Node C to respond to the original Node.
I have come up with the distinct methods, but dont know which one is more idomatic for DHTs.
When each node makes a request, it waits for the response on the original TCP connection, this makes it so the response takes the reverse path it originally took
Make the request then forget about it, when Node C recieves the request it sends the response directly back to the original node, indicated by the sender (IPAddress) field in the request message.
Send the response to the sender NodeID just as it were any other message, so it would be routed around the Chord ring.
I cant figure out which is the best method to use.
The only reason you use routing in Chord, is to find resources. That's why you shouldn't just know the accessor and predecessor but also additional nodes in distances of 2^n. This way you can achieve a lookup performance of O(log N). You can read the Wikipedia article about Chord for details.
So you should attach to the message you are sending to Node C the source-node's address, so that C can respond directly. This will have a much better performance over all.
I already have an A* Implementation that works. The problem is that if you pick a destination that is unwalkable, no path is returned. I want to be able to get the 'closest' I can get.
The preferable option would be completely dynamic (not just checking the 8 tiles around the destination to try to find one). That way, even if they click an unwalkable tile surrounded by a huge square of unwalkable tiles, it will still get as close as it can.
While the simple answers provided here MIGHT be sufficient enough, I think it depends on your game type and what you're trying to achieve.
For example, take this play field (sorry I'm reusing the same software I used to show you the fog of war :)) :
As you can see, an Angry Chicken is blocking the path between the left side and the right side. The Angry Chicken could be anything... if it's a static obstacle, then going with the lowest h node might be enough, but if it's a dynamic object (like a locked door, draw bridge, etc...) the following examples might help you find out how you want to solve your problem.
If we set the destination for our Hero on the other side
We need to think what we want the path to be, since obviously we can't reach it. Using a standard heuristic like manhattan distance or euclidian distance, you will get this result:
Which might be good enough, but if there's any way our little Hero could interact with the chicken to pass, it doesn't make sense at all, what you want is this
How can you do this? Well, an easy way to do this is to pathfind on hierarchical graphs. This sounds complicated but it isn't. First, you want to be able to build a new set of high level nodes and edges that will contain multiple grid nodes (or other representation, wouldn't change a thing)
As you can see, we now have a right blue node and a left red node. The arrow represents the edge between the two nodes. How to build this graph you ask? It's easy, simply start from an open node, expand all of its neighbors and add them to a high level node, when you're done, open the dynamic nodes that could lead to another part of the graph and do the same.
Now, when you ask for a path from our Hero to the red X, you first do the pathfinding on the high level... is there a way from blue node to red node? Yes! Through the chicken.
You can now easily know how to navigate on the blue side by going to the edge that will allow you to cross, which is the chicken.
If it was just a plain wall, you could determine very quickly, by visiting a single node, that there is NO way to reach on the other side and then handle it the way you want, possibly still performing an A* and returning the lowest h node.
You could keep a pointer which holds a tile with the lowest h-value, then if no path is returned simply generate a path to the tile you're holding onto instead.
i am developing a multiplayer roleplaying game, (No, its not a mmorpg. ;)
My current setup is like this.
Client tells the server "I want to move forward"/"I want to move backwards", the server then updates your entity, and informs all clients in the area about the change. The server is also updating each entity every 20ms and sending updates every 100ms to the clients, these updates contains position, velocity, rotation etc.
So far so good, however i have nothing in store for smoothing the movement between the packets on the client side, and i must say, i can not get it working. I have been reading up on prediction, interpolation, deadreackoning but its all a big mess for me.
So right now i am just doing something like "Position = Packet.Position", which causes a very stuttering movement.
So, what i want help with is, how do i get a more smooth movement? Have been looking at the XNA Prediction Sample, but i could not get it right.
Thanks //F
Read Valve's description of their multiplayer protocol. It should be instructive, and gives a very clear example on how you do the prediction/interpolation.
I'd suggest the idea from another question (see the accepted answer)
Here the client calculates its position itself as if its not a network game. Client regularly sends his current position to the server. And if client cheats or can't continue moving in the chosen direction, server just sends the client his correct position.
The same algorithm was used in Ultima Online (at least when I was playing it 10 years ago)
I solved it by running a ghost entity alongside with my main one.
The ghost will get updated every frame aswell, but whenever a packet comes in, his values are set to the values of the packet.
I then gradually tweak the real entity to where the ghost is.