On Sun, 23 Mar 2003, Ben Schumacher wrote: >Yup. I think it unfortunate, as well, but I think its mostly >unavoidable. I just don't think there's a way to make sure all the SSL >context is available to the child process... at least nothing that is >readily apparent to me. I suppose it *might* be possible to duplicate >the structure that contains the context, and somehow pull this back >into the child process, but that could be really complicated. You >always could just fire a question off to the OpenSSL mailing list and >see what they have to say. My experience with those libraries is that >there is often a lot of poorly (un-?) documented features, so there may >be something there you can use.
Agreed - I have fired off the question on the OpenSSL list but haven't got any response after three days. >I do have a quick question for you. Is there a reason for your choice >of using std::strings instead of cstrings? My experience with these is >that they can often be terribly inefficient, both in memory usage and >cycles. You might not see this in BincIMAP since you have short lived >processes, but my company has a broad sweeping policy now to no longer >use them, because we discovered (through profiling) that a huge amount >of time was being spent in these routines. While they do help protect >you from buffer overruns, this often comes at an extremely high cost. Actually, I have heard the opposite. Rather than being less efficient, that C++ strings are quite optimial for several reasons. When appending two strings together, no data copying is done. When setting one string equal to another, the data are copied-on-write instead of strcpy/memcpy as we would have to do with cstrings. Functions returning a (const <class> &) can be quite optimal if the copy constructor uses this magic, and from what I read, it's a common implementation. Bundled with the dynamic size properties, I think C++ strings are quite a piece of art. But I am excited to hear of any benchmark results you may come up with. :-) Andy >On Sunday, March 23, 2003, at 01:23 PM, Andreas Aardal Hanssen wrote: >> Hi, Ben! >> >> On Fri, 21 Mar 2003, Ben Schumacher wrote: >>> Andreas- >>> When you saw child process, are you fork then exec'ng? Can you not >>> just >>> use a pipe to communicate back to the parent process and have it deal >>> with the socket code. I imagine it might be possible to fork and exec >>> and not use a pipe, but that's one possible solution. >>> I think the problem is that you need to get all SSL context >>> information >>> into the child process, which I'm not exactly certain how to do. >> >> I guess the fall-back solution is to pipe the data through the parent, >> although I was hoping that the child could issue a renegotiation and >> continue on native mode. >> >> I tried the pipe solution last week and it really looks ugly ;) but if >> that's the only way we know, then I'll go for it for now and see if I >> can >> make the piping code weaved into the design. >> >> Andy :-) >> >>> Glad to hear BincIMAP is progressing. >>> >>> Cheers, >>> >>> bs. >>> >>> On Friday, March 21, 2003, at 06:51 AM, Andreas Aardal Hanssen wrote: >>>> Hi, everyone. Some updates here. >>>> >>>> VERSION NUMBERING >>>> ----------------- >>>> >>>> The latest Binc release was 1.0.25-2. I'll be making some changes to >>>> version numbering now that I know better what changes are likely to >>>> happen >>>> are which aren't. :-) >>>> >>>> The scheme we'll use is this: >>>> >>>> <major>.<minor>.<bugfix>-<dist> >>>> >>>> Minor will alter between odd and even numbers. Odd numbers mark >>>> unstable >>>> development releases. Evens are stable. >>>> >>>> major : Complete redesign >>>> \_ Different programming language / concept >>>> \_ Major license/distribution changes >>>> >>>> minor : New major features / enhancements >>>> \_ Loadable C++ class modules support >>>> \_ Support for new authenticators >>>> \_ Privilege seperation, etc.. >>>> >>>> bugfix : Minor new features and primarily bugfixes >>>> >>>> dist : Changes to the way Binc is distributed (spec file changes, >>>> documentation updates, etc) >>>> >>>> MILESTONE >>>> --------- >>>> >>>> The 1.0.26 release is turning out to be such a great mile stone that >>>> I >>>> will be releasing it as 1.1.0 and not 1.0.26. So 1.0 will be left as >>>> a >>>> "stable" branch and we will continue development on 1.1 (unstable), >>>> only >>>> fixing bugs on the 1.0 tree. >>>> >>>> When we are confident that 1.1 is ready for production, the project >>>> will >>>> move from beta to production stage 1.2. Core development work will >>>> then >>>> continue on 1.3, and so on. >>>> >>>> NEW SITE >>>> -------- >>>> >>>> The domain bincimap.org has been registered and will soon take over >>>> for >>>> bincimap.andreas.hanssen.name serving the Binc IMAP website at a new >>>> stable location. The .name domain will still point to the server >>>> currently >>>> hosting the site (aka infeline,org), serving as our first mirror. >>>> Anyone >>>> interested in mirroring the site I encourage to contact me (bad >>>> english!!) >>>> ;) >>>> >>>> NEXT RELEASE >>>> ------------ >>>> >>>> Ok, leaking some stuff about the 1.1.0 release: >>>> >>>> - Will support privilege seperation >>>> - checkpassword invoked daemon >>>> - Loadable module support >>>> - Initial contributions: loadable modules that add support for >>>> several extensions like IDLE, ID, SORT. These contributions >>>> will serve as examples on how easy it is to add extensions as a >>>> completely seperate task/project while leaving the Binc IMAP >>>> core development untouched. >>>> >>>> The 1.1.0 release will be out next week. If anyone can help me with >>>> figuring out how a child process can continue SSL communication after >>>> the >>>> parent did the SSL_accept, then 1.1.0 will probably be out sooner >>>> rather >>>> than later. >>>> >>>> Good weekend everyone! >>>> >>>> Andy :-) > > -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
