source: TI12-security/branches/Dependencies/m2crypto/contrib/dave.README @ 2172

Subversion URL: http://proj.badc.rl.ac.uk/svn/ndg/TI12-security/branches/Dependencies/m2crypto/contrib/dave.README@2237
Revision 2172, 2.7 KB checked in by pjkersha, 13 years ago (diff)
Line 
1From dave@pythonapocrypha.com  Wed Dec 11 07:57:55 2002
2Date: Tue, 10 Dec 2002 15:05:26 -0800 (PST)
3From: Dave Brueck <dave@pythonapocrypha.com>
4To: ngps@netmemetic.com
5Subject: M2Crypto problem with asynch sockets
6
7Hi and thanks for M2Crypto - great stuff!
8
9I wrote an asynchronous socket layer and decided to use M2Crypto to add
10SSL support to it. Unfortunately, I've found a small problem in
11_m2crypto_wrap.c - hopefully I'm just not understanding something.
12
13The ssl_connect, ssl_read_nbio, etc. calls don't differentiate between
14SSL_ERROR_WANT_WRITE and SSL_ERROR_WANT_READ when a non-blocking call
15couldn't finish. But without this information, I don't know whether the
16socket needs to do more reading or more writing before a subsequent
17attempt will work without blocking. The demo applications (e.g.
18echod-async.py) don't seem to care about this but they get around it by
19simply trying the operation over and over again, which I can't do for
20performance reasons.
21
22Am I missing something? I thought about just calling SSL_get_error when
23the above calls return None (indicating WANT_READ or WANT_WRITE), but by
24then the error has already been removed from the SSL error queue.
25
26Any help or suggestions would be appreciated. I'd be happy to submit a
27patch fixing those calls, but by not returning None they would break
28existing code.
29
30Thanks again for M2Crypto though!
31
32-Dave
33
34
35From dave@pythonapocrypha.com  Fri Dec 13 00:46:39 2002
36Date: Thu, 12 Dec 2002 09:52:08 -0800 (PST)
37From: Dave Brueck <dave@pythonapocrypha.com>
38To: ngps@netmemetic.com
39Subject: Re: M2Crypto problem with asynch sockets
40
41Hello again,
42
43Here is a patch to M2Crypto's _ssl.i that illustrates the fix I had in
44mind in my previous message. You might not want to use it as is since it
45changes the error semantics of the affected functions (they now raise an
46exception that contains the SSL_WANT_READ or SSL_WANT_WRITE flag instead
47of returning None or whatever), but if you tell me how you'd like it
48instead then I'd be happy to fix the patch and send it back to you.
49
50Just to refresh your memory, this patch fixes the problem where a
51non-blocking call to accept/connect/etc results in an SSL_NEED_READ/WRITE;
52currently there's no way for the caller to know _which_ of the two
53occurred and so it must try again once the socket has become readable OR
54writeable, instead of waiting specifically for one or the other. For many
55people this won't matter because their performance requirements are low
56enough that trying the ssl_accept/etc call again prematurely won't hurt
57too much, but for servers with lots of connections or high throughput it's
58much more critical to wait until you know the SSL call has a better chance
59of success.
60
61Thanks!
62-Dave Brueck
63
64
Note: See TracBrowser for help on using the repository browser.