I'm new in Wowza. I need to know whether there is any mechanism to identify the start and end of a stream through wowza. This service will monitor each of the inbound ports that are currently bound to wowza engine and then try to create a notification on two events.
1. Start of UDP packets in to the port, the event should trigger everytime a new port receives packets.
2. End of UDP packets in to the port. If no packets hit the given port for a certain period of time, this event will be triggered.
Wowza has modules and there is one that makes something similar: https://www.wowza.com/forums/content.php?171-How-to-use-IMediaStreamActionNotify2-to-monitor-live-streams-%28ModuleStreamWatchDog%29
the source is public so you could modify to match your needs. Java skills required.
the other way is to call the rest api periodically and check for new streams.
Related
I'm new to MQTT: but I have got some basic Python programs working where sensor readings can be published to a particular topic: and other clients can then subscribe to get the temperature on a event-driven basis.
But when it comes to sending commands; I'm a little stuck on the best to do this.
So for example: take a 'countdown timer' connected to mqtt.
This timer has two states: 'stopped' and 'started'.
It will initialize itself into the 'stopped' state and wait for a 'start' command; and then will count down; publishing the current countdown to a topic.
When the countdown reaches zero; it will switch its state to 'stopped' again, and wait for another 'start' command.
If it receives a 'stop' command (over mqtt); it should also go into the 'stopped' state.
So perhaps I could create topics something like:
countdown_timer/command
countdown_timer/state
countdown_timer/value
And the countdown device could subscribe to 'command' and react by publishing to 'state'. ('stopped' or 'started'?)
But should the client somehow 'consume' the 'command' topic value once it has processed it ?
Or would it better to have something like:
countdown_timer/send_command
countdown_timer/command_result
Where the controller would send a command, the subscribed-device would carry-out the command and put 'ok' or 'error' on the 'command_result' topic ?
In general, both approaches that you describe are valid MQTT patterns. You choose what is most appropriate for your application. Here are some comments:
For your countdown timer, I would go with your first suggestion. But for other applications, other approaches may make more sense.
If you write to countdown/state and countdown/value, you may want to make these publish messages retained. This will ensure that newly subscribed clients will immediately receive the latest value.
If your countdown timer process is always running, then you don't need the retained flag for countdown_timer/command --- but sometimes it makes sense when a server process can fail, restart and reconnect to just continue with the last command.
The send_command and command_result pattern is common for MQTT when one client speaks to one server and receives one answer for each question. This doesn't seem to fit this current example well: You don't have one specific answer to respond to for each command.
Here is another pattern for client-server applications: The server subscribes to one channel server/command and each client subscribes to a separate channel: client/1, client/2, client/3 etc. When a client sends a command to the server, it includes its client id --- and the server responds on the corresponding channel.
A modification of this pattern is to use independent channels for command queries: service/1, service/2 etc. The first clients publishes to service/1 and subscribes to client/1. The second client publishes to service/2 and subscribes to client/2. The server subscribes to service/#, extracts the client id from the topic name of the received message and responds to the corresponding client channel.
You see: There are many valid patterns for MQTT --- at one hand, this flexibility is an advantage. At the other hand it puts the responsibility on you to choose wisely.
When creating a peer to peer audio connection using webRTC, the STUN server we use will return the public IP if a user is behind a router. Now in the ICE objects, I can see that the rport is always something between 50000 and up.
Is there a way to use a specific port so that the user does not have to open all those ports?
Is there a way to use a specific port so that the user does not have to open all those ports?
I think you have a misunderstanding. The whole point of STUN and ICE (including its WebRTC derivative) exists to avoid anyone having to open a port on their NAT. Instead, STUN and ICE dynamically open the port.
Here's how it works (in a really brief description).
Client opens a socket on a random port (e.g. 50001)
Contacts STUN server using that socket to discover the external IP:port mapping for this socket. (e.g. 192.168.1.2:50001 maps to 1.2.3.4:50001). Ports don't necessarily have to match between internal and external addresses, but they usually do, so I'll keep with that for this example.
Through an external mechanism (SIP, XMPP, Jingle, cups with strings), the candidate address list of both nodes are exchanged. This includes all known internal and external addresses collected (e.g. 192.168.1.2:50001 and 1.2.3.4:50001).
Using the same socket opened in step 1, both sides send (STUN) messages (UDP packets) directly between each other. The first pair of messages may be blocked by the router/firewall. But because one side initiated an outbound packet to the remote address, subsequent packets from that address are allowed back in. This is called the "hole punching step". Hence, the port is dynamically open without the router needing any specific configuration.
Hope this helps.
You can't programatically unless you are using webrtc API in your own application. The browser will pick specific local ports from a range locally; and then it will inform you about them in the SDP and ICE candidate information.
STUN server only helps discover whether a client is behind a NAT/firewall; and then ICE uses this information in establishing peer-to-peer connection.
I have heard somewhere there might be a way to control that port range via Chrome policy templates(used by enterprises to restrict Chrome settings) - http://www.chromium.org/administrators/policy-templates. It might worth looking into...
I want to implement a demo application to listen data via TCP/IP.
Data Transmitter will transmit a series or ASCII char or a series of string all the time. It feeds data into TCP/IP address (eg. 127.0.0.1:22) This could be a GPS transmitter.
I want to implement a demo application for receiving data by clicking the start button and listening to the data via TCP/IP and display it accordingly.
Correct me if I am wrong, I don't think I can use Server/Client server for this purpose. I tried to create a client application with TIdTcpClient, it receives only one time data. I don't think Indy has a TCP listening component.
Thanks in advance.
If you wanna monitor network comunications between some device and some other program on your computer using of TIdTCPServer won't work. Why? Once Indy will read network data it will mark it as processed and delete it from network buffer. So that data probably won't even reach to the other program on your computer. Workaround for this is that you design your application to actually work similar as network bridge. Your application listens to the data on one port and then forwards that data on another port on which the other program is listening. But the main problem is that you have to make this to work both ways.
What you need is somekind of a component which is able to peek at the network data but don't interact with it. This is usually done on driver level.
Now if it is not abolutely necessary to have such functionality in your own software but you are only interested in getting the data I recomend you try Wireshark (http://www.wireshark.org/). Wireshark is a verry powerfull freware software which alows you to monitor all netwrok traffic on basically all protocols without causing any interuptions. In order for this software to work it instals special driver which serves for intercepting the network data.
Maybe you would want to use same driver in your application if this functionality needs to be in your application.
Based on your diagram I think that your implementation could also be based on a message-oriented middleware, using a message broker which receives the GPS transmitter or other data.
The message broker would then store the data internally and forward it to all interested clients which are connected. A typical messaging pattern in this case is a "Topic", which broadcasts the messages similar to a radio station.
So the middleware will ensure that the information will be collected (optionally also persisted to disk) and then guarantees the delivery to the receivers. This can be done even in a way where receivers which have been off-line for a while still receive the GPS messages created while they where not listening ('retroactive consumers').
There are many popular free open source message brokers, and most of them also can be used with Delphi.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
I have used poll in the past where a server has multiple connected file descriptors, but how does one use poll in the case where one wants to listen in to various multicast groups? From my understanding this would entail multiple upd sockets wanting to call recvfrom after joining a group but never connecting these socket..would one just poll on these descriptors anyways and then call recvfrom when the events trigger? Is there any small simple example of this on the web?
Thanks
The polling is exactly the same - you wait for any of your several sockets to become readable, figure out which one is, and then call recv(2) or whatnot. The difference from TCP is that each read on UDP socket de-queues exactly one datagram, so this is a bit easier.
The sockets you put into poll set are usually set to non-blocking, in which case you'd need to handle EWOULDBLOCK error from recv(2).
Also remember that UDP is not reliable, so if you are not consuming those datagrams fast enough they fill socket receive buffer and kernel starts dropping them.