Virtually all of those 150 protocols are dce-rpc based protocols.
As such they are already described in interface description files and compiled into marshalling/unmarshalling code using standard idl-compilers. Microsofts one is called midl.exe.
It would take no time at all to just take these interface description (idl) files and publish them.
It would not take very long to at least provide specifications of those protocol interfaces. A few hours is how long it would take at most to provide interface specifications to all protocols except SMB and SMB2 themself. All other protocols (except SMB and SMB2) are machinegenerated using idl compilers (midl.exe) from interface specification files : idl-files.
That would be a good start and it wouldnt require mote than one engineer spending 1 hour collecting and providing these itnerface specifications.
Once they have done that, they can use the engineers to provide higher level documentation for the actual protocols, but providing the interface specifications would be a matter of an hour, tops.
An interface description is a file that describes the packet format, i.e. the packet syntax. Sort of like the.x files for onc-rpc you will find down in/usr/include/srvsvc but idl files are for dce-rpc instead.
Re:Standard protocol is needed!!
on
Firefox VoIP Client
·
· Score: 3, Informative
There are two standards for VoIP (SIP and H.323) and any application that implements them should interoperate just fine with any other implementation.
Any SIP VoIP application should interoperate just fine with any other SIP application. same goes for H.323.
Skype is special and uses a proprietary nonstandard protocol and as such wont interoperate with anything else.
It would be nice if skype were to be gradually phased out and replaced with proper H.323 or SIP based applications.
Re:support for the h.323 protocol, quite unlikely
on
Linux 2.6.17 Released
·
· Score: 1
I stand corrected and am very impressed with the fact they managed to implement this in so little code.
My doubts were based on having first hand experience implemented PER/H225/H245 myself and knowing how huge and complex they are. That they managed to squeeze even the smallest required subset of the problem space into a 20kb object module to just extrack the ipaddress/portnumbers is very very impressive.
As someone that knows PER/h225/h245 really well I say : very impressive!
Re:support for the h.323 protocol, quite unlikely
on
Linux 2.6.17 Released
·
· Score: 3, Interesting
Bloody hell!
They managed to squeeze both PER and also H225/235/245 into just 20kbyte of object code?!
(why implement h235? thats crypto and wouldnt work unless you know the keys?)
That is VERY impressive.
Re:support for the h.323 protocol, quite unlikely
on
Linux 2.6.17 Released
·
· Score: 1
"I read that as ip conntracking to allow videoconferencing devices that follow the h.323 standard to be natted."
Still pretty unlikely. The only thing that differs between say H.323 and SIP initiated voip or videoconferencing or the others is how the signalling works. After all signalling is done, the actual voice or video is just normal standard RTP traffic anyway.
H.323 differs from SIP in that the signalling is performed through two main protocols h.225 and h.245 which are both encoded using asn1 aligned-PER. This is a really compact encoding and it does require a massive amount of code in order to implement decoders for. I know because I have written aligned-PER decoders. We are talking about many thousands on lines of code just to unmarshall the packets.
SIP on the other hand is just implemented as additional methods for HTTP and is encoded in simple ascii text. A SIP decoder can be written in 100 lines or less and is trivial.
Why is signalling important? Signalling is where tou actually handshake end to end which ports to use for the RTP session. A h.323 connection tracking module for h.323 would therefore require unmarshalling of h.225 and h.245 something i think would be very very very unlikely to include inside the kernel.
For the other responder to my initial post. I have taken your offer into consideration but have decided to decline.
support for the h.323 protocol, quite unlikely
on
Linux 2.6.17 Released
·
· Score: 1, Interesting
1, there exists no protocol called h.323 There exists a h.323 standard that references protocols such as h.225 h.245 etc. but there is no h.323 protocol.
2, even more unlikely for h.323 support is that since all the important parts of h.323 such as h.225 and h.245 are all ASN.1 PER encoded. Are they going to add a decoder for aligned-PER inside the kernel? yeah likely.
Whatever thay have added it is not support for h.323. Maybe they have added support for RTP?
As you say, you have never even seen the tool, which is why you have no idea of what it does.
I use coverity and my experience is that it is incredibly useful and powerful.
There has never been any exploits.
There has been a number of dereference null pointer or forget to increase the loopcounter so end up in an infinite loop.
Very few stack or buffer overflows have been in ether^wireshark.
getting better or worse? Check out coverity which showed ethereal/wireshark having vastly fewer bugs per line of code than any other >1M loc project.
Including the *BSDs.
Nah, the lack of support RIP is a subtle message to network admins. Dont use RIP, it doesnt handle variable length netmasks so there will always be "surprises" when using RIP.
VoIP is different from most other traffic types in that it is hard realtime and needs real low latency. This means VoIP uses UDP
OpenSSL builds encrypted sessions over TCP. TCP is not designed to work well for the requirement space needed by VoIP. If fact, it just would not work well at all.
No that is not a good example of something that needs/benefits from better accuracy.
The problem is that code cutters today have zero understanding of what they do or theory and then they blame lack of precision for the "error" terms.
No matter how high you make precision there are lots of numberical calculations that just can not be done accurately without a proper education in computer science or numerical analysis.
Question 1: Using Gaussean elimination, I want to invert a Hilbert-matrix with 100 rows and 100 columns, how many bits of mantissa do I need in the float representation if I want the residual error to be less than 1%?
1, dont know. dont even know how to estimate ==> you should not write numerical software since you lack the tools and understanding required.
2, make them really big. ==> see above.
3, 128bits. ==> see above
4, could estimate it bit it is pointless since that algorithm is not numerically stable. ==> almost there
5, 4+the Gershgorin(spelling?) circles show that we have to do partial pivoing (english name?) to stabilize the calculations. ==> congratulations right answer.
I am in the unfortunate position to have to work with the 1-3 answer people. Todays cs degrees are just paper and dont even cover the most basic 101 skillsets. I bet they can hack together an example inventory database app in VB really quickly though.
The OP was wrong. The paper linked had nothing to do with precision at all but an old broken implementation.
This is exactly the problem. The people that shout the loudest for enhanced precision is the crowd that have no idea about numerical analysis or how floating point work and for those, enhancing the precision is not a solution, it might HIDE the real problem (people with no clue about numerical analysis writing numerical analysis code) but it will not help them at all.
I know that there are specific niche applications that may benefit from higher precision.
However, I belive that is very niche.
Most, virtually all, people asking for higher precision floats do so because they do not understand floating point and they misguidedly belive it will improve the accuracy in thair calculations. As my example it doesnt matter how many bits of precision you use, you just CAN not solve certain problems without understanding of floats and numerical analysis.
As for Gaussean-elimination in particular, it doesnt matter how many bits of precision you use, you just can not invert certain types of matrices using that algorithm, no matter how many bits you extend your floats to.
I belive you agree with that.
What benefit does increasing the precision of floats to 128bits bring?
64bits are more than enough for 99.9999% and the remaining cases can be handled in sw emulation.
You can still not solve (without massive growth of the error terms) an equation system described by a Hilbert-matrix using Gaussean-elimination no matter how many bits you make the mantissa.
Oh i forgot my contact details.
If I were wrong and you want to discuss "interesting" business opportunities my email address is
princess_ahkbara798@hotmail.com
and the opportunity is regarding a diplomatic consignment deposited by my late husband Presdent Fknomibara of Belgania (killed by enemy rebels) that is held in escrow in a bank in amsterdam.
" If you know what that means, I would like to offer you a cookie, because I sure as heck don't."
Easy
It means:
1, It sounds really good saying we will only release it when it is perfect and when it is the best game on any platform ever. Customers your satisfaction is our highest goal!
2, We will ship it as soon as it can display the intro scene properly and when it doesnt crash too often and when we have removed the most obious cheat exploits. If you want toplay it from start to end without it, buggung out well that is what the post-release patches are for.
3, Oh, it already so overhyped that we can release anything we want and people will bee too ashamed of hyping it to do anything else than continue praising it.
The previous releases in this gengre were both initially unplayable and pretty mediocre and were even hyped after they were released and people could actually try the games. Why different now? Unless they are stupid with their money they will minimize expenses and release again a mediocre game but sell massive numbers. If this is NOT the case, then please contact me since I have really interesting business opportunities for you.
Thats a waste of a perfectly good scroll of identify.
You identify glass by engraving or putting in a chest and kicking it. Save the scroll for the gems that are NOT glass.
Some years ago a large swedish company was fined for anti-competitive practises and price dumping on the italian market.
that is a big no-no and they were fined the standard 10% of the annual global revenue.
10% global annual revenue hurts big time if you are a multinational company.
many other european companies have been fined in the same way.
Virtually all of those 150 protocols are dce-rpc based protocols.
As such they are already described in interface description files and compiled into marshalling/unmarshalling code using standard idl-compilers. Microsofts one is called midl.exe.
It would take no time at all to just take these interface description (idl) files and publish them.
It would not take very long to at least provide specifications of those protocol interfaces. A few hours is how long it would take at most to provide interface specifications to all protocols except SMB and SMB2 themself. All other protocols (except SMB and SMB2) are machinegenerated using idl compilers (midl.exe) from interface specification files : idl-files.
.x files for onc-rpc you will find down in /usr/include/srvsvc but idl files are for dce-rpc instead.
That would be a good start and it wouldnt require mote than one engineer spending 1 hour collecting and providing these itnerface specifications.
Once they have done that, they can use the engineers to provide higher level documentation for the actual protocols, but providing the interface specifications would be a matter of an hour, tops.
An interface description is a file that describes the packet format, i.e. the packet syntax. Sort of like the
There are two standards for VoIP (SIP and H.323) and any application that implements them should interoperate just fine with any other implementation.
Any SIP VoIP application should interoperate just fine with any other SIP application. same goes for H.323.
Skype is special and uses a proprietary nonstandard protocol and as such wont interoperate with anything else.
It would be nice if skype were to be gradually phased out and replaced with proper H.323 or SIP based applications.
I stand corrected and am very impressed with the fact they managed to implement this in so little code.
My doubts were based on having first hand experience implemented PER/H225/H245 myself and knowing how huge and complex they are. That they managed to squeeze even the smallest required subset of the problem space into a 20kb object module to just extrack the ipaddress/portnumbers is very very impressive.
As someone that knows PER/h225/h245 really well I say : very impressive!
Bloody hell!
/ dissectors/packet-per.c )
is way larger than that, and that is just aligned PER decoding (ok with some unaligned PER additions recently) and that one itself is >>20kbyte. Adding 225/245 into the mix. Impossible!
They managed to squeeze both PER and also H225/235/245 into just 20kbyte of object code?!
(why implement h235? thats crypto and wouldnt work unless you know the keys?)
That is VERY impressive.
My PER decoder alone ( http://anonsvn.wireshark.org/wireshark/trunk/epan
I am very impressed. Very impressed.
"I read that as ip conntracking to allow videoconferencing devices that follow the h.323 standard to be natted."
Still pretty unlikely. The only thing that differs between say H.323 and SIP initiated voip or videoconferencing or the others is how the signalling works.
After all signalling is done, the actual voice or video is just normal standard RTP traffic anyway.
H.323 differs from SIP in that the signalling is performed through two main protocols h.225 and h.245 which are both encoded using asn1 aligned-PER. This is a really compact encoding and it does require a massive amount of code in order to implement decoders for. I know because I have written aligned-PER decoders. We are talking about many thousands on lines of code just to unmarshall the packets.
SIP on the other hand is just implemented as additional methods for HTTP and is encoded in simple ascii text. A SIP decoder can be written in 100 lines or less and is trivial.
Why is signalling important? Signalling is where tou actually handshake end to end which ports to use for the RTP session. A h.323 connection tracking module for h.323 would therefore require unmarshalling of h.225 and h.245 something i think would be very very very unlikely to include inside the kernel.
For the other responder to my initial post. I have taken your offer into consideration but have decided to decline.
1, there exists no protocol called h.323 There exists a h.323 standard that references protocols such as h.225 h.245 etc. but there is no h.323 protocol.
2, even more unlikely for h.323 support is that since all the important parts of h.323 such as h.225 and h.245 are all ASN.1 PER encoded.
Are they going to add a decoder for aligned-PER inside the kernel? yeah likely.
Whatever thay have added it is not support for h.323. Maybe they have added support for RTP?
As you say, you have never even seen the tool, which is why you have no idea of what it does. I use coverity and my experience is that it is incredibly useful and powerful.
you are seriously mistaken. coverity is a most impressive tool.
There has never been any exploits.
There has been a number of dereference null pointer or forget to increase the loopcounter so end up in an infinite loop.
Very few stack or buffer overflows have been in ether^wireshark.
getting better or worse? Check out coverity which showed ethereal/wireshark having vastly fewer bugs per line of code than any other >1M loc project.
Including the *BSDs.
Nah, the lack of support RIP is a subtle message to network admins. Dont use RIP, it doesnt handle variable length netmasks so there will always be "surprises" when using RIP.
Your God probably also said something silly like "thou may not eat crisp bacon" as well.
I tell you, time to change God. Let me recommend Thor, a proper God that knows the value of beer and a few pounds of roasted pork.
"Remember it's been shown by many studies that humans are vegetarian primates, so eating meat is just going against nature"
BS. It may be against nature but being a vegetarian is being against God, you pagan.
If God did not want us to eat animals he would, in his omnipotence, not have hade animals taste so good.
QED
VoIP is different from most other traffic types in that it is hard realtime and needs real low latency. This means VoIP uses UDP
OpenSSL builds encrypted sessions over TCP. TCP is not designed to work well for the requirement space needed by VoIP.
If fact, it just would not work well at all.
Your idea is intriguing.
Please give me 1 week advance notice of you implementing this plan so I can reposition my stock portfolio to naked puts in MS stock.
What an excellent idea.
You gonna help them come up with a good message to explain to the market and shareholders why they choose to reduce revenues by 30% as well?
No that is not a good example of something that needs/benefits from better accuracy.
The problem is that code cutters today have zero understanding of what they do or theory and then they blame lack of precision for the "error" terms.
No matter how high you make precision there are lots of numberical calculations that just can not be done accurately without a proper education in computer science or numerical analysis.
Question 1: Using Gaussean elimination, I want to invert a Hilbert-matrix with 100 rows and 100 columns, how many bits of mantissa do I need in the float representation if I want the residual error to be less than 1%?
1, dont know. dont even know how to estimate ==> you should not write numerical software since you lack the tools and understanding required.
2, make them really big. ==> see above. 3, 128bits. ==> see above 4, could estimate it bit it is pointless since that algorithm is not numerically stable. ==> almost there 5, 4+the Gershgorin(spelling?) circles show that we have to do partial pivoing (english name?) to stabilize the calculations. ==> congratulations right answer.
I am in the unfortunate position to have to work with the 1-3 answer people. Todays cs degrees are just paper and dont even cover the most basic 101 skillsets. I bet they can hack together an example inventory database app in VB really quickly though.
The OP was wrong. The paper linked had nothing to do with precision at all but an old broken implementation.
This is exactly the problem. The people that shout the loudest for enhanced precision is the crowd that have no idea about numerical analysis or how floating point work and for those, enhancing the precision is not a solution, it might HIDE the real problem (people with no clue about numerical analysis writing numerical analysis code) but it will not help them at all.
I know that there are specific niche applications that may benefit from higher precision.
However, I belive that is very niche.
Most, virtually all, people asking for higher precision floats do so because they do not understand floating point and they misguidedly belive it will improve the accuracy in thair calculations. As my example it doesnt matter how many bits of precision you use, you just CAN not solve certain problems without understanding of floats and numerical analysis.
As for Gaussean-elimination in particular, it doesnt matter how many bits of precision you use, you just can not invert certain types of matrices using that algorithm, no matter how many bits you extend your floats to. I belive you agree with that.
What benefit does increasing the precision of floats to 128bits bring?
64bits are more than enough for 99.9999% and the remaining cases can be handled in sw emulation.
You can still not solve (without massive growth of the error terms) an equation system described by a Hilbert-matrix using Gaussean-elimination no matter how many bits you make the mantissa.
Oh i forgot my contact details. If I were wrong and you want to discuss "interesting" business opportunities my email address is
princess_ahkbara798@hotmail.com
and the opportunity is regarding a diplomatic consignment deposited by my late husband Presdent Fknomibara of Belgania (killed by enemy rebels) that is held in escrow in a bank in amsterdam.
" If you know what that means, I would like to offer you a cookie, because I sure as heck don't."
:
Easy
It means
1, It sounds really good saying we will only release it when it is perfect and when it is the best game on any platform ever. Customers your satisfaction is our highest goal!
2, We will ship it as soon as it can display the intro scene properly and when it doesnt crash too often and when we have removed the most obious cheat exploits. If you want toplay it from start to end without it, buggung out well that is what the post-release patches are for.
3, Oh, it already so overhyped that we can release anything we want and people will bee too ashamed of hyping it to do anything else than continue praising it.
The previous releases in this gengre were both initially unplayable and pretty mediocre and were even hyped after they were released and people could actually try the games. Why different now? Unless they are stupid with their money they will minimize expenses and release again a mediocre game but sell massive numbers. If this is NOT the case, then please contact me since I have really interesting business opportunities for you.
None of them. They are businessmen/engineers that got lucky and never did any research that drove the fields forward.
Don Knuth is a real hero. As is Dijkstrah