Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> - rtnet-check-receiving.diff
>>>>>>> @@ -375,13 +379,23 @@ ssize_t rt_udp_recvmsg(struct rtdm_dev_c
>>>>>>> struct udphdr *uh;
>>>>>>> struct sockaddr_in *sin;
>>>>>>> nanosecs_rel_t timeout = sock->timeout;
>>>>>>> - int ret;
>>>>>>> + int ret, index;
>>>>>>> + rtdm_lockctx_t context;
>>>>>>>
>>>>>>>
>>>>>>> /* non-blocking receive? */
>>>>>>> if (testbits(msg_flags, MSG_DONTWAIT))
>>>>>>> timeout = -1;
>>>>>>>
>>>>>>> + rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
>>>>>>> + if ((index = sock->prot.inet.reg_index) < 0) {
>>>>>>> + rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>>>>>>> + /* socket is being closed */
>>>>>>> + return -EBADF;
>>>>>>> + }
>>>>>>> + port_registry[index].receiving = 1;
>>>>>>> + rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>>>>>>> +
>>>>>> This is the only part of the patch I don't like. I don't want to add
>>>>>> another lock site to the RX path. I see the problem, but I think we need
>>>>>> some other solution. Maybe something that disables reception, and thus
>>>>>> unwanted buffer consumption.
>>>>> Well, I was too quick. There is another thing I don't like about this
>>>>> patch: It breaks valid use cases.
>>>>>
>>>>> Consider some application creating a socket first, then sending some
>>>>> message, next doing something else (or being preempted for a while), and
>>>>> finally calling into the recvmsg functions. With your change a potential
>>>>> reply to that sent-out message could have been dropped in the meantime
>>>>> because the socket was not yet marked as 'receiving'. Not good.
>>>> It seems I was too quick to admit your use case: would such an
>>>> application do this without binding the socket to another port than the
>>>> automacically assigned port ? Because once a socket is bound to a port
>>>> no received packet is lost.
>>> Well, not binding to a specific port is the standard pattern for client
>>> applications. And clients start their work with sending some packet to a
>>> server. So this use case is surely not unusual.
>> I would expect client applications to try to bind their socket to a
>> given port range, not to rely on the UDP stack to choose one in an
>> unknown range. This way, you get things working behind a firewall...
>
> First, there are /typically/ no firewalls to cross for RTnet
> applications. And second even if there are, hacking applications to work
> around some firewall shortcomings might be required from time to time
> but that must not be considered as a common application pattern.
>
> My point remains: We cannot block reception until the application calls
> recvmsg, we must allow it from the beginning. Blocking it on request is
> acceptable, though.
Ok. I had a look at Linux "shutdown" call, it seems to accept UDP
sockets, but is not used by anything in the UDP code except poll. The
only Linux call that we could use to avoid queuing received packets is
SO_RCVBUF. Of course, implementing rcvbuf for RTnet makes little sense,
because the messages pool has a finite number of messages, and every
message consumes a fixed amount of memory, so even with an rcvbuf limit,
if we received only small messages, we could exhaust the pool, the only
case that would make sense is rcvbuf set to 0.
--
Gilles.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
