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. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
