EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Proposed change to asyn drvAsynIPPort for UDP sockets
From: Torsten bögershaus <[email protected]>
To: Mark Rivers <[email protected]>
Cc: EPICS Core-Talk <[email protected]>, Henrique Almeida <[email protected]>, EPICS Tech Talk <[email protected]>
Date: Wed, 9 Dec 2015 21:22:10 +0100
I’m confused myself ;-)

I think there are 2 minor comments:
a) In flushIt(), the sender address is ignored anyway, so recv() works fine.
b) In readIt(), the print may be wrong or confusing on a stream socket.
>From nam recvfrom():
  If address is not a null pointer and the socket is not connection-oriented, the source address of the message is filled
     in.  The address_len argument is a value-result argument, initialized to the size of the buffer associated with address,
     and modified on return to indicate the actual size of the address stored there.

Solution: Separate stream from datagram. 
In short:

https://github.com/tboegi/asyn/tree/151210_2116_udp_fixes

BR
/Torsten



Am 09.12.2015 um 17:30 schrieb Mark Rivers <[email protected]>:

> I am a little confused by your message.
> 
> Which IP address is the IOC, 192.168.0.14, 192.168.0.15, or 192.168.0.99?
> 
> You are showing the source port being the same as the destination port (3333).  This is normally not the case, the source port for the message will be an ephemeral port that the system assigns, right?
> 
> The way drvAsynIPPort is written the destination address is fixed when the port is created by drvAsynIPPortConfigure.  The IP address string is copied to a private structure once, and that is the destination address that is used for all write operations.  So if .15 is the IOC in your example it is not possible for it to send messages to both .14 and .99 using the same drvAsynIPPort instance.
> 
> Mark
> 
> 
> -----Original Message-----
> From: Torsten bögershaus [mailto:[email protected]] 
> Sent: Wednesday, December 09, 2015 10:13 AM
> To: Mark Rivers
> Cc: Eric Norum; EPICS Core-Talk; Henrique Almeida; EPICS Tech Talk
> Subject: Re: Proposed change to asyn drvAsynIPPort for UDP sockets
> 
> Agreed, so far.
> 
> What about sendIt() ?
> What I understand, there are 2 scenarios:
> 1) "point to point" 
> 
> 192.168.0.14:3333 ---> UDP --->           192.168.0.15:3333
> 192.168.0.14:3333 <--- UDP <---           192.168.0.15:3333
> Both have a unique destination IP/port number.
> 
> 2)   Server-client
> 192.168.0.14:3333 ---> UDP --->           192.168.0.15:3333
>                                                                              Who was the last sender ?
> 192.168.0.14:3333 <--- UDP <---           192.168.0.15:3333
> 192.168.0.99:3333 ---> UDP --->           192.168.0.15:3333
>                                                                              Who was the last sender ?
> 192.168.0.99:3333 <--- UDP <---           192.168.0.15:3333
> (This is covered by recvfrom/sendto, I think)
> 
> 
> ------------
> Do we cover 
> 
> 1) "point to point" 
> 
> 192.168.0.14:3333 ---> UDP --->           192.168.0.15:3333
> 192.168.0.14:3333 <--- UDP <---           192.168.0.15:3333
> 192.168.0.99:3333 ---> UDP --->           192.168.0.15:3333
> 	                                                                      Where does the answer go?
> 
> /Torsten
> 
> 
> Am 09.12.2015 um 16:33 schrieb Mark Rivers <[email protected]>:
> 
>> Actually I think Torsten and Henrique have discovered a significant problem in my current implementation.
>> 
>> The problem is that when recvfrom() is called in readIt() and flushIt(), the IP address and port of the remote sender will replace the values in tty->farAddr.oa.sa.  This means that the next time octetWrite() is called, it will call sendto() using the address of the last responder, not the address that was originally specified when creating the port.  I don't think this is the correct behavior.  The solution is to use a local  osiSockAddr variable to receive the sender's address information in readIt() and flushIt(), not tty->farAddr.oa.sa.
>> 
>> Agreed?
>> 
>> Mark
>> 
>> 
>> From: Eric Norum [mailto:[email protected]] 
>> Sent: Wednesday, December 09, 2015 8:46 AM
>> To: Torsten bögershaus
>> Cc: Mark Rivers; EPICS Core-Talk; Henrique Almeida; EPICS Tech Talk
>> Subject: Re: Proposed change to asyn drvAsynIPPort for UDP sockets
>> 
>> 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.
> 



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
Re: Proposed change to asyn drvAsynIPPort for UDP sockets Eric Norum
RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Re: Proposed change to asyn drvAsynIPPort for UDP sockets Torsten bögershaus
RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers

Navigate by Date:
Prev: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Henrique Almeida
Next: Problem with generalTime clock synchronization Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
Next: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Henrique Almeida
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  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 ·