I would like to see/detect if something connects to my virtual midi port.
So I create a port:
snd_seq_create_simple_port(handle, "my port",
SND_SEQ_PORT_CAP_WRITE|SND_SEQ_PORT_CAP_SUBS_WRITE,
SND_SEQ_PORT_TYPE_MIDI_GENERIC);
Now before I start producing MIDI events on that port, I would like to know if someone connected/mapped that port (e.g. using aconnect or patchage or so).
Subscribe to 0:1 (SND_SEQ_CLIENT_SYSTEM:SND_SEQ_PORT_SYSTEM_ANNOUNCE) to receive events about subscriptions. See the output of aseqdump -p 0:1 for examples.
Please note that it is possible to send events directly to a port without a subscription.
Related
I have a PC A where LTTng tracing is running with live view
lttng create trace-session --live
# Traces will be output to tcp4://127.0.0.1:5342/ [data: 5343]
Another PC B is directly connected with A with a Ethernet cable. At the same time, B is connected to a local network.
Now how can I view the live trace events from a third PC C, which is in the same local network as B, for example with
babeltrace2 "net://${B_IP}/host/${B_HOSTNAME}/trace-session"
I ran the following command on PC C, to make a tunnel to PC *A.
ssh -L 5342:${A_IP}:5342 -N user_name#${B_IP}
However, it seems not to have worked. I would like to ask:
What have I done wrong here?
What is the standard way to "forward" LTTng live tracing events to be viewed by babeltrace2?
Babeltrace2 connects to lttng-relayd using the live port of the lttng-relayd process not the data and control ports.
When the command line report the following:
# Traces will be output to tcp4://127.0.0.1:5342/ [data: 5343]
It means that the lttng-sessiond and lttng-consumerd process will communicate with a lttng-relayd process listening on the 127.0.0.1:5342 for control message and 127.0.0.1:5343 for trace data exchange. A viewer, in this case Babeltrace2 can connect to the live port of a lttng-relayd process to stream live session. You can take a deeper look at the component graph here.
The default live port is 5344 and the default behavior for the lttng-relayd process is to bind on all interfaces to listen. Naturally Babeltrace2 also default on using that port if none is specified to communicate with the lttng-relayd process.
See the man page of lttng-relayd for more details.
What have I done wrong here?
In your scenario you need to tunnel the 5344 port. Note that I'm not versed in ssh tunneling so I cannot validate the ssh approach here.
ssh -L 5344:${A_IP}:5344 -N user_name#${B_IP}
What is the standard way to "forward" LTTng live tracing events to be viewed by babeltrace2?
Babeltrace2 and lttng-relayd use TCP for communication. Hence, all TCP "forwarding" methods are acceptable here. As you probably noticed, LTTng does not encrypt communication and trace data in any way. I would say that using a ssh tunnel is appropriate here if you need to move data across non-trusted network.
This is for a school project so I need to use UDP Broadcast.
I am building a P2P app that uses only port 5000 over UDP. I need to send a discovery broadcast packet to all clients in my network.
Normally the app will be used over Hamachi but for the purpose of developing I would like to use the simplest fastest network environment so I would like to test multiple instances locally.
I discovered that it is possible to use 127.0.0.1 127.0.0.2 etc as IPs for my local instance. (Actually tested with ips from 1 to 6 and sending messages at random to each other)
I now need to use the SAME port 5000 but do a broadcast UDP
When I invoke ifconfig on the loopback interface I do not see the BROADCAST option.
Since apparently it is impossible to add the BROADCAST option to the loopback interface, what is the easiest way to have:
1 ip address per instance
same port
running locally
Should I consider using Docker or VM or some network simulator for this purpose?
If you only want to broadcast to all clients, maybe multicast is enough for you. And this can fullfill all the three need you mention. Here is the definition, and here is a little example may help you.
Can use tcpdump to capture socket data ?. Since , at the listener end i'm freqyently getting some additional info along with send message.
In between client and end listener , one edge server and one application server is running, not sure at which point that additional info is being added. To troubleshoot, I tried to use tcpdump to capture the socket data. But I couln't capture it.
Can someone please tell me, tcpdump is not fit to capture socket data?. if so, then which one is correct one to do this.
Note: I'm Using CentOS
tcpdump can capture data base on port as following:
tcpdump tcp port 23 and host 210.27.48.1 -w temp.pcap
If you still can't capture any data, you can capture data for the interface to ensure your tcpdump is working:
tcpdump -i eth1 -w temp.pcap
ps: If your client and your server are on the same machine, you need to capture the lo interface.
I have an application (essentially a game) that is broadcasting game state data via UDP to many connected clients on a private LAN.
UDP works fine for broadcasting game state. Not having to configure the clients is important for this app. The client just read the UDP datagram stream and build up state as it goes.
But now I need the clients to reliably download a few pieces large data payload from the server. TCP is way better then UDP for that.
But we still rather not have to configure each and every clients with the host info.
It would be better to just embed an service advertisement in the broadcast UDP stream and then have each client see the advertisement and connect to the TCP host with no extra configuration on the endpoints.
Is there an standard way, or better, example code of advertising a TCP service via UDP. Preferably in C++.
The client needs to know the IP and port of the TCP server, that is all. If you can embed that info into your protocol it will work.
Actually, the UDP clients probably know the IP already because the UDP packets have a sender IP. Maybe this fact can help you.
One of the options here (maybe not for just a game but for some "enterprise" service) is setting up SRV records in local DNS.
I have an FPGA device with which my code needs to talk. The protocol is as follows:
I send a single non-zero byte (UDP) to turn on a feature. The FPGA board then begins spewing data on the port from which I sent.
Do you see my dilemma? I know which port I sent the message to, but I do not know from which port I sent (is this port not typically chosen automatically by the OS?).
My best guess for what I'm supposed to do is create a socket with the destination IP and port number and then reuse the socket for receiving. If I do so, will it already be set up to listen on the port from which I sent the original message?
Also, for your information, variations of this code will be written in Python and C#. I can look up specific API's as both follow the BSD socket model.
This is exactly what connect(2) and getsockname(2) are for. As a bonus for connecting the UDP socket you will not have to specify the destination address/port on each send, you will be able to discover unavailable destination port (the ICMP reply from the target will manifest as error on the next send instead of being dropped), and your OS will not have to implicitly connect and disconnect the UDP socket on each send saving some cycles.
You can bind a socket to a specific port, check man bind
you can bind the socket to get the desired port.
The only problem with doing that is that you won't be able to run more then one instance of your program at a time on a computer.
You're using UDP to send/receive data. Simply create a new UDP socket and bind to your desired interface / port. Then instruct your FPGA program to send UDP packets back to the port you bound to. UDP does not require you to listen/set up connections. (only required with TCP)