views:

86

answers:

2

Hi, i need a pointer i the right direction. I have been looking around and cant seem to find any design pattern (GoF) that will point me in the right direction.

I am developing a small digital signage application prototype, where there is a simple server and an amount of player applications (displaying an image/video) connected to this server. My requirements are to be able to connect 100 players to a single server, and distribute 50Mb data to each.

I plan on making small hubs (software hubs) in between the server and the players collecting the players (around 25 in each?) in hubs and having the hubs get and distribute the 50Mb data (divide and conquer, right?). The 50Mb is only for the prototype, i reckon that in real life displaying videos will be more around 300Mb to each. The reason for these hubs is that i would avoid having 100 players request 50Mb at the same time, instead only 4 (with 25 players each) hubs will request and redistribute.

When using Hubs i will need to be able to move the players around between the hubs, that is remove a player from one hub and attach it to another hub. (one of my thoughts are that all players attached to the same hub must share content, so the hub will avoid having to download 25 different movies)

Please, does anyone know how this is done in real life? Could you please comment on my concepts and/or point me in the right direction for at pattern/book that would help me solve this issue.

+7  A: 

Don't "choose" the design pattern before you design. Design first, and then compare with the patterns.

Your design need not always adhere to the patterns. But, make sure your design doesn't adhere to anti-patterns.

pavanlimo
+1 - I agree: you need to do some thinking before picking a pattern; the solution (pattenr) should always fit the problem - not the other way around.
Adrian K
+5  A: 

You need to take a step back from this. At the minute, you're trying to concentrate on the minutiae of your software architecture, without having considered (or at least mentioned) some important requirements.

It looks like you're really just trying to stream video. So:

  • Can you use an off the shelf video streaming product? This may be cheaper than building your own.

If not:

  • Will a broadcast model work for you, or does it have to be on demand? That is, let's say Client 1 requests Video A. If, a few minutes later, Client 2 also wants Video A, is it OK if Client 2 becomes another viewer of the same stream that Client 1 is receiving?

  • Will this be delivered over the internet, or on a private network over which you have control?

If you're using a private network and a broadcast model will work, you may be able to use UDP Multicast, which can offer significant bandwidth reduction over a pure on-demand solution.

So before you start deciding on your software architecture, you need to consider your hardware constraints and how they impact on the choices available to you.

Getting back to your proposed solution, I don't think it will scale very reliably. If one particular piece of content is very popular, then one of your hubs will be grossly overloaded, while others are idle. You may want to look into a more conventional load balancing technique which will allow you to scale out by simply adding more servers.

Winston Smith
The players have a schedule e.g. [video1], [image1], [image2], [video2], etc. this schedule, when expired it restarts the cycle, also one channel may show it from 10-11 AM, whereas another channel shows it from 10:30-11:30 AM. This means that broadcasting is not an option. Furthermore its a requirement, that each player (screen+computer/labtop) can be "taken offline". It is also a requirement that some of them work over http, so they can be located in a small shop window.
H4mm3rHead
Channels with a schedule... that sounds *exactly* like broadcast to me. Will multiple clients subscribe to a channel, or by *channel* do you really mean *client*? Anyway, if it's over the internet it's a moot point, because UDP multicast won't work, unfortunately.
Winston Smith
Sorry for my bad description, by channel i mean _client_. That is, the client that shows the content on a monitor. (i also call it a "player" in my original post. I appologize for my bad description.
H4mm3rHead