Re: Contribution question and TrafficMask

[Trustin Lee <tr...@gmail.com>]

Hi Greg,

On 3/31/07, Greg Duffy <gd...@gmail.com> wrote:
> I'm almost done with a first stab at a new datagram transport. It's about
> 1500 LoC. Should I just open a JIRA and attach it as I've done with patches
> before, or is there a different process for something of this size? Maybe a
> sandbox or something?
>
> Let me know the best way to get started.

I think it's just one or two classes, so attaching it to JIRA would be
fine.  Thanks for your contribution!

> Also, I'm having some trouble with the TrafficMask stuff. If we are blocking
> reads and writes, should I still queue them up? I think that I should drop
> them to avoid unlimited queue growth, but this doesn't seem to be agreeing
> with the existing unit test. I'll try and dig deeper, but some pointers on
> the intended behavior would be helpful.

All write requests are queued, so any write attempt should be queued
up until TrafficMask for write operations is cleared.  But I'm not
sure this is the optimal behavior, although the implementor will know
that he or she changed the traffic mask and therefore not writing
data.

For read operations, there's no queue because removing OP_READ
interestOp will suffice.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Contribution question and TrafficMask

[Greg Duffy <gd...@gmail.com>]

On 4/5/07, Trustin Lee <tr...@gmail.com> wrote:

> Yep, but user wrote by one's own will. ;)


True ... I guess it doesn't make sense to encourage all of the overhead of
writing a message if we just drop it on the floor. Maybe I can add some
clarity to the documentation for this, though.

I think dropping is reasonable for UDP because it's inevitable
> difference between transport type.  You could simply write some
> warning in the documentation.
>

I agree. We would also be able to do more in the UDP world with a
per-IoService TrafficMask ... I think that was being discussed already.

-Greg

Re: Contribution question and TrafficMask

[Trustin Lee <tr...@gmail.com>]

On 4/5/07, Greg Duffy <gd...@gmail.com> wrote:
> Yes, I am queuing write requests as well, but the way you mentioned seems
> like a possible ticket to OutOfMemoryError.

Yep, but user wrote by one's own will. ;)

> And on the read operation, we can't remove OP_READ on DatagramAcceptor,
> because there is just one selection key for many possible clients. I'm
> currently just checking the session's TrafficMask and dropping the message
> on the floor if it isn't readable.
>
> Any more thoughts on this?

I think dropping is reasonable for UDP because it's inevitable
difference between transport type.  You could simply write some
warning in the documentation.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Contribution question and TrafficMask

[Greg Duffy <gd...@gmail.com>]

Yes, I am queuing write requests as well, but the way you mentioned seems
like a possible ticket to OutOfMemoryError.

And on the read operation, we can't remove OP_READ on DatagramAcceptor,
because there is just one selection key for many possible clients. I'm
currently just checking the session's TrafficMask and dropping the message
on the floor if it isn't readable.

Any more thoughts on this?

-Greg

On 4/5/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Greg,
>
> On 3/31/07, Greg Duffy <gd...@gmail.com> wrote:
> > I'm almost done with a first stab at a new datagram transport. It's
> about
> > 1500 LoC. Should I just open a JIRA and attach it as I've done with
> patches
> > before, or is there a different process for something of this size?
> Maybe a
> > sandbox or something?
> >
> > Let me know the best way to get started.
>
> I think it's just one or two classes, so attaching it to JIRA would be
> fine.  Thanks for your contribution!
>
> > Also, I'm having some trouble with the TrafficMask stuff. If we are
> blocking
> > reads and writes, should I still queue them up? I think that I should
> drop
> > them to avoid unlimited queue growth, but this doesn't seem to be
> agreeing
> > with the existing unit test. I'll try and dig deeper, but some pointers
> on
> > the intended behavior would be helpful.
>
> All write requests are queued, so any write attempt should be queued
> up until TrafficMask for write operations is cleared.  But I'm not
> sure this is the optimal behavior, although the implementor will know
> that he or she changed the traffic mask and therefore not writing
> data.
>
> For read operations, there's no queue because removing OP_READ
> interestOp will suffice.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>