Oct 26, 2010

Data is out of sync

I have found out that, in Slidex, the printed data cannot be queried at the time when it is sending data to the printer.

Because the printing task is on a different thread. This means that some other threads might already change the data in the database.

It makes the printed data wrong.


Here is the fix:

We need to make copies of all data needed by a printing task. And that's it.

----------------------------------------------------------------------------------

This also happens with all the commanders. We need to make copies of data just for sending.

Oct 16, 2010

Strange behavior of NetworkStream.WriteByte(byte b)

It turns out if you do WriteByte() too frequently, it crashes the network of the computer. The problem might be XP does not handle buffer very well or it blocks too many packets being sent.

We solve the problem by using BufferedStream and do not flush() unless we need to. And that's it. It solves all the problems.

System.Security.Cryptography.CryptographicException: Object already exists.

It occurs when I try to initialize an RSACryptoServiceProvider instance.

This happens because the program is run with different users; One with normal user and another with startup user.

When the key is created, its permission is only granted to the creator.

Therefore, you need to change the permission of the key in order that it can be used by everyone.

Here is the code:


CspParameters cspParams;
cspParams = new CspParameters(PROVIDER_RSA_FULL);
cspParams.KeyContainerName = CONTAINER_NAME;
cspParams.Flags = CspProviderFlags.UseMachineKeyStore;
cspParams.ProviderName = "Microsoft Strong Cryptographic Provider";

CryptoKeyAccessRule rule = new CryptoKeyAccessRule("everyone", CryptoKeyRights.FullControl, AccessControlType.Allow);

cspParams.CryptoKeySecurity = new CryptoKeySecurity();
cspParams.CryptoKeySecurity.SetAccessRule(rule);



OR another solution is to not use UseMachineKeyStore Option.

Never flush() the stream if you don't need to.

Today I found a problem that flush() the stream too often can cause freezing to the ethernet card. The computer won't have access to any network anymore. It happens to only Windows XP though. It seems like Windows 7 fixes this problem with another layer of flushing.

Here is some flushing practice I have found on the internet:

The only time you need to call flush() is if ALL of the following are true:

- You've written some of the data

AND

- You're not totally done. There's still more data to write.

AND

- You want to make sure the data you've already written reaches its destination ASAP. It is not acceptable if there's still some sitting in the buffer that goes with the next write that will come later.

Otherwise, there's no need to call it. If you're already done writing, you'll call close(), and that will call flush() anyway. If you're writing all of the data in chunks one right after the other, and not stopping to do other processing between chunks, then you'll be writing as fast as possible and calling close() right away anyway, so, again, no benefit to calling flush.

So with this code, there's no reason to call flush() explicitly. Note, however, that you should always close streams in a finally block, so that they get closed even if there's an exception.

-------------------------------------------------------------------------------

There will be no buffer overflow because OS will handle that itself. A little bit of lesson here is not to try to handle what OS has already handled; It might cause some strange problems...