On Wed, Oct 10, 2001 at 02:35:51PM -0500, Andrew Sutton wrote:
>
> 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?
Correct.
> 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?
No. Because of the half duplex stuff, you need to wait for the
pf bit to come back to you.
> > 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 :)
Yes, I wrote that in a former life. I'm not totally happy
about the API, because it's kind of kludgy. I prefer what I did with
the event channel (you can use select or poll, which is much cleaner,
and you are sure to not miss any event).
> 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 :)
Yes, I forgot about expiry. The expiry timeout is 6 seconds
(i.e. 6s after the last discovery sighting, the log entry is cleaned
up and the expiry event propagated).
The event is not available through IrSock. Probably it should
be hoocked in the IRLMP_WAITDEVICE stuff, so that you get both events
at once. But I told you that I'm not satisfied of the API of
IRLMP_WAITDEVICE...
> again, thanks,
>
> Andrew Sutton
> [EMAIL PROTECTED]
Have fun...
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
