Last time I looked seriously at SCTP (18 months ago), it had two "problems" with multi-homing and failover.
1) It only sends traffic over the current primary connection. Because the standby connection(s) are idle, it cannot detect failure on them until it needs to use them. On IP networks, failure takes a long time to detect. If the primary connection fails, it could switch to another failed (but not detected as failed) connection when there is a (better) working alternative.
2) It does not load-share. If there are three diverse routes, it makes sense to share the load over all three. This requires some metrics: Two broadband routes would loadshare, but in a broadband and ISDN backup case, the sharing would need to be uneven, or not at all (i.e. main+standby configuration).
Interestingly, providing 2 would solve 1.
Of course, these are problems introduced by the ability of SCTP to multi-home, it is not a regression on TCP (or UDP).
> Plus, he argues passionately for paying programmers well & giving them exciting projects, but in at least two cases he hired interns to start his company's most interesting apps.
That is because Joel has fallen into the legacy vs new trap. Legacy code is difficult to maintain and only your best and most experienced programmers can work on it without either braking it, making it worse, or doing it very very slow. In comparison, writing new code _seems_ relativily easy (can you hear the alarm bells?).
So if you have to put your best programmers on the legacy code, everyone else gets to write the new code... badly (but you don't realise this until maintanance time). The new code becomes legacy code, which requires your best programmers, which leaves the rest for the new new code. And the cycle continues.
There is no easy answer, pair programming helps, but requires more staff. Not many managers understand the "pay a bit more now, collect the big reward later" way this works. Good experienced programmers are expensive, young inexperienced progammers are cheap if you only consider how much you pay them (and not how much you have to pay to sort out the mess later using your expensive experienced programmers).
It works for me - I make a living out of fixing bad legacy code. I don't get to work on the sexy new projects, the youngsters do, creating my future employment needs... and so the cycle continues...
It has been shown time and time again that data over mains cables leaks radiation big time. But still they try. Unless this is stopped, the interference to radio services will prevent them being used. They won't stop pushing it until it wipes out the 999/911/112 services, then it will be too late.
The international standard for emergency calls is 112. This is mandatory in GSM.
Up until GSM roaming, a phone was always fixed to a country, thus countries were free to define their own emergency number. In practice, most countries outside North America followed 112 or had a migration path to it.
When GSM roaming came in, phones could be used outside the country of origin so following the international standard became important.
All GSM countries either moved to 112 or ran it in parallel, for example, 999 is used in the UK in parallel to 112.
The North American code area (the 22 countries in the North America dialling plan) managed to avoid the problem because roaming was years behind the rest of the world and GSM was limited to a few cities (until recently).
As an aside, the GSM specification states that 112 must be handled as a priority, i.e if a cell is full, dialling 112 will disconnected someone else. This does not apply to alternatives numbers so there is no need for UK operators to treat 999 as a priority, although in practice they do.
Now that the US has joined the party, and VoIP joins GSM as a non-country-locked phone service, it will be necessary for the US to migrate to 112. As 911 is so ingrained in the culture (as is 999 in the UK) both 112 and 911 will probably run in parallel for a very long time.
So shouldn't the authorities/regulators be mandating 112 rather than, or as well as, 911 ?
There are two audiences to code.
1) Developers.
2) Compilers.
It may come as a surprise to some, but the compiler cannot read the comments.
If you write it in the code, both the developers and the compilers are working to the same source.
Anything in comments is invisible to the compiler - it will be ignored, always.
A really really simplified case:
/* Initialise all variables */ int i, j, k = 0;
Here it is easy to see that the comment is wrong. In more complex cases it often isn't. Until compilers are able to read comments - DON'T USE THEM.
I repeat - say it in the code - if you feel you have to add a comment then you are writing difficult-to-understand-code - rewrite it so it is understandable.
Of course it is important to document the code, and the best place for documentation in next to the code (which is very different to comments). The documentation should indicate the why (not the how - code does the how):
/* Use single character variables because this is just an example and they don't have any meaning */ int i = 0; int j = 0; int k = 0;
Slashdot Mirror
Last time I looked seriously at SCTP (18 months ago), it had two "problems" with multi-homing and failover.
1) It only sends traffic over the current primary connection. Because the standby connection(s) are idle, it cannot detect failure on them until it needs to use them. On IP networks, failure takes a long time to detect. If the primary connection fails, it could switch to another failed (but not detected as failed) connection when there is a (better) working alternative.
2) It does not load-share. If there are three diverse routes, it makes sense to share the load over all three. This requires some metrics: Two broadband routes would loadshare, but in a broadband and ISDN backup case, the sharing would need to be uneven, or not at all (i.e. main+standby configuration).
Interestingly, providing 2 would solve 1.
Of course, these are problems introduced by the ability of SCTP to multi-home, it is not a regression on TCP (or UDP).
But Finland isn't in Europe, it's in Scandinavia. ;)
Not symmetrical...
Like a party full of girls looking for husbands, and husbands looking for girls, the situation is not as symmetrical as it seems.
> Plus, he argues passionately for paying programmers well & giving them exciting projects, but in at least two cases he hired interns to start his company's most interesting apps.
... badly (but you don't realise this until maintanance time). The new code becomes legacy code, which requires your best programmers, which leaves the rest for the new new code. And the cycle continues.
That is because Joel has fallen into the legacy vs new trap.
Legacy code is difficult to maintain and only your best and most experienced programmers can work on it without either braking it, making it worse, or doing it very very slow. In comparison, writing new code _seems_ relativily easy (can you hear the alarm bells?).
So if you have to put your best programmers on the legacy code, everyone else gets to write the new code
There is no easy answer, pair programming helps, but requires more staff. Not many managers understand the "pay a bit more now, collect the big reward later" way this works. Good experienced programmers are expensive, young inexperienced progammers are cheap if you only consider how much you pay them (and not how much you have to pay to sort out the mess later using your expensive experienced programmers).
It works for me - I make a living out of fixing bad legacy code. I don't get to work on the sexy new projects, the youngsters do, creating my future employment needs... and so the cycle continues...
It has been shown time and time again that data over mains cables leaks radiation big time. But still they try. Unless this is stopped, the interference to radio services will prevent them being used. They won't stop pushing it until it wipes out the 999/911/112 services, then it will be too late.
The international standard for emergency calls is 112. This is mandatory in GSM.
Up until GSM roaming, a phone was always fixed to a country, thus countries were free to define their own emergency number. In practice, most countries outside North America followed 112 or had a migration path to it.
When GSM roaming came in, phones could be used outside the country of origin so following the international standard became important.
All GSM countries either moved to 112 or ran it in parallel, for example, 999 is used in the UK in parallel to 112.
The North American code area (the 22 countries in the North America dialling plan) managed to avoid the problem because roaming was years behind the rest of the world and GSM was limited to a few cities (until recently).
As an aside, the GSM specification states that 112 must be handled as a priority, i.e if a cell is full, dialling 112 will disconnected someone else. This does not apply to alternatives numbers so there is no need for UK operators to treat 999 as a priority, although in practice they do.
Now that the US has joined the party, and VoIP joins GSM as a non-country-locked phone service, it will be necessary for the US to migrate to 112. As 911 is so ingrained in the culture (as is 999 in the UK) both 112 and 911 will probably run in parallel for a very long time.
So shouldn't the authorities/regulators be mandating 112 rather than, or as well as, 911 ?