Re: SERIAL NUMBER PROBLEM *AGAIN*!!!
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 21279
interpreted = N
texte = If anyone feels uncomfortable with the SN issue - watch the little lights on your hub when your server launches. Whatever is going on, it certainly is damn efficient - which stands to reason, in light of how well the rest of the product is designed.The folks at PCS have found a way of validating SNs without having to 'phone home' or depend on another server for validation. It does not have to pass SNs back and forth; PCS probably wouldn't have done something arbitrarily moronic like broadcasting unencrypted SNs, nor does it cache SNs anywhere but in your prefs.It seems logical to me - and I am only operating on pure hunch - that the package broadcasts a checksum based on SN, and leaves it parked in the TCP stack. Any other copy will do the same. If two copies with the same checksum find each other, one returns to demo mode.When WebCat quits, it clears the checksum info from the stack. A server crash will leave that info stranded in the TCP stack. When the WebCat copy on that very same machine is re-launched, it sees the stranded data and assumes that it is there because of another copy running nearby or even on the same machine, and it reverts to demo mode.Just thinking about this a little bit, I wonder what sort of magic it would take to make sure the stack info is cleaned even after a bomb. Would you run a separate process for just this? Would you keep setting and clearing the data in hopes that the crash occurs while the data is cleared? It's a lot of work for only one purpose - to be able to restart the server after a crash, even though the computer has not been restarted.That's nuts. The people who are doing the most bitching about this are probably the same ones running the server on the same machine with their browser and editing software, so rebooting takes too long. Many of the emails are worded to make it sound as if being unable to relaunch software on an unstable machine somehow does a disservice to customers. PCS would do well to preserve this as a feature since it forces a re-launch and prevents unstable operation from inaccurately tarnishing the reputation of the product.As for me, I paid a bunch for the software, so I want the SN scheme to make piracy a damn pain in the ass. Rebooting the server for me is very rare because a properly configured server, on which actual customers actually rely, should be stripped of everything that can possibly be removed, and carefully tuned. If a server does go down, I not only assume that I'm not going to just re-launch, but I'm going to divert all traffic to a backup server, tear the unit that crashed apart and scour the thing to find out how it happened.When did we WebCat users start getting irrationally paranoid? The last thing we need to do is generate false rumors about the product and make marketing to our customers that much tougher. Maybe we all need a vacation at Ken's place! I'll bring the badmitton.Now as for this goofy thread - you get the ankles and I'll get the wrists,Pat McCormick----- Original Message ----- From: Kenneth Grome
To: Sent: Tuesday, November 24, 1998 5:49 PM Subject: Re: SERIAL NUMBER PROBLEM *AGAIN*!!! >>So webcat is using bandwidth and cycles systematically culling millions >>of ip addresses for some secret handshake? I find that highly unlikely. >> If it is true, we're all in for a very strange ride. > >If that's what it's doing, what happens when it finds an IP address running webcat? Does it pass the SN back and forth between the two copies of webcat -- unencrypted -- to determine whether the SN is the same? Does it log the IP address of the other machine when it finds a matching SN? What other goodies does this new version of webcat offer? > >This sounds like something Microsoft would do ... > >Sincerely, >Ken Grome >808-737-6499 >WebDNA Solutions >mailto:ken@webdna.net >http://www.webdna.net > > > > > >
Associated Messages, from the most recent to the oldest:
If anyone feels uncomfortable with the SN issue - watch the little lights on your hub when your server launches. Whatever is going on, it certainly is damn efficient - which stands to reason, in light of how well the rest of the product is designed.The folks at PCS have found a way of validating SNs without having to 'phone home' or depend on another server for validation. It does not have to pass SNs back and forth; PCS probably wouldn't have done something arbitrarily moronic like broadcasting unencrypted SNs, nor does it cache SNs anywhere but in your prefs.It seems logical to me - and I am only operating on pure hunch - that the package broadcasts a checksum based on SN, and leaves it parked in the TCP stack. Any other copy will do the same. If two copies with the same checksum find each other, one returns to demo mode.When WebCat quits, it clears the checksum info from the stack. A server crash will leave that info stranded in the TCP stack. When the WebCat copy on that very same machine is re-launched, it sees the stranded data and assumes that it is there because of another copy running nearby or even on the same machine, and it reverts to demo mode.Just thinking about this a little bit, I wonder what sort of magic it would take to make sure the stack info is cleaned even after a bomb. Would you run a separate process for just this? Would you keep setting and clearing the data in hopes that the crash occurs while the data is cleared? It's a lot of work for only one purpose - to be able to restart the server after a crash, even though the computer has not been restarted.That's nuts. The people who are doing the most bitching about this are probably the same ones running the server on the same machine with their browser and editing software, so rebooting takes too long. Many of the emails are worded to make it sound as if being unable to relaunch software on an unstable machine somehow does a disservice to customers. PCS would do well to preserve this as a feature since it forces a re-launch and prevents unstable operation from inaccurately tarnishing the reputation of the product.As for me, I paid a bunch for the software, so I want the SN scheme to make piracy a damn pain in the ass. Rebooting the server for me is very rare because a properly configured server, on which actual customers actually rely, should be stripped of everything that can possibly be removed, and carefully tuned. If a server does go down, I not only assume that I'm not going to just re-launch, but I'm going to divert all traffic to a backup server, tear the unit that crashed apart and scour the thing to find out how it happened.When did we WebCat users start getting irrationally paranoid? The last thing we need to do is generate false rumors about the product and make marketing to our customers that much tougher. Maybe we all need a vacation at Ken's place! I'll bring the badmitton.Now as for this goofy thread - you get the ankles and I'll get the wrists,Pat McCormick----- Original Message ----- From: Kenneth Grome To: Sent: Tuesday, November 24, 1998 5:49 PM Subject: Re: SERIAL NUMBER PROBLEM *AGAIN*!!! >>So webcat is using bandwidth and cycles systematically culling millions >>of ip addresses for some secret handshake? I find that highly unlikely. >> If it is true, we're all in for a very strange ride. > >If that's what it's doing, what happens when it finds an IP address running webcat? Does it pass the SN back and forth between the two copies of webcat -- unencrypted -- to determine whether the SN is the same? Does it log the IP address of the other machine when it finds a matching SN? What other goodies does this new version of webcat offer? > >This sounds like something Microsoft would do ... > >Sincerely, >Ken Grome >808-737-6499 >WebDNA Solutions >mailto:ken@webdna.net >http://www.webdna.net > > > > > >
Pat McCormick
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
[taxrate] question (1997)
WebCat2b15MacPlugIn - [authenticate] not [protect] (1997)
[WebDNA] Seriously what is wrong here? (2011)
Users.db (1998)
For those of you not on the WebCatalog Beta... (1997)
Cancel Subscription (1996)
2nd WebCatalog2 Feature Request (1996)
Setting up shop (1997)
CR's (2003)
Possible Bug in 2.0b15.acgi (1997)
WebCatalog NT beta 18 now available (1997)
Unceremonious Unwanted Unsubscription (1999)
creating a 60 fields database (1997)
taxTotal, grandTotal (1997)
[WebDNA] EMailFolder/ (2016)
TCPConnect / Current Temperature (2004)
[WebDNA] High-profile WebDNA sites? (2008)
multiple selected Checkboxes (1998)
emailer error -108 (1997)
Problem in 4.0 store thankyou page (2000)