Re: Socket delayed read
Christine Jones <[email protected]> Thu, 26 Jul 2012 15:05:46 -0700
| Newsgroups | gmane.network.routing.click |
|---|---|
| Message-ID | <[email protected]> |
I've tried out the latest git repository version of Click, and the same problem occurs. Christine On Jul 19, 2012, at 7:30 AM, Christine Jones wrote: > I am running the head of the main Click git repository as of 9-22-2011. That is right before Click 2.0.1 was released. > > So, it has been awhile since I have updated. Have the bug fixes occurred more recently? > > Thanks! > > Christine > > On Jul 19, 2012, at 6:54 AM, Beyers Cronje wrote: > >> Hi, >> >> What version of Click are you running? There has been some bug fixes to >> Socket a while back that addressed some notifier and scheduling bugs. >> >> Beyers >> >> On Thu, Jul 19, 2012 at 3:25 PM, Christine Jones <[email protected]> wrote: >> >>> Hello! >>> >>> I am using Click to set up a router that installs a proxy service for a >>> subset of traffic. Much of the traffic flowing through the router is >>> forwarded as normal. But some traffic that meets certain criteria is sent >>> to the proxy (a user-space process on the local machine). The proxy also >>> sends packets and other state back to the Click router. >>> >>> There are two versions of this router, kernel and user-level. I am >>> encountering a problem with the user-level version. The communication >>> between router and proxy is via the Socket element configured to be a unix >>> socket, as such... >>> >>> proxy :: Socket(UNIX, 'pathname', CLIENT true) >>> >>> FromDevice >>> ... >>> -> proxy; >>> >>> proxy >>> ... >>> -> Queue >>> -> RawSocket(TCP); >>> >>> The problem is that when the router has a period in which no packets are >>> forwarded to the proxy the socket may not be read (although the socket is >>> configured for reading in the select loop and there is data waiting from >>> the proxy). If I force the router to write to that socket (with a periodic >>> keep-alive) then the socket will be read. However, I would prefer to not >>> have to rely on keep-alives. The socket should be selected when there is >>> data to read. >>> >>> Any thoughts? >>> >>> Thanks! >>> >>> Christine >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> _______________________________________________ >> click mailing list >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click