Got a question for a programmer or network admin/engineer...

XMEN Ashaman DTM · Post by **XMEN Ashaman DTM** » Fri Feb 27, 2004 4:03 pm

Okay... here is the problem: I would like several machines of varying computing power and varying connection data rate to be connected together and work on the same problem. In my experience, this problem is similar to having formation flying and mission sharing/planning/execution for autonomous vehicles. It also applies to your regular client-server model for games. Here is what I have thought about so far: Semi-Parallelized Computing: Want several computers to update each other on their respective viewpoints of the workspace. We do NOT want a server in there to delegate where the data is sent and when it is sent. To this end, I've come up with the following scenario: 1) Define Workspace to be shared 2) Schedule workspace updates at end of current time-step. 3) Send updated workspace variables to network que at start of next time step. 4) If info isn't transmitted, increase the size of the network que to accomodate a second workspace update (or use more of the allotted network que). This has to be done on each machine. The problem with just sending the data out to the other clients is that your sending machine has to que copies of the updated data for EACH of the other clients. It makes a BIG bottleneck on the sending end of things. My next thought was along this line: What if you take the data to be sent, sent it to another client and that client acted as a repeater for the original client, with the condition that the repeater could not send data to the originator. From my analysis, this idea ran into the problem that after the repeater, the next client/repeater would send a copy of the original data back to the original sender. The sender would be bombarded with copies of its own data from all the clients after the first repeater. That problem is taken care of if you have a client-server model: all the clients send their updates to the server, and the server distributes the clients' data so that all the clients are updated the same time. So I thought about taking the server out of the system, as I originally wanted. That brought me to having this idea: That computers that are close to each other in the workspace share update information first. Then the updates are sent out to the clients that are working on parts of the workspace that are farther away. Think about a table: two clients are working at one of the legs, and a third client is working on a leg at the opposite corner. That means that the two clients close to each other will have to update more quickly (as their work depends on the other client's data). As I thought of this, another thought occurred: that the synchronization of ALL of the clients can be done by using the transmission protocol's inherent reliance on a universal time. In the case of the internet, this is done with respect to GMT, which is adjusted according to several atomic clocks throughout the world. The problem that I realized from this approach was that if you have many clients close to each other, you start to clog your network with too much data as the close clients try to synch each others' updates. This led me to realize a few things: There has to be a way to determine a client's connection data carrying capacity (data rate). There has to be a way to determine a client's machine's computing power. A way to delegate which machine(s) handle more of the data needs to be found. This last is should be similar in concept to autonomous formation flying/task scheduling for UAVs. (Which is where my experience comes in.) The thing with autonomous formation flying UAVs is that one update is sent to ALL machines at once. This is done via some for of radio. The internet and other similar networks is not like that: each communication is serial in nature. In other words, on the internet, you can only send data to one machine at one time. This led to wanting to test the connection carrying capacity of clients. And wanting to test the computing power of each client. This is done with something similar to a 'ping' command (just like you are testing for ping and packetloss in a game), and by having a client perform some math operations on a data set, and increasing the size of the data set to approximate several clients' data. I have that last paragraph down. The next thing to do would be to prioritize the machines. To do that in real life, you'd need to have all the machines register some kind of identification with a secure website (just something that all machines can look to for a list of computers, and their locations in the workspace). I'd imagine that once that is done, that the computers nearby are ranked according to their connection first, and their computing power second. The higher ranking computers get more of the data in the workspace to work with, AND they get more updates from the other machines. I'm thinking that ALL of the computers on the list will be ranked relative to each other so that the ones able to handle more data are higher on the list. This should work even if the computers are all at the same computing power, because their connections are different. Now... My questions are: Did I make any mistakes? Can this be done? I know that this sort of thing can work with multiple aircraft. But computers are not always the same. <img src=http://www.ezboard.com/images/emoticons/wink.gif ALT=";)"> Thoughts? If you're wondering why I'm thinking of this, I'm trying to work out an alternative to the client-server scenario. Yet one that is not completely parallel as in a cluster.

Post by **XMEN Gambit** » Sat Feb 28, 2004 11:56 am

Not ignoring you, Asha, but I've not had time to give this the thorough going-over it needs. Back later...

XMEN Ashaman DTM · Post by **XMEN Ashaman DTM** » Sat Feb 28, 2004 4:35 pm

No problem. I'm most concerned with load balancing. <img src=http://www.ezboard.com/images/emoticons/wink.gif ALT=";)">

Post by **XMEN Gambit** » Tue Mar 16, 2004 3:49 pm

Ok, had a look at some of this, and if I'm correct you've made a couple of incorrect assumptions. The first being, there are ways to "broadcast" packets to each machine on a network or subnet. For TCP/IP, refer to UDP packets. The problem with UDP packets is that there is no acknowledgement of the packet being recieved, so it could be missed. One of the network models that you mentioned is similar to a token-ring network, where each machine passes info to the next. The way to manage something like that would be similar to managing a linked list programming structure; it could be forward only, doubly-linked, or whatever, each machine knows only about the machine(s) directly next to it, etc. As I was reading, one thing I pictured was that each machine broadcasts the key for the unit it is working on (to prevent duplicated work) when it starts, and also broadcasts the result when it finishes computing. Each machine notes which machine is working on which unit. Without a central server, each machine must store this WiP info and the results of each other's units of work (or you need a somewhat more complex scheme where only certain other machines do). It cannot store only its own results because it could be pulled out of service (crash) at any time, and if you run a ring-type network the results could be ugly when a machine or set of machines drops. Depending on the size of the network and the work units, this distributed storage of work in progress and results may or may not be practical. If the work unit size can be adjusted, tuning the network becomes easier. <img src="http://www.xmenclan.org/xmengambit.gif"/> XMEN member Card-carrying DTM OKL Fish-napper Though a program be but three lines long, someday it will have to be maintained.  The Tao of ProgrammingEdited by: <A HREF=http://pub141.ezboard.com/bxmenclan.sho ... ambit>XMEN Gambit</A>  <IMG HEIGHT=10 WIDTH=10 SRC="http://www.xmenclan.org/images/x.gif" BORDER=0> at: 3/16/04 6:47 pm

XMEN_Hammer · Post by **XMEN_Hammer** » Tue Mar 16, 2004 5:43 pm

Yaaa what he said <img src=http://www.ezboard.com/images/emoticons/tongue.gif ALT=":p"> <img src="http://www.xmenclan.org/avatars/hammer_ ...  Proud member ot the Soup Clan Proud Member of the XMEN Clan Proud Member of the Dragon Talon Mercenaries If you run, you will only die tired.

XMEN Ashaman DTM · Post by **XMEN Ashaman DTM** » Wed Mar 31, 2004 9:34 pm

Ah I see. Some of my assumptions were incorrect then. If you can vary the amount of data sent between machines, would it be a viable option as I originally described? I don't have any firm ideas on how to throttle the data, and how to throttle the correct data, but I think that would help too. In any case, I was just trying to figure out a different model. Kind of like how Defense Turret works: each client validates the other clients' files and sends a "yea" or "nay" vote if the files don't work. When a client gets too many "nay" votes, it gets a disconnect packet from the server. But I guess in that instance, the voting info is sent to a central server. I was talking more about the way that DT on one client seeks information about other clients.

Post by **XMEN Gambit** » Wed Mar 31, 2004 10:40 pm

Mmmm, perhaps. I don't have a warm fuzzy feeling about it. I believe there are more optimal solutions. A big deal here is your requirement that there be no central server. Therefore, you either need to have every machine knowing what every other machine has done (not who, just what), or you need a scheme where you have "local" servers (kind of a multiple star config), or you need to link each machine to the next and have a scheme to "heal" breaks. The first (everyone has everything) is not difficult, not necessarily bandwidth intensive, but could very easily consume a large amount of storage on each client. Bandwidth and storage needs really depend on what you're doing. The second (the star) is pretty complex, but could be quite efficient. The third (ring) is again simple, but if a machine on one side of the network needs info stored on a machine on the other side of the network, the info has to be sent from machine to machine down the line or around the ring until it gets there, which is not only slow but doesn't scale well at all. A central server, or bank of servers, would help a lot by directing traffic, and it may or may not be a good idea to have it actually handing out work and storing results. <img src="http://www.xmenclan.org/xmengambit.gif"/> XMEN member Card-carrying DTM OKL Fish-napper Though a program be but three lines long, someday it will have to be maintained.  The Tao of Programming

Ambush Bug · Post by **Ambush Bug** » Sat Apr 03, 2004 10:14 am

Asha, you may want to do a little digging on IBM's old Token-Ring architechture. The problem Gambit mentioned of the ring getting severed was one they solved rather neatly by using a double-ring. To wit: You have two concentric rings connecting six machines. Let's say one of the machines goes dead. The rings, sensing that their tokens will no longer go through that particular machine, adapt in such a way that they 'fuse' together at the broken ends. This forms a larger ring that leaves the dead machine out of the network. Bad ASCII Art Example: <pre> Complete Double Ring: _____ /_____\ // \\ || || \\_____// \_____/Double Ring Fused At Top (Space is busted machine): _ _ /_| |_\ // \\ || || \\_____// \_____/</pre> Now this setup will protect you from one dead machine, but not two. However, if you're talking UAV's (which aren't connected via physical cable, but radio... or at least, that would seem the logical path), you may be able to get around that problem and have the radio links form up in whatever shape they need to bypass hosed units. Could be processor-intensive for your radio links, however (whatever those may be, and I truly don't know.) Can't say I can help with you any other aspects of your problem\\example right off the bat... that's more El Gambino's territory than mine.

Post by **XMEN Gambit** » Sat Apr 03, 2004 5:03 pm

Yar, that's one of the issues. One that concerns me more is the loss of data, if each machine is storing some info uniquely to itself because of the lack of centralization.

XMEN Ashaman DTM · Post by **XMEN Ashaman DTM** » Sun Apr 04, 2004 1:25 am

Well, what originally got me stuck on that idea that I mentioned above was applying UAV communications principles for squadron-level communications in a network. UAV's that fly in formation won't have to worry about synchronization or timing so much as in a network. You send your data out over the radio, and receive from the others. You kind of have to listen for each aircraft independently; meaning that only one aircraft can transmit data at a given time. That is unless you are using more than one antenna for the transmission. Or multiplexing the signals onto the same antenna; something that is extremely difficult to do with the timing involved. So when one aircraft sends out it's current info to all the others, the others receive the new info pretty much all at once. I was interested in applying the UAV idea to how current networks operate. Such as in a client-server type of deal. Even if you broadcast of of the data to each machine such that you are sending out the latest update in one block for each other machine, you still have to contend with the fact that the other machines have to listen in series. So I guess that begs the question: why not have one machine that is local to the workspace take on the task of scheduling transactions between the machines? Meaning, is it possible to have one machine accept the updates of the other machines nearby (in the workspace), and then relay all of that updated information to the other machines and itself? I guess the problem there is thoroughput of the data on the server-like machine and its connection. Hmm...

Post by **XMEN Gambit** » Sun Apr 04, 2004 9:46 pm

Well, if the purpose is to minimize the # of channels used, I'd suggest one tiny channel for data, and another channel for handshaking. You can use whatever algorithm you like to determine who gets to broadcast, using the main channel, next. However, I'm not sure that in a real autonomous UAV situation that you'd have enough data being transmitted that it would tie up a decent channel. That is unless you're planning on transmitting lots of pictures/video. Specific to the UAV situation, let's postulate that you've got a flock of little sparrow-sized bots to gather intelligence. To start with, you load basic info about the target and its location into all the bots, then let 'em loose. They know basically where they want to go based on GPS or whatever. No info needs to be passed around just yet - but let's make it more complicated. Say they need to fly fast and low. Now, when the front bots encounter an obstacle that they need to fly around/over, they can inform the other bots what they're doing and why, letting the later bots make a smaller adjustment sooner, and possibly allowing them to become lead bots themselves while the former leads recover from the obstacle. Likewise, they can ping each other so if one gets taken out by something the others will know and be able to focus more attention on avoiding the danger. When they arrive at the target they can surround it or fly around it or whatever to examine it from different angles, and each can then send a message home to mommy or store it until they can get home themselves, or whatever. Now, in this scenario, the main channel hardly gets used at all unless there's a problem or obstacle. Mostly the radio traffic is just periodic pings to find out if your neighbors are still with you. The UAV environment is completely different than the distributed problem-solving environment, in my view. <img src="http://www.xmenclan.org/xmengambit.gif"/> XMEN member Card-carrying DTM OKL Fish-napper Though a program be but three lines long, someday it will have to be maintained.  The Tao of Programming

Ambush Bug · Post by **Ambush Bug** » Mon Apr 05, 2004 12:06 am

This is kinda a derailing post, but I had an interesting idea for a set of UAVs--On-Call Tank Busting. Take your UAVs, arm 'em with one (or more, if they can carry more) anti-tank missiles. Give 'em general coordinates and let 'em loose. They take off and fly to the coordinate area (presumably a current battle) and maintain a nice holding pattern at Y altitude (20K feet? 60K Dunno.) Now, trooper Joe on the ground sees an enemy tank nearby. He doesn't have a LAW on hand, nor could he get close enough to use it if he did without getting shredded by enemy troops. So he whips out a handy little laser designator, points it at the tank and presses the button to call down one of the UAVs. Said UAV splits off from the pack, swoops down, and sends the missile plowing into the tank from above (bypassing that nasty frontal armor). Presto, no more tank. Obviously, there's issues with this idea--who has the authority to call down one of the UAVs? How many does he get? What if Jim Numbnuts points it at his own troops? Even so, I think it'd be useful, especially since you could load up the UAVs with whatever kind of weapons the conflict needed--anti-personnel explosives, bomblets, and so on. Might be really handy in places where it's difficult to emplace artillery or in places where artillery can't reach due to obstructions. Same for places where human-piloted planes couldn't go due to weather, massive AAA, and so on, freeing up these men for other airstrikes. --- That said, back to the problem at hand. I'm in tenuous agreement with Gambit's last statement. It seems to me that looking at this problem as a distributed computing problem or through the lens of a network cabling solution could hamper ideas. One thing that came to mind is the following: if you're going to have these UAVs communicating with each other over radio, how much does that detract from their stealth capabilities, if any? I imagine enemy ELINT guys seeing this mini-cloud of weak transmissions headed their way on whatever instruments they use. Now, as to your formation-flying stuff--there's several programmers out there that have gotten computer AI's to 'flock' in-flight, much in the same manner that birds do so now by instinct. That kind of code would be useful. You may even be able to automate the process too, without tying up any radio channels. Try this on for size: The UAVs are programmed beforehand with a list of possible formations they could assume. (Single file, delta, stacked, and what-have-you.) This data would include proper distances and so on. Then you outfit each one of the UAVs with a beacon or a sensor of some kind. While in flight, a formation is determined (by ground control of the UAVs themselves) and they then monitor each others beacons or their own sensor input to maintain it, totally separate from whatever else they may be doing. Problems I see with this is the following: what to use? If a beacon of some kind, like an IFF signal, how do you make it stealthy enough so it's non-detectable, yet able to be seen by the UAVs? If a sensor (radar and perhaps ultrasound or infrared) would it be better to use the UAVs existing sensor suite or mount a separate one with a dedicated processor? If in the case of ultrasound, would the airspeed make it useless? Must think on this some more.

XMEN Ashaman DTM · Post by **XMEN Ashaman DTM** » Mon Apr 05, 2004 12:27 am

<blockquote>Quote:<hr>The UAV environment is completely different than the distributed problem-solving environment, in my view.<hr></blockquote> Hmm... see this is why I was thinking of this problem in these terms. I guess I'm trying to take the extremely parallelized system inherent to autonomous UAV formations and trying to figure out how to make it work over a network (say a LAN).

Got a question for a programmer or network admin/engineer...

Got a question for a programmer or network admin/engineer...

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee

Re: Got a question for a programmer or network admin/enginee