well..
I'm from a non-English speaking country.
I need to use DTCP-IP in my work, which the full-name is Digital Transmission Content Protection over Internet Protocol.
What confused me is the word "over".
The network model is:
-------------------------------[ The Transportation Layer ]
[ Header of Internet Protocol ][ Content from The Transportation Layer ]
The problem is
which part should be handled?
and how to interpret the word "over" in this field?
Thanks.
Over in this context means "using".. You watch a television show OVER the television cable, you make a phone call OVER the phone line, so it's a protocol that protects content as it transmits it across the internet.
Related
Are there any Wireshark gurus?
I am debugging an issue on my home Zigbee network. I have a sniffer dongle and I can catch all the packets transmitted. Since my network has ~40 devices, the air is quite cluttered with packets I am not really interested in. I am looking for a ways to filter uninteresting messages
Questions:
Is there a way to filter out messages related to IEEE protocol (various Data Requests, and Acks), while leaving only upper layer messages (Zigbee, Zigbee HA)?
Is there a way to assign human readable labels for the devices on the network? e.g. 'Coordinator' instead of 0x0000, or 'Light Switch' instead of '0xc83a'?
I would propose making your own filters (whoah, relax, we are not animals, we do this the smart way) ... go to Statistics > Protocol Hierarchy, the panel should show you all the traffic by protocols. Then just identify which protocols you do not want to see, mark them (one by one), right-click and Prepare as Filter > ...and not Selected (to prepare a filter to exclude the highlighted protocol). Sadly wireshark does not allow you to select multiple protocols to exclude at once. After this simply save your filter and reuse it as much as you like
What you are trying to do is Name resolution. This is done via configuration files, more specifically ethers and hosts
I am working on Adaptive Autosar project, where input data (video) captured from camera sensor needs to be transferred from client machine to server machine, which runs object detection algorithm.
someIP (service oriented middleware over IP) protocol is used as middleware .
Is it possible to share video file using SomeIP protocol?
If No, what is other method to share the video frame?
Thanks & Regards
Astha Mishra
The problem would be, that you would need a very good connection between the two ECUs, and I doubt that even with Ethernet, you can pass the data that fast to keep a certain performance. It might make sense to preprocess the data, before transmitting it somewhere else.
Transmission would be done rather as a byte stream with a streaming protocol, e.g. SomeIpTp, you might think about compression if possible. UDP instead of TCP might be also a good idea, but consider the possible drawbacks of UDP.
Vector seems to provide some MICROSAR module called MICROSAR.AVB module for Audio/Video-Briding.
But make sure, the sensor/camera does not provide the data faster than it can push it out over the network.
i want to send data over wireless medium in the range of 6 kms.
what is the best method to achieve this. Is this Wi-Fi or some other method.
Assuming you're talking line of sight, WiFi would be possible, with the kit needed costing around 300 euro or up. That is of course largely dependant on your requirements like throughput, influence of bad weather, budget...
This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx
When programs such as Skype streams video from a user to another and vice versa, how is that usually accomplished?
Does client A stream to a server, and server sends it to client B?
or does it go directly from client A to B?
Feel free to correct me if i am way off and none of those is correct.
Skype is much more complicated than that, because it is Peer to Peer, meaning that your stream may travel through several other skype clients, acting as several servers. Skype does not have a huge central system for this. Skype always keeps track of multiple places that it can deliver your stream to, so that if one of these places disappear (that Skype client disappears), then it will continue sending through another server/skype-client. This is done so efficiently, that you don't notice the interruption.
Basically , this is how its achieved.
1) encode video / audio using the best compression you can get. Go lossy compression and plenty of aliasing to throw away portions of video and audio which is not usable. Like removing background hiss
2) pack video / audio into packets and put a timestamp on them. The packets are usually datagrams.
3) send packets directly to destination. Use the most appropriate route. You dont have to send all packets the same way. Use many routes if possible. P2P networks often use many routes to the same destination
4) re-encode on the destination. If a packet is too old , throw it away. If packets are lost , dont bother about it since its too late.
5) join the video back and fill in the missing frames the best you can.