* UDP: Send and receive on same port?
@ 2021-03-30 8:58 Mario Lang
2021-03-30 11:11 ` Mario Lang
0 siblings, 1 reply; 5+ messages in thread
From: Mario Lang @ 2021-03-30 8:58 UTC (permalink / raw)
To: emacs-devel
Hi.
Certain OSC (Open Sound Control) applications reply to the UPD sender
port, making it necessary to listen on the same port which was allocated
for the sending process. I remember having asked this roughly a year
ago, and the answer was a no. I'd like to re-raise this one: Can we do
something with the process framework to allow listening on a UDP client
port? I dont see a way to get the allocated port of the sending
process.
--
CYa,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UDP: Send and receive on same port?
2021-03-30 8:58 UDP: Send and receive on same port? Mario Lang
@ 2021-03-30 11:11 ` Mario Lang
2021-03-30 15:23 ` Robert Pluim
0 siblings, 1 reply; 5+ messages in thread
From: Mario Lang @ 2021-03-30 11:11 UTC (permalink / raw)
To: emacs-devel
Replying to self
Nevermind, it works by creating a datagram server first, and then using
set-process-datagram-address to set the destination. The server process
can now be used to send UDP as well. However, I am seeing lost incoming
packets. According to tcpdump, the reply is clearly there, but the
process filter only seems to pick it up 1 out of roughly 4 times.
Weird.
Mario Lang <mlang@blind.guru> writes:
> Hi.
>
> Certain OSC (Open Sound Control) applications reply to the UPD sender
> port, making it necessary to listen on the same port which was allocated
> for the sending process. I remember having asked this roughly a year
> ago, and the answer was a no. I'd like to re-raise this one: Can we do
> something with the process framework to allow listening on a UDP client
> port? I dont see a way to get the allocated port of the sending
> process.
--
CYa,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UDP: Send and receive on same port?
2021-03-30 11:11 ` Mario Lang
@ 2021-03-30 15:23 ` Robert Pluim
2021-03-30 21:03 ` Mario Lang
0 siblings, 1 reply; 5+ messages in thread
From: Robert Pluim @ 2021-03-30 15:23 UTC (permalink / raw)
To: Mario Lang; +Cc: emacs-devel
>>>>> On Tue, 30 Mar 2021 13:11:47 +0200, Mario Lang <mlang@blind.guru> said:
Mario> Replying to self
Mario> Nevermind, it works by creating a datagram server first, and then using
Mario> set-process-datagram-address to set the destination. The server process
Mario> can now be used to send UDP as well. However, I am seeing lost incoming
Mario> packets. According to tcpdump, the reply is clearly there, but the
Mario> process filter only seems to pick it up 1 out of roughly 4 times.
Mario> Weird.
Hmm, I have a patch somewhere to allow setting the sending port
directly, Iʼll see if I can find it and resurrect it.
Having said that, this sounds like it might be a bug (although I
haven't checked if the emacs code supports sending from a datagram
server like this). Could you open a bug with M-x report-emacs-bug with
your emacs version, and sample code?
Robert
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UDP: Send and receive on same port?
2021-03-30 15:23 ` Robert Pluim
@ 2021-03-30 21:03 ` Mario Lang
2021-03-31 9:14 ` Robert Pluim
0 siblings, 1 reply; 5+ messages in thread
From: Mario Lang @ 2021-03-30 21:03 UTC (permalink / raw)
To: Robert Pluim; +Cc: emacs-devel
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Tue, 30 Mar 2021 13:11:47 +0200, Mario Lang <mlang@blind.guru> said:
>
> Mario> Replying to self
> Mario> Nevermind, it works by creating a datagram server first, and then using
> Mario> set-process-datagram-address to set the destination. The server process
> Mario> can now be used to send UDP as well. However, I am seeing lost incoming
> Mario> packets. According to tcpdump, the reply is clearly there, but the
> Mario> process filter only seems to pick it up 1 out of roughly 4 times.
> Mario> Weird.
>
> Hmm, I have a patch somewhere to allow setting the sending port
> directly, Iʼll see if I can find it and resurrect it.
OK. However, we'd also need a way to get the listening port of a server
process with :service t. At least I haven't seen a way to query the
listening port yet.
> Having said that, this sounds like it might be a bug (although I
> haven't checked if the emacs code supports sending from a datagram
> server like this).
It does works, and also flawlessly. The weirdness I saw was due to a
coding-system issue, `osc-make-server` did not set :coding 'binary,
which is now fixed.
> Could you open a bug with M-x report-emacs-bug with your emacs
> version, and sample code?
I'd rather not, since this behaviour is actually wanted.
It is the only way I have to communicate with a certain external program
directly from elisp. scsynth always replies to the sender port...
To reproduce, all you need is create a datagram server, and set the
datagram-address to the desired destination. You can now receive
datagrams, and also use process-send-string to send to the desired
destination.
--
CYa,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UDP: Send and receive on same port?
2021-03-30 21:03 ` Mario Lang
@ 2021-03-31 9:14 ` Robert Pluim
0 siblings, 0 replies; 5+ messages in thread
From: Robert Pluim @ 2021-03-31 9:14 UTC (permalink / raw)
To: Mario Lang; +Cc: emacs-devel
>>>>> On Tue, 30 Mar 2021 23:03:58 +0200, Mario Lang <mlang@blind.guru> said:
Mario> Robert Pluim <rpluim@gmail.com> writes:
>>>>>>> On Tue, 30 Mar 2021 13:11:47 +0200, Mario Lang <mlang@blind.guru> said:
>>
Mario> Replying to self
Mario> Nevermind, it works by creating a datagram server first, and then using
Mario> set-process-datagram-address to set the destination. The server process
Mario> can now be used to send UDP as well. However, I am seeing lost incoming
Mario> packets. According to tcpdump, the reply is clearly there, but the
Mario> process filter only seems to pick it up 1 out of roughly 4 times.
Mario> Weird.
>>
>> Hmm, I have a patch somewhere to allow setting the sending port
>> directly, Iʼll see if I can find it and resurrect it.
Mario> OK. However, we'd also need a way to get the listening port of a server
Mario> process with :service t. At least I haven't seen a way to query the
Mario> listening port yet.
(aref (process-contact server :local) 4)
>> Having said that, this sounds like it might be a bug (although I
>> haven't checked if the emacs code supports sending from a datagram
>> server like this).
Mario> It does works, and also flawlessly. The weirdness I saw was due to a
Mario> coding-system issue, `osc-make-server` did not set :coding 'binary,
Mario> which is now fixed.
>> Could you open a bug with M-x report-emacs-bug with your emacs
>> version, and sample code?
Mario> I'd rather not, since this behaviour is actually wanted.
Mario> It is the only way I have to communicate with a certain external program
Mario> directly from elisp. scsynth always replies to the sender port...
No need, since it appears thereʼs no bug :-)
Mario> To reproduce, all you need is create a datagram server, and set the
Mario> datagram-address to the desired destination. You can now receive
Mario> datagrams, and also use process-send-string to send to the desired
Mario> destination.
Based on my (vague) recollection, for a server process you should be
able to pass in :service <port> anyway, so then thereʼs no need to
query for the port.
Robert
--
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-31 9:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-30 8:58 UDP: Send and receive on same port? Mario Lang
2021-03-30 11:11 ` Mario Lang
2021-03-30 15:23 ` Robert Pluim
2021-03-30 21:03 ` Mario Lang
2021-03-31 9:14 ` Robert Pluim
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.