EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: Proposed change to asyn drvAsynIPPort for UDP sockets
From: Eric Norum <[email protected]>
To: Torsten bögershaus <[email protected]>
Cc: EPICS Core-Talk <[email protected]>, Mark Rivers <[email protected]>, EPICS Tech Talk <[email protected]>, Henrique Almeida <[email protected]>
Date: Wed, 9 Dec 2015 06:45:51 -0800
ASYN has never allowed multiplexing multiple transactions through a single socket like that.   Mark’s proposed change of recv to recvfrom is simply to provide additional information for diagnostic messages.  The other changes (use sendto rather than connect/send for SOCK_DGRAM sockets) is to support devices which respond to UDP broadcasts. 

On Dec 9, 2015, at 5:28 AM, Torsten bögershaus <[email protected]> wrote:

May be unrelated.
(And may be we should have the comments on Github.)

Can we cover the following example ?


                                                  Our EPICS IOC
192.168.0.14 ———> UDP ———>                             AsynUser 1 reads it. Does some processing. sleeping…

192.168.0.15 ———> UDP ———>                             AsynUser 2 reads it. Does some processing. sleeping…
                                                                                     AsynUser 1 wants to answer. Does the answer go to 192.168.0.14 ?
                                                                                     Or does it go to 192.168.0.15 ??



On Dec 9, 2015, at 4:35 AM, Henrique Almeida <[email protected]> wrote:

This only seems to be correct if the messages are processed sequentially, first receiving, then consuming the message, then receiving one more message and so on. If the code allows receiving and consuming the messages out of order, then this is mixing the messages source addresses in tty->farAddr.oa.sa.

 If necessary, the remote address should be linked to the message, not to the socket, and consumed with it.

Replies:
RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
References:
Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Re: Proposed change to asyn drvAsynIPPort for UDP sockets Henrique Almeida
RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Re: Proposed change to asyn drvAsynIPPort for UDP sockets Torsten bögershaus
Navigate by Date:
Prev: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Torsten bögershaus
Next: RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Torsten bögershaus
Next: RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <2015>  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·