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.
- 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
- Re: Proposed change to asyn drvAsynIPPort for UDP sockets Eric Norum
- RE: Proposed change to asyn drvAsynIPPort for UDP sockets Mark Rivers
- Navigate by Date:
- Prev:
Re: Proposed change to asyn drvAsynIPPort for UDP sockets Eric Norum
- 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 Mark Rivers
- 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
|