Well - SSL isn't on my priority list yet but it is in my road map. (All I did so far was find out that web browsers treated my server like the black plague and only ... get this... IE allowed me to get past the warnings! LOL)
So I'm very concerned about this issue, but I'm also aware the cert stuff is not exactly robust .. meaning we developers need to implement it well.. and it might be that when little errors pop up - the demo doesn't handle the errors gracefully. I don't know .. and I'm too strapped for time at this moment... but I will revisit this issue because... welll - it's in my path of things to do like you. It does sound like there is something deep in the weeds from what you have posted. I'm sorry I don't personally have much to add. One thing I did do... that allows my server to "get the benefit" of SSL for the time being (also has side effect of leveraging existing web infrastructures) is I made a CGI program that prepares a special payload that is basically a bundle of the request made to it.. then it hands it off to my server. My server recognizes this special format and parses out the payload and then ACTS like the request happened locally... (Like if you asked for SOMEFILE.TXT.... the CGI app wraps up that request and sends it in the special payload, when it arrives, my server sees the request WAS for SOMEFILE.TXT and sends it out..) The CGI "proxy" then relays the output out the normal stdout conduit CGI applications use... it's seamless - but not as "fast" as a direct solution obviously... but it does expand configuration possibilities A LOT. Just thought I'd toss that idea out there in case it might spark a solution "NOW" (to "Git-R-Dun") and then you might be able to address the https threading issue with less "rush". Just trying to help. --Jason On 8/30/2010 2:29 PM, Jarto Tarpio wrote: > Well, the demo pretty much does the same thing. It listens on incoming > connections and creates a new thread for handling the TCP/IP-connection. > The threads don't even try to pass data between each other after that. > The method is rock solid with http. > > I did some further tests. The same problem exists on Ubuntu jaunty. I > also made a Kylix-version, which also crashes with runtime error 231, > once you start hammering it with traffic. > > So, there seems to be something badly wrong with synapse's > openssl-support on Linux OR the demo does things wrong. > > New version at: http://www.starsoft.fi/jarto/httpsserv.tgz > > If you test this, notice that the server listens on port 4430. An easy > way to test is to create a long file with a few thousand lines of: > > wget -q -O /dev/null --no-check-certificate https://_ip_number_:4430/ > > And call that from a few computers. > > Regards, > > Jarto Tarpio > > On Mon, Aug 30, 2010 at 10:00:13AM -0400, Jason P Sage wrote: >> Not even looking at your code (time limited) I know the demo's do a >> good job of showing you how to get started. I wrote a pretty meaty web >> server/application server to the tune of 120,000 lines of code >> thereabouts that works great on both Linux and Windows. >> >> I had to make my own "listener thread" and hand off "work" to worker >> threads that are given the TCPIP connection and then the listener is >> "reset" , then the worker is told to resume. >> >> This works pretty decent but the problem between windows and linux for >> me was that they simply do not do multi-threading exactly the same and I >> had to make some Linux and Windows specific Code to handle the multiple >> threads (as you say - many hits coming from various computers) to work >> smoothly. >> >> Initially I wrote a way the parent thread can send a message to child >> threads and vice versa if necessary. I made critical sections for this >> special messaging thing.. and frankly it purrs on Linux but in windows I >> was being intermittently locking up for whatever reason. I did some >> reasearch and multi-thread debugging is difficult - so after awhile I >> never nailed the windows problem but it seemed to be getting hung as in >> thread contention or or dead-lock kind of deal... whatever you call it - >> I needed a better way to manage which worker threads got assigned to new >> web requests in windows. I had to made a loop that "PEEKED" into the >> status of the threads to see if they were done, sitting idle - and if so >> I'd use the first one I found matching this criteria for the next >> incoming request (from listener). >> >> In Linux my inter-thread Messaging system works brilliant... in windows >> I needed an alternative. >> >> Though I'm happy to report that 90% of my code thereabouts is OS >> independent... maybe a little more. >> >> Generally speaking the only code that needs special handling based on >> the operating system for me so far is: >> >> * inter-thread communication ( have on Linux, not used so much on windows ) >> * file things... like which way the slash goes forward for linux, and >> backwards for windows... >> >> Honestly, not a whole heck of a lot - FreePascal is sweet on that note >> for sure! So in the Synapse Library! >> --Jason >> >> >> >> On 8/30/2010 9:40 AM, Jarto Tarpio wrote: >>> I've been testing Synapse's own httpsserv-demo. It works well on >>> Windows, but on Linux it appears not to be thread-safe and crashes >>> badly. >>> >>> I changed the demo slightly to make it console-based (msgbox -> >>> writeln), so it would not require X11. When I fire lots of wget- >>> requests from several computers simultaneously at it, it crashes very >>> fast with the error message below. >>> >>> I'm using Debian 5.0.5 on a Dell PowerEdge T100. >>> Compiler: FPC 2.4.1 (latest 2.4.0 from the fixes-branch) >>> The error can be reproduced with both the stable- and trunk-versions >>> of Synapse. >>> >>> My changes and an unstripped binary are available at: >>> http://www.starsoft.fi/jarto/httpsserv.tgz >>> >>> Regards, >>> >>> Jarto Tarpio >>> >>> Error message: >>> *** glibc detected *** ./httpsservconsole: double free or corruption >>> (!prev): 0xb6402830 *** >>> ======= Backtrace: ========= >>> /lib/i686/cmov/libc.so.6[0xb7633764] >>> /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7635966] >>> /usr/lib/i686/cmov/libcrypto.so.0.9.8(CRYPTO_free+0x3a)[0xb7430cca] >>> /usr/lib/i686/cmov/libcrypto.so.0.9.8(ERR_clear_error+0x5c0)[0xb74a26f >>> 0] >>> /usr/lib/libssl.so(SSL_CTX_use_certificate_chain_file+0x242)[0xb757651 >>> 2] >>> ... >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >>> Be part of this innovative community and reach millions of netbook users >>> worldwide. Take advantage of special opportunities to increase revenue and >>> speed time-to-market. Join now, and jumpstart your future. >>> http://p.sf.net/sfu/intel-atom-d2d >>> _______________________________________________ >>> synalist-public mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/synalist-public >> >> ------------------------------------------------------------------------------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> _______________________________________________ >> synalist-public mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/synalist-public > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > synalist-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/synalist-public ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
