The wave would be directed. It's kind of like Fourier analysis( synthesis ) where you add a series of sinusoids to produce different shapes. In this case, you would want all sinusoids to be at their peek at a single point ( just in front of the ocean shore ). Because the amplitudes of the sinusoids would be decaying over distance, they would only ever be devistating at that one point ( a non-decaying wave would produce periodic peeks all around the world ). In addition to this 1'st order mathematical analysis, you have to consider that the explosions will be directed ( most likely in a line ), thus the compounding effect will only be towards the target. It will not, therefore, produce a radially expanding wave ( as in a point disturbance like a single explosion ). In fact, you should even be able to safely station your ship or sub not too far behind the starting point of the wave.
This discussion has been pretty informative on how to build a high BW server, but I'm not completely convinced that this brute forced method is the best solution for what is essentially a TV broadcast. ( but with interactive designs )
Why not use Multi-cast video streaming with channels that repeat every 10 minutes or so ( kind of like pay per view with 4 channels that break into half hour blocks ). This way you have a fixed number of connections that scales with the number of titles, not the number of users.
Thus you have clients request a title, and on the next 10 minute block, all users that have requested that title ( or more specifically a 10 minute section of a title ) will be multi-casted together. The clients can be set up with varying sized caches ( based on their free disk space ), so if they need to pause or replay a section, BW doesn't have to be eaten ( and while they are pausing, they are still downloading future portions of the movie along with anyone else. ) I'm not sure how well a mainstream player such as RealPlayer, media player or quicktime would work ( not familiar enough with them ), but if this is an educational project, a custom built system shouldn't be too hard to tackle. ( though a mainstream ( no pun intended ) product would be easier to maintain ).
There are many variations that could be played with. The big problem that I see with brute force is that if you have 5 guys in a hall downloading the same 1.2Meg/s file, the BW is going to be too saturated for the rest of the hall downloading porn ( in jest ). Perhaps there is a switching configuration which would allow this media to be completely independant; I'm not experienced enough in that area, but it definately doesn't work on a generic shared network.
The cool thing about this sort of system is that you can easily divide an conquer. If your 150 connects are all independant titles, you can cluster them ( one, two or three titles per server ). Here you could easily take advantage of cheap, stable Linux and x86 and build 50 or so $3-400 boxes for $15,000 - $20,000.
You could stick with simple UDMA IDE drives ( $150 a piece ). You could even load directly off a DVD player ( $90 a piece ). Down time would be minimized and localized. ( tape restore to a new drive if one fails, and you only lose the title(s) local to that disk. Or not at all if using DVD ).
Titles that are more popular could have enough RAM installed to cache most of the system ( aside from the mentioned 1-2G limit on Linux ).
Because broadcasts are in blocks, they can be loaded as a continguous chunks ( 1.2Mbps * 600s = 72MBytes per feed ), and can easily be cached in memory. This removes the need for _any_ high performance disk hardware ( including SCSI ), since it would only take 9 - 36 seconds to load a chunk into memory.
A 2 hour video clip would only have 12 segments, and thus your 150 titles would require a maximum of 1,508 channels. If properly switched and distributed, each machine would only need 12 - 36 channels or 14.4Mbps - 43.2Mbps, which could be handled by a 100BaseT NIC rather comfortably. Thus all generic parts seem to suffice.
The only penalty I can see is that a user would have to wait a maximum of 9.9 minutes before their feed begins. I think this is a fair trade-off, given it's one step closer to interactive TV.
Slashdot Mirror
The wave would be directed. It's kind of like Fourier analysis( synthesis ) where you add a series of sinusoids to produce different shapes. In this case, you would want all sinusoids to be at their peek at a single point ( just in front of the ocean shore ). Because the amplitudes of the sinusoids would be decaying over distance, they would only ever be devistating at that one point ( a non-decaying wave would produce periodic peeks all around the world ). In addition to this 1'st order mathematical analysis, you have to consider that the explosions will be directed ( most likely in a line ), thus the compounding effect will only be towards the target. It will not, therefore, produce a radially expanding wave ( as in a point disturbance like a single explosion ). In fact, you should even be able to safely station your ship or sub not too far behind the starting point of the wave.
This discussion has been pretty informative on how to build a high BW server, but I'm not completely convinced that this brute forced method is the best solution for what is essentially a TV broadcast. ( but with interactive designs )
Why not use Multi-cast video streaming with channels that repeat every 10 minutes or so ( kind of like pay per view with 4 channels that break into half hour blocks ). This way you have a fixed number of connections that scales with the number of titles, not the number of users.
Thus you have clients request a title, and on the next 10 minute block, all users that have requested that title ( or more specifically a 10 minute section of a title ) will be multi-casted together. The clients can be set up with varying sized caches ( based on their free disk space ), so if they need to pause or replay a section, BW doesn't have to be eaten ( and while they are pausing, they are still downloading future portions of the movie along with anyone else. ) I'm not sure how well a mainstream player such as RealPlayer, media player or quicktime would work ( not familiar enough with them ), but if this is an educational project, a custom built system shouldn't be too hard to tackle. ( though a mainstream ( no pun intended ) product would be easier to maintain ).
There are many variations that could be played with. The big problem that I see with brute force is that if you have 5 guys in a hall downloading the same 1.2Meg/s file, the BW is going to be too saturated for the rest of the hall downloading porn ( in jest ). Perhaps there is a switching configuration which would allow this media to be completely independant; I'm not experienced enough in that area, but it definately doesn't work on a generic shared network.
The cool thing about this sort of system is that you can easily divide an conquer. If your 150 connects are all independant titles, you can cluster them ( one, two or three titles per server ). Here you could easily take advantage of cheap, stable Linux and x86 and build 50 or so $3-400 boxes for $15,000 - $20,000.
You could stick with simple UDMA IDE drives ( $150 a piece ). You could even load directly off a DVD player ( $90 a piece ). Down time would be minimized and localized. ( tape restore to a new drive if one fails, and you only lose the title(s) local to that disk. Or not at all if using DVD ).
Titles that are more popular could have enough RAM installed to cache most of the system ( aside from the mentioned 1-2G limit on Linux ).
Because broadcasts are in blocks, they can be loaded as a continguous chunks ( 1.2Mbps * 600s = 72MBytes per feed ), and can easily be cached in memory. This removes the need for _any_ high performance disk hardware ( including SCSI ), since it would only take 9 - 36 seconds to load a chunk into memory.
A 2 hour video clip would only have 12 segments, and thus your 150 titles would require a maximum of 1,508 channels. If properly switched and distributed, each machine would only need 12 - 36 channels or 14.4Mbps - 43.2Mbps, which could be handled by a 100BaseT NIC rather comfortably. Thus all generic parts seem to suffice.
The only penalty I can see is that a user would have to wait a maximum of 9.9 minutes before their feed begins. I think this is a fair trade-off, given it's one step closer to interactive TV.