'Cause they are really different sockets. Diferent ip/port combination, different connections. The legacy application that answers to these sockets on the other side works like this. And I believe this is better , 'cause this application can receive many requests at the same time. Otherwise, it would block the connection until it gets the answer. I use the OnDataArrival event to receive the data, that is, assyncronous to the sending function. Regards, Leonardo Muzzi

"All catch/finally blocks are honored, and never aborted mid-stream..." ...but code which relies upon certain instructions not throwing exceptions may be broken if they do so. See the article's comments about 'using'. By the sound of it, using abort exceptions doesn't sound very safe. Using interrupt would seem much safer, provided that any time-consuming loops that don't engage in managed sleeping test a flag for whether they should exit. The "using" directive is nice in many ways--it's too bad that there are so many wrinkles when using it. If a constructor could take a byRef parameter indicating where the new object should be stored, and if it could store the newly-created object there before leaving its outermost try/catch block, one could emulate a 'Using' in such a way as to avoid leaving dangling resources in case of an abort. Unfortunately, I don't know any way to make anything remotely like that work as smoothly as "using". Too bad iDisposable seems to have been an afterthought (unlike Finalize, which is common to all objects). If Finalize took a parameter which indicated whether to perform a garbage-collect cleanup, explicit disposal, or failed-object-creation cleanup (objects that wanted to receive a garbage-collect cleanup would have to register) that would have simplified a lot of things.

Thanks for the advice, that was the problem. In fact, the real problem is that PaddingMode.PKCS7 doesn't work properly. Using this mode, in the roundtrip, I always get the error "PKCS7 padding is invalid and cannot be removed.". That's why I tried to do the padding myself, but it is not possible to do it in the string, because of the special characters that takes more than one byte. So, the solution was: I implemented the PKCS7 myself, in the byte array, right before the encryption, using PaddingMode.None for the RijndaelManaged. That worked fine. However, in the decryption, it was not necessary to implement it, the PaddingMode.PKCS7 worked correctly. Thanks to this article, "Notes On Padding" section: http://www.codeproject.com/KB/security/Cryptor.aspx[^]