On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote:
Jorge wrote:
On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P
You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough.
Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close).
The patch avoids this.
I'm a bit hesitant to return a msg if we don't plan to do anything with it, but then if we have to send back something, it does make sense to put some information in there...
That's the canonical way of doing it in DPIP. If the message sender is not interested in the answer, he can ignore it (as in this case). This allows for a simpler communication algorithm and a uniform way of dealing with DPIP messages. The patch sends an answer that says whether the cookie was set. It is easy to extend it to say what happened if the need arises. -- Cheers Jorge.-