Ah yes, you are right. [timeout( is for TCP. I think I got that mixed up with UDP previously closing itself after some sort of unknown host return etc which we removed to make it "fire and forget."
On Jun 4, 2021, at 4:17 PM, pd-list-request@lists.iem.at wrote:
Message: 3 Date: Fri, 04 Jun 2021 16:17:29 +0200 From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> To: Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> Cc: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] UDP server with Pd Message-ID: <2aed329cdb23e198c96f658f05a81ce4f276bf84.camel@gmail.com mailto:2aed329cdb23e198c96f658f05a81ce4f276bf84.camel@gmail.com> Content-Type: text/plain; charset="utf-8"
On Thu, 2021-06-03 at 19:51 +0200, Dan Wilcox wrote:
You could try a longer connection timeout via the [timeout f( message.
Isn't the 'timeout' method only affecting TCP sessions? In UDP nothing at all is sent when using 'connect' method. It internally sets destination address and port, I believe.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Fri, 2021-06-04 at 21:34 +0200, Dan Wilcox wrote:
Ah yes, you are right. [timeout( is for TCP. I think I got that mixed up with UDP previously closing itself after some sort of unknown host return etc which we removed to make it "fire and forget."
Ah, now I remember. It was that thread where I read about those notification messages. Your message reminded me that I was actually testing with [iemnet/udpclient] which does not seem to ignore those messages. And indeed, [netsend -u] does _not_ disconnect itself when sending many packets to Miller's proposed UDP server emulation. However, many packets are dropped, even on localhost. So, it seems that the quickly-binding-and-releasing-port business doesn't really make for a decent UDP server, unfortunately. I was hoping that a C illiterate person like me would get something going with Pd performing better than with Python. I guess I have to wait for https://github.com/pure-data/pure-data/issues/949 or learn C ;-)
Roman
I guess I have to wait for https://github.com/pure-data/pure-data/issues/949 or learn C ;-)
I've mentioned [iemnet/udpserver] a couple of times now. Does it not work for your use case?
Christof
On 04.06.2021 22:59, Roman Haefeli wrote:
On Fri, 2021-06-04 at 21:34 +0200, Dan Wilcox wrote:
Ah yes, you are right. [timeout( is for TCP. I think I got that mixed up with UDP previously closing itself after some sort of unknown host return etc which we removed to make it "fire and forget."
Ah, now I remember. It was that thread where I read about those notification messages. Your message reminded me that I was actually testing with [iemnet/udpclient] which does not seem to ignore those messages. And indeed, [netsend -u] does _not_ disconnect itself when sending many packets to Miller's proposed UDP server emulation. However, many packets are dropped, even on localhost. So, it seems that the quickly-binding-and-releasing-port business doesn't really make for a decent UDP server, unfortunately. I was hoping that a C illiterate person like me would get something going with Pd performing better than with Python. I guess I have to wait for https://github.com/pure-data/pure-data/issues/949 or learn C ;-)
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2021-06-04 at 23:03 +0200, Christof Ressi wrote:
I guess I have to wait for https://github.com/pure-data/pure-data/issues/949 or learn C ;-)
I've mentioned [iemnet/udpserver] a couple of times now. Does it not work for your use case?
Yes, you did. Sorry for not reacting earlier. The help only mentions the 'broadcast' method for sending packets. I don't actually know what it is supposed to do, but it seems to only send back to the client the last packet was coming from (or I am too slow switching windows and miss some timeout). Tested with iemnet 0.3.0. What I am looking for is to send to any client specified by address and port.
Roman
I don't actually know what it is supposed to do, but it seems to only send back to the client the last packet was coming from
Yes. That's what I explained.
What I am looking for is to send to any client specified by address and port.
Ok, so [iemnet/udpserver] won't work for your use case.
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -, you could make a feature request to
iemnet ;-)
I've already looked at the code for [iemnet/udpserver] and it shouldn't be too hard to implement.
Chrisotf
On 04.06.2021 23:21, Roman Haefeli wrote:
On Fri, 2021-06-04 at 23:03 +0200, Christof Ressi wrote:
I guess I have to wait for https://github.com/pure-data/pure-data/issues/949 or learn C ;-)
I've mentioned [iemnet/udpserver] a couple of times now. Does it not work for your use case?
Yes, you did. Sorry for not reacting earlier. The help only mentions the 'broadcast' method for sending packets. I don't actually know what it is supposed to do, but it seems to only send back to the client the last packet was coming from (or I am too slow switching windows and miss some timeout). Tested with iemnet 0.3.0. What I am looking for is to send to any client specified by address and port.
Roman
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Roman
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Or you could copy the code from mrpeach/udpsndrcv into your own external.
Martin
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Or you could copy the code from mrpeach/udpsndrcv into your own external.
To me, [mrpeach/udpsndrcv] looks more similar to [iemnet/udpclient] than to [iemnet/udpserver]. Both, [mrpeach/udpsndrc] and [iemnet/udpclient] require the bind port to be closed before creating a new connection. [udpserver] would (ideally) keep the bind port open at any time and still be able to set an address (destination address and port) for sending.
Roman
Am 5. Juni 2021 09:29:35 MESZ schrieb Roman Haefeli reduzent@gmail.com:
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
[udpserver] would (ideally) keep the bind port open at any time and still be able to set an address (destination address and port) for sending.
i'm totally open to any improvements in iemnet's [udpserver]. The reason it's advancement stalled was that i couldnt decide on an algorithm to keep "active" clients. I'm happy for input on this (as a ticket on our git instance)
Roman
On Sat, Jun 5, 2021 at 3:31 AM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Or you could copy the code from mrpeach/udpsndrcv into your own external.
To me, [mrpeach/udpsndrcv] looks more similar to [iemnet/udpclient] than to [iemnet/udpserver]. Both, [mrpeach/udpsndrc] and [iemnet/udpclient] require the bind port to be closed before creating a new connection. [udpserver] would (ideally) keep the bind port open at any time and still be able to set an address (destination address and port) for sending.
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth. Martin
IMO, those are just silly workarounds. When I send a packet from A to B, I would expect to get a reply from B and not some random socket C.
What we actually need is a UDP networking object that can independently
listen for packets on a given port
send packets to any destination
There is no reason why we would need two seperate objects for this. A UDP socket is perfectly capable of doing both at the same time.
Christof
On 07.06.2021 02:26, Martin Peach wrote:
On Sat, Jun 5, 2021 at 3:31 AM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Or you could copy the code from mrpeach/udpsndrcv into your own external.
To me, [mrpeach/udpsndrcv] looks more similar to [iemnet/udpclient] than to [iemnet/udpserver]. Both, [mrpeach/udpsndrc] and [iemnet/udpclient] require the bind port to be closed before creating a new connection. [udpserver] would (ideally) keep the bind port open at any time and still be able to set an address (destination address and port) for sending.
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth. Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman
OK, I have implemented something that might work: [udpsrvr] can listen on a port and send to an address using the same or a different port. The only problem I see with it is that while the socket is connected for a send, it won't receive anything. I overcome this partly by sending the connect/send/disconnect sequence in one comma-delimited message. The code is at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/ne...
Martin
On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli reduzent@gmail.com wrote:
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The only problem I see with it is that while the socket is connected for a send, it won't receive anything.
Why is that? This shouldn't happen.
BTW, you don't actually have to call connect(), instead you could just save the sockaddr and use sendto(). Consequently you could also rename the [connect( method to something else, e.g. [set <host> <port>( or [client <host> <port>(, etc. After all, a server doesn't *connect* to a client...
Christof
On 07.06.2021 21:34, Martin Peach wrote:
OK, I have implemented something that might work: [udpsrvr] can listen on a port and send to an address using the same or a different port. The only problem I see with it is that while the socket is connected for a send, it won't receive anything. I overcome this partly by sending the connect/send/disconnect sequence in one comma-delimited message. The code is at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/ne...
Martin
On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli reduzent@gmail.com wrote:
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi info@christofressi.com wrote:
The only problem I see with it is that while the socket is connected for a send, it won't receive anything.
Why is that? This shouldn't happen.
I don't know why, that's what happens when I try it here on linux. I will see if sendto() works any better. Thanks for the tip.
Martin
BTW, you don't actually have to call connect(), instead you could just save the sockaddr and use sendto(). Consequently you could also rename the [connect( method to something else, e.g. [set <host> <port>( or [client <host> <port>(, etc. After all, a server doesn't *connect* to a client...
Christof
On 07.06.2021 21:34, Martin Peach wrote:
OK, I have implemented something that might work: [udpsrvr] can listen on a port and send to an address using the same or a different port. The only problem I see with it is that while the socket is connected for a send, it won't receive anything. I overcome this partly by sending the connect/send/disconnect sequence in one comma-delimited message. The code is at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/ne...
Martin
On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli reduzent@gmail.com wrote:
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
So I changed it to use sendto and it works a lot better. It receives from multiple clients while sending to any one. I added a [to ( message to set the destination, and removed the [connect( and [disconnect{ methods. Thanks Christof for the critique!.
Martin
On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi info@christofressi.com wrote:
The only problem I see with it is that while the socket is connected for a send, it won't receive anything.
Why is that? This shouldn't happen.
BTW, you don't actually have to call connect(), instead you could just save the sockaddr and use sendto(). Consequently you could also rename the [connect( method to something else, e.g. [set <host> <port>( or [client <host> <port>(, etc. After all, a server doesn't *connect* to a client...
Christof
On 07.06.2021 21:34, Martin Peach wrote:
OK, I have implemented something that might work: [udpsrvr] can listen on a port and send to an address using the same or a different port. The only problem I see with it is that while the socket is connected for a send, it won't receive anything. I overcome this partly by sending the connect/send/disconnect sequence in one comma-delimited message. The code is at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/ne...
Martin
On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli reduzent@gmail.com wrote:
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Great to hear!
On 07.06.2021 22:57, Martin Peach wrote:
So I changed it to use sendto and it works a lot better. It receives from multiple clients while sending to any one. I added a [to ( message to set the destination, and removed the [connect( and [disconnect{ methods. Thanks Christof for the critique!.
Martin
On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi info@christofressi.com wrote:
The only problem I see with it is that while the socket is connected for a send, it won't receive anything.
Why is that? This shouldn't happen.
BTW, you don't actually have to call connect(), instead you could just save the sockaddr and use sendto(). Consequently you could also rename the [connect( method to something else, e.g. [set <host> <port>( or [client <host> <port>(, etc. After all, a server doesn't *connect* to a client...
Christof
On 07.06.2021 21:34, Martin Peach wrote:
OK, I have implemented something that might work: [udpsrvr] can listen on a port and send to an address using the same or a different port. The only problem I see with it is that while the socket is connected for a send, it won't receive anything. I overcome this partly by sending the connect/send/disconnect sequence in one comma-delimited message. The code is at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/ne...
Martin
On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli reduzent@gmail.com wrote:
On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth.
Again, this does not work. The socket on the client side will only accept packets originating from the port it has sent packets to, but [udpsend] on the server cannot use this port as bind port, because it is already occupied by [udpreceive]. To put this into telephone analogy: When you call someone, you expect a third party to be prohibited from shouting into your call, and you expect to hear only the party you called.
The only solution to this is to use the same socket for both sending and receiving, as Christof already suggested.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2021-06-07 at 16:57 -0400, Martin Peach wrote:
So I changed it to use sendto and it works a lot better. It receives from multiple clients while sending to any one. I added a [to ( message to set the destination, and removed the [connect( and [disconnect{ methods. Thanks Christof for the critique!.
Seems to work as advertised! I find the interface with a 'to' method makes sense.
I will do some more extensive test with some more load.
Great! Thanks for your effort!
Roman
On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote:
On Mon, 2021-06-07 at 16:57 -0400, Martin Peach wrote:
So I changed it to use sendto and it works a lot better. It receives from multiple clients while sending to any one. I added a [to ( message to set the destination, and removed the [connect( and [disconnect{ methods. Thanks Christof for the critique!.
I will do some more extensive test with some more load.
A quick follow-up. The new object [udpsrvr] works flawlessly. I couldn't find any issues with it. I've used it to relay packets between multiple clients.
However, my hope a Pd implementation is faster than the python script turned out to be forlorn. In reality, the Pd version eats ~50% more cycles (at least same ballpark, which is still impressive for Pd, I think).
Roman
On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote:
....
A quick follow-up. The new object [udpsrvr] works flawlessly. I couldn't find any issues with it. I've used it to relay packets between multiple clients.
However, my hope a Pd implementation is faster than the python script turned out to be forlorn. In reality, the Pd version eats ~50% more cycles (at least same ballpark, which is still impressive for Pd, I think).
In the last commit I added a verbosity method so it doesn't print to the console by default. This may speed it up a bit. OTOH I added an symbol output of the IP so it can be fed directly into the [to( message, so that may slow it down if the symbol lookup takes a long time.
Martin
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2021-06-09 at 10:41 -0400, Martin Peach wrote:
On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote:
....
A quick follow-up. The new object [udpsrvr] works flawlessly. I couldn't find any issues with it. I've used it to relay packets between multiple clients.
However, my hope a Pd implementation is faster than the python script turned out to be forlorn. In reality, the Pd version eats ~50% more cycles (at least same ballpark, which is still impressive for Pd, I think).
In the last commit I added a verbosity method so it doesn't print to the console by default.
I commented out the respective 'post', because printing something to the console on each 'to' message was too much.
This may speed it up a bit. OTOH I added an symbol output of the IP so it can be fed directly into the [to( message, so that may slow it down if the symbol lookup takes a long time.
Whether I create the symbol or get it directly from the output, isn't the lookup the same? Anyway, there is/was a discussion on the iemnet repo whether the number list ipv4 address should be replaced by symbolic ipv4 address. I think that it makes sense.
Roman
-
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig -
Martin Peach -
Roman Haefeli