tcl-core

[TCLCORE] TIP 287 [chan available] reference implementation

[Michael A. C. <mi...@cl...>]

I've updated TIP #287 (which proposes a [chan available]) command with
a pointer to the reference implementation/patch at SourceForge (RFE
1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
The patch also includes updated man pages and test cases.

Naturally feedback is appreciated.  I think this should be a
relatively uncontroversial TIP as it fits in nicely with the new
[chan] command in 8.5 (and will help authors of network daemons to
avoid a certain class of DoS attacks).

Michael

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Andreas K. <and...@ac...>]

> I've updated TIP #287 (which proposes a [chan available]) command with
> a pointer to the reference implementation/patch at SourceForge (RFE
> 1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
> The patch also includes updated man pages and test cases.
>
> Naturally feedback is appreciated.  I think this should be a
> relatively uncontroversial TIP as it fits in nicely with the new
> [chan] command in 8.5 (and will help authors of network daemons to
> avoid a certain class of DoS attacks).

Michael,

your are quoting from fileevent.n:

	A channel is also considered to be readable if there is unread
	data in an input buffer, except in the special case where the
	most recent attempt to read from the channel was a gets call
	that could not find a complete line in the input buffer.

I am not aware of this special case, and think that the manpage might be
wrong.

... Writing a test script ... Ok I seem to be wrong.

Using the attached scripts (yyy = sender incomplete line, zzz = sender complete
line, xxx = receiver), I find that after each push of an incomplete line to the
socket the receiver calls the event handler only twice and then stops. Until the
next chunk is received. Without the special case it would expect it to execute
the handler rapidly without stopping, until the line has been completed ...

Interesting. Now I am wondering how this is implemented.


Ok, I also found an older RFE by Colin McCormack


http://sourceforge.net/tracker/index.php?func=detail&aid=1399062&group_id=10894&
atid=360894
	gets with limited line-length

I think this should be discussed in the TIP

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Andreas K. <and...@ac...>]

> Using the attached scripts (yyy = sender incomplete line, zzz =
> sender complete
> line, xxx = receiver), I find that after each push of an incomplete
> line to the
> socket the receiver calls the event handler only twice and then
> stops. Until the
> next chunk is received. Without the special case it would expect it to execute
> the handler rapidly without stopping, until the line has been completed ...
>
> Interesting. Now I am wondering how this is implemented.

Aha. tclIO.c, Tcl_GetsObj, line 3854 (8.4 head, end of the function).
CHANNEL_NEED_MORE_DATA flag ...

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Michael A. C. <mi...@cl...>]

On 10/30/06, Andreas Kupries <and...@ac...> wrote:
> Ok, I also found an older RFE by Colin McCormack
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1399062&group_id=10894&
> atid=360894
>         gets with limited line-length
>
> I think this should be discussed in the TIP

I haven't downloaded the patch attached to Colin's RFE yet to see
(will do so tonight), but with the various ways one can call [gets] (0
to 3 arguments currently) the semantics seem like they could get a bit
messy if -maxchars were supported in all flavors.

Also I think you'd want to be able to distinguish between the case
where you got -maxchars because that is exactly what was there to be
read and when you got -maxchars because you hit the maximum.  I
suppose you could distinguish the case by requesting -maxchars [expr
{$limit + 1}] and then testing [string length $line] to see if it were
just $limit or ($limit + 1) ...

Anyway, I think [chan available] is a good fit with the new [chan]
ensembles in 8.5 and approving the TIP shouldn't preclude a separate
TIP for changing [gets] in my opinion.

Michael

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Donald G P. <dg...@ni...>]

Michael A. Cleverly wrote:
> I've updated TIP #287 (which proposes a [chan available]) command with
> a pointer to the reference implementation/patch at SourceForge (RFE
> 1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
> The patch also includes updated man pages and test cases.
> 
> Naturally feedback is appreciated. 

I think it would be helpful to add tests to the test suite that 
demonstrate this feature's effectiveness at addressing the use cases in 
the proposal.  Tests that actually show event-driven channel operations.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Michael A. C. <mi...@cl...>]

On 10/31/06, Donald G Porter <dg...@ni...> wrote:
> Michael A. Cleverly wrote:
> > I've updated TIP #287 (which proposes a [chan available]) command with
> > a pointer to the reference implementation/patch at SourceForge (RFE
> > 1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
> > The patch also includes updated man pages and test cases.
> >
> > Naturally feedback is appreciated.
>
> I think it would be helpful to add tests to the test suite that
> demonstrate this feature's effectiveness at addressing the use cases in
> the proposal.  Tests that actually show event-driven channel operations.

I've uploaded a new chan.test.patch which adds an event-driven socket
test (chan-16.6).

Michael