On Wednesday 10 October 2001 12:14, Jean Tourrilhes wrote:
> Andrew Sutton wrote :
> ...

thanks for the feedback jean.

>
>       Here are the two sysctl you may use :
>               o max_inactive_time
>               o lap_keepalive_time
>       As I was the one adding them to the stack, I will explain you
> what they do. By the way Werner, this is Howto material ;-)
> <snip>

let me see if i haven't gotten this straight :) the max_inactive_time sysctl 
essentially defines when to break the link (after so many RR frames not 
received). so i miss so many frames in max_inactive_time seconds, and the 
link is broken. sound right?

the lap_keepalive_time sort of corresponds to the final fin packet for tcp - 
how long the connection hangs around after the sockets are closed. that about 
right?

so what i'd probably want to do is set the max_inactive_time to the lowest 
possbile value (3) for faster timeouts. we're using rj45 cable, not wireless, 
so this value really could be lower than that. would it be possible to 
request an immediate release when the device is out of range? like setting 
max_inactive_time to 0, thereby indicating that broken links will 
automatically release the connection?

>
> > an additional concern is how timeouts affect discovery. in order to
> > ensure optimal pnp interoperability, i'd like to be able to rediscover a
> > device as soon as its plugged in. if the device was unplugged or the link
> > broken, i believe the discovery entry for that device may persist after
> > the timeout occurs and i have to wait until that entry is gone before
> > re-discovering the device. does the irda stack automatically remove the
> > discovery entry after a timeout?
>
>       You may have seen me doing quite some work on the issue,
> making sure that discovery events are propagated in timely
> fashion. For now, those events are only plugged on the IrNET control
> channel.
>       As of 2.4.10, all Discovery and Expiry events are propagated
> up the stack with no delay (except passive discovery - 200ms). This
> allow a user space program to act as soon as the IrDA stack discover a
> device.
>       However, the speed of discovery is contrained by the period of
> the discover frame. Discovery happens every 3s, so you may wait up to 3s.

i think i dropped the discovery rate to 1 second for faster discovery times. 
i'm using IRLMP_WAITDEVICE to block until a device comes into range (or is 
plugged in in my case) and then my application reacts - pretty fast too :)

does an expiry event describe an event where a device is no longer in range 
(plugged in?) if so, how is that event available through the IrSock layer? 
i'll probably have to go digging thru the latest kernel stack eventually :)

again, thanks,

Andrew Sutton
[EMAIL PROTECTED]
_______________________________________________
Linux-IrDA mailing list  -  [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda

Reply via email to