On Wed, 2021-06-09 at 10:41 -0400, Martin Peach wrote:
> On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli
> 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
On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli 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
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
On Tue, Jun 08, 2021 at 05:44:39PM +0200, IOhannes m zm?lnig wrote:
>
>
> Am 8. Juni 2021 17:05:13 MESZ schrieb Miller Puckette via Pd-list
> :
> >P.S. maybe 'sendto' would be clearer - 'to' could be misunderstood as
> >just setting
> >a return port/addr for a later 'send' (which I think would
Am 8. Juni 2021 17:05:13 MESZ schrieb Miller Puckette via Pd-list
:
>P.S. maybe 'sendto' would be clearer - 'to' could be misunderstood as
>just setting
>a return port/addr for a later 'send' (which I think would make
>netreceive -u
>unnecessarily stateful).
i think 'sendto' only makes sense
P.S. maybe 'sendto' would be clearer - 'to' could be misunderstood as just
setting
a return port/addr for a later 'send' (which I think would make netreceive -u
unnecessarily stateful).
On Tue, Jun 08, 2021 at 08:01:30AM -0700, Miller Puckette via Pd-list wrote:
> Yep, I was going to propose
eak patches.
>
> > On Jun 7, 2021, at 11:00 PM, pd-list-requ...@lists.iem.at wrote:
> >
> > Message: 4
> > Date: Mon, 7 Jun 2021 23:00:21 +0200
> > From: Christof Ressi > <mailto:i...@christofressi.com>>
> > To: Martin Peach mailto:chakekat...@gm
artin Peach mailto:chakekat...@gmail.com>>,
> Pd-List
> mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] UDP server with Pd
> Message-ID: <mailto:df5de976-556c-2a67-01f5-0c95d3adc...@christofressi.com>>
> Content-Type: text/plain; charset=utf-8; forma
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
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
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
On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi 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
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
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
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
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
1) listen for packets on a given port
2) send packets to any destination
There
On Sat, Jun 5, 2021 at 3:31 AM Roman Haefeli wrote:
>
> On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
> > On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli
> > wrote:
> > > On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
> > > > Instead of waiting for
> > > >
Am 5. Juni 2021 09:29:35 MESZ schrieb Roman Haefeli :
>> > > 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
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
> On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli
> 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
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli 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.
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.
>
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.
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
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
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
: 3
> Date: Fri, 04 Jun 2021 16:17:29 +0200
> From: Roman Haefeli mailto:reduz...@gmail.com>>
> To: Dan Wilcox mailto:danomat...@gmail.com>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] UDP server with Pd
> Message-ID: <2aed329cd
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
021 14:52:07 +0200
> From: Roman Haefeli mailto:reduz...@gmail.com>>
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: Re: [PD] UDP server with Pd
> Message-ID: <mailto:d588131641f4e973e59201abc884fc5191cb0e6c.ca...@gmail.com>>
> Content-Type: tex
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
> One solution (which the conniption server/client and quacktrip both
> use in somewhat different ways) is for a "netreceive" object to wait
> for an incoming connection and then, once one arrives, immediately to
> close
> its
On Wed, 2021-06-02 at 17:29 -0400, Martin Peach wrote:
>
> What is/are the issue{s} with firewall + NAT? Asking because I never
> used either, I only ever use them on a LAN.
From what I know, NAT firewalls forward packets coming back from a
public server only when previously a matching packet
On Wed, Jun 2, 2021 at 12:09 PM Christof Ressi wrote:
>
> On 02.06.2021 16:55, Martin Peach wrote:
>
> > On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli wrote:
> > You could still have the server reply to the source port plus one, or
> > something like that,
> This doesn't solve anything regarding
as solid as a
rock. It may not be Pd-native, but it does the job extremely well.
Best,
Phil Stone
Davis, CA
From: Christof Ressi
To: Pd-List
Subject: Re: [PD] UDP server with Pd
Message-ID: <06b68c67-a27e-81d8-4b6e-5b60db943...@christofressi.com>
Content-Type: text/plain; charset=
If you want the server to reply only to the current client,
[iemnet/udpserver] actually works fine (despite the error message in the
console): the list method will send the packet to the source address of
the most recently received packet.
However, if you need to send packets to several/all
On 02.06.2021 16:55, Martin Peach wrote:
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli wrote:
(replying to list as - I believe - you intended to)
On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote:
On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli
wrote:
On Tue, 2021-06-01 at 19:19 -0400,
OK, I found it now...The object is [udpsndrcv] in mrpeach.
It allows you to set the source and destination ports and send and
receive on them.
Martin
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli wrote:
>
> (replying to list as - I believe - you intended to)
>
> On Wed, 2021-06-02 at 09:34
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli wrote:
>
> (replying to list as - I believe - you intended to)
>
> On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote:
> > On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli
> > wrote:
> > > On Tue, 2021-06-01 at 19:19 -0400, Martin Peach wrote:
> > > >
(replying to list as - I believe - you intended to)
On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote:
> On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli
> wrote:
> > On Tue, 2021-06-01 at 19:19 -0400, Martin Peach wrote:
> > > A [udpsend] normally has a different port number to the one it
> > >
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
> One solution (which the conniption server/client and quacktrip both
> use in somewhat different ways) is for a "netreceive" object to wait
> for an incoming connection and then, once one arrives, immediately to
> close
> its
The mrpeach [udpsend] outputs its ip and port on the second outlet on
'connect', while the[ [udpreceive] object outputs the ip and port of
each received datagram, so using both you should be able to do what
you want.
A [udpsend] normally has a different port number to the one it sends
to, but a
only send
> > back to all connected clients, but not to a specific one.
> Actually, a [sendto( message for [netreceive] would already allow you to
> build a fully functional UDP server in Pd vanilla.
>
> BTW, there is a [udpserver] object in iemnet, but it's not really usable yet
While we're at it, it seems [netreceive] (in TCP mode) can only send
back to all connected clients, but not to a specific one.
Actually, a [sendto( message for [netreceive] would already allow you to
build a fully functional UDP server in Pd vanilla.
BTW, there is a [udpserver] object
Hey all
I would like to open a datagram listening socket and be able to send
back to clients from which I received messages. It seems both [netsend
-u] and (obviously) [netreceive -u] actually can open a listening
socket. However, [netreceive -u] can't send anything back. While
[netsend -u] can
42 matches
Mail list logo
