This is my reply to one old message here... > That SSL Lib problem hit me a few times, and I did not remember from > one episode to the next what "SSL is not implemented" means. It could > mean so many things! At which point it doesn't mean much at all. > Though at least in this situation we know it's an SSL problem. There > are times when you get the error message "Network subsystem is > unusable" for *exactly* the same error. [See below for an example.] > This is also an error condition that will likely hit every NEW user of > Synapse, and possibly a few of us "seasoned" users again... Choosing > another way of handling it will mean less support needed on the > mailing list, happier users, and possibly *more* users...
Error handling is complicated by SSL. Just because we have errors on different levels: Basic level is TBlockSocket.LastError. This level is pure socket level and you found here basic errors with socket communication. Second level is SSL. This protocol is technically application level protocol based on pure sockets. This level is transparent for Synapse users. Users using socket classes as usual, but internally is communication passed throung SSL/TLS engine what using TCP as transport level. All communication errors on the sockets are presented as TBlockSocket.LastError. But even on socket level is all OK, you have some logical error on SSL level. (like invalid keys, etc.) SSL level errors are presented by different property, TBlockSocket.SSL.LastError, because it is different error. Just because code simplicity and simple usage is needed, I map SSL errors to socket errors. This causing major paradigma: If TBlockSocket.lastError have value zero, then all is OK! For this I need to set 'fake' TBlockSocket.LastError non-zero value, if some error exosts on SSL level. I cannot create new error value, because Synapse running on various paltforms with varuious error code assigning. Hard to find one common safe value. So, I setting "Network subsystem is unusable" in this case. This error is not often used, and their text is close to real problem. Most situations can be solved by testing of zero value in TBlockSocket.lastError. If you need to know what exact error happen, then if you got "Network subsystem is unusable", see for TBlockSocket.SSL.LastError for additional error informations on SSL level. If no problem is here, then it is real "Network subsystem is unusable" error. I relly not know how to map errors form SSL level to socket level better. There are place for improvements of error handling if no SSL support is compiled, of course! > In ADDITION, I suggest using a technique we've used for a long time: > This error is part of a class of errors that are discovered at run > time, but which are uniquely PROGRAMMER (setup) ERRORS. We, not the > user, installer, etc., were the ones making the mistake, and this was > predictable from the original library code (as you indicated with your > ReturnError() method, called from nearly all the base class TCustomSSL > methods). In those situations, I call a function called, strangely > enough <g>, ProgrammerError! that does only one thing, throw an > exception RIGHT AT THE POINT OF THE PROBLEM: Raising of unconditional exception if program trying to use noncompiled SSL/TLS support sounds reasonable. But it is not 'programmer error'. It can be users error too. What about if you have program without SSL support, and user enters SSL based URL? Uncoditional exception can break logical flow of existing programs! Synapse now create error on SSL level "SSL is not implemented", what is IMHO right error here (even we can found better text of this error), and map error to socket level by way what I explain before. > When you run the program, you will immediately notice a different > problem, one that's causing me some difficulties at the moment. The > (F)LastError integer property is being cleared on the way back out the > call stack, so IT CAN'T BE USED TO INSPECT the reasons for any > failure. Yes, this must be fixed by me. It is cleaned by TCP socket closing code. I know! However you are not true if you say: > Let's trace through the important parts of what happens. To make it > easier, open the blcksock unit and place a breakpoint in the > ReturnError method, where TCustomSSL's FLastError is set to -1, and > FLastErrorDesc is set to "SSL is not implemented!" Running to that > point, and then single-stepping our way back out of the call stack we > quickly arrive at SSLDoConnect where the TTCPBlockSocket's FLastError > is immediately "translated" into the wrong (socket) error (10091) > WSASYSNOTREADY. Going into ExceptCheck then changes FLastErrorDesc to ... SSL error is not translated to socket level error. SSL level error stays in SSL.LastError. However problem with overriding of socket level error in TCP cleaning code exists, and must be fixed. > One way to handle the problem of reporting SSL errors, internal > programming configuration errors, and socket errors (among others) > might be to add another integer property that specifies the "class" > (or "kind") of error encountered. The FLastError value would then be > interpreted in terms of this ErrorKind value. [Example: when ErrorKind > was ekSocketError, the (F)LastError values would be the ones we see > today.] It is interesting idea, even I not know if I use it now yet. However it sounds like reasonable alternative to current system. > P.S. I can't help mentioning another "language" issue that's been > bothering me for a long time: On the main Synapse web page there's a > description line for the "Current stable release" that says "Final > release of Synapse." That phraseology may well give casual visitors > the impression that THAT'S the LAST one (if they don't see that 38b7 > is above...)! "Final" means the absolute, ultimate end... which is > obviously not the case... Right, thanks! BTW: I am thinking about totally new web pages now. :-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
