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