System architecture opinions sought

[AtW]

Using UDP rather than TCP in this case might make sense.

[TheRefactornator]

Using UDP rather than TCP in this case might make sense.

I did consider this as an option but as I understand it, UDP does not transport well over the internet because UDP packets are likely to be dropped by routers along the path. The network topology in this application must use the internet because the data gatherers are at geographically worldwide remote locations relative to the core server's location. I'll be happily corrected if I'm wrong about UDP however.

[AtW]

I did consider this as an option but as I understand it, UDP does not transport well over the internet because UDP packets are likely to be dropped by routers along the path.

UDP is used by all popular online games.

It is indeed not reliable protocol but you can easily solve this by adding counters and confirmations via UDP too.

UDP is ideal for small packets and cases when server needs to process lots of those packets.

Are you going to run this on LAN? If not you need to think about security for the data you send over public networks.

[TheRefactornator]

UDP is used by all popular online games.

It is indeed not reliable protocol but you can easily solve this by adding counters and confirmations via UDP too.

UDP is ideal for small packets and cases when server needs to process lots of those packets.

Are you going to run this on LAN? If not you need to think about security for the data you send over public networks.

I stand corrected. If I understand you correctly when you mention counters and confirmations, what you are describing here is a application level request/response protocol built on top of UDP that manages network retries to guarrantee delivery. Is that what you were thinking?

This will not run on the LAN so I've already considered encryption, but the sensitivity of the data will need to be confirmed by the vendor so I'm not sure if encryption is required yet.

[Churchill]

Realtime means that the time taken is quantifiable, not that it's fast.

Stick to noddy .NET "apps".

[CheeseSlice]

Any thoughts on load balancing hardware? I'm aware of the Barracuda 640 that is able to handle 2000tps and redundant configuration for high availability http://www.barracudanetworks.com/ns/...cer_models.php but I would be interested to learn about other possible options.

Not used one of these, but have used Brocade ServerIrons before (was Foundry before Brocade purchased them).
These are robust pieces of kit and used by the likes of telcos.
They'll do lots of different LB algorithms, round-robin, least loaded, sticky, non-sticky, etc, etc.
Depends what your requirements are and how much you're willing to spend.

I wouldn't touch Windows NLB with a barge pole if this is for a highly-available production service. App health awareness is non-existent. I've seen NLB systems loadbalancing requests quite happily to systems throwing .NET server errors. There are workarounds, but not simple. With the hardware option you can at least put some intelligence in there to spot this.

Could talk for hours about this subject, but I charge for that

[DimPrawn]

Realtime means that the time taken is quantifiable, not that it's fast.

Says who?

By that definition, Royal Mail 1st Class is realtime.

[BrilloPad]

Says who?

By that definition, Royal Mail 1st Class is realtime.

Is it quantifiable? It is supposed to take a day but can be 3 weeks in out part of LOndon.

[DimPrawn]

I wouldn't touch Windows NLB with a barge pole if this is for a highly-available production service. App health awareness is non-existent. I've seen NLB systems loadbalancing requests quite happily to systems throwing .NET server errors. There are workarounds, but not simple. With the hardware option you can at least put some intelligence in there to spot this.

Could talk for hours about this subject, but I charge for that

http://blogs.msdn.com/clustering/arc...4/8648702.aspx

HTH

[minestrone]

I don't that a multithreaded garbage collected environment could be classed as real-time.