I feel like I am missing something, all of the VITA49 examples seem to be using TCP or UDP.
Is there a specification or standard way of providing VITA49 packets for consumption?
Should I be performing the conversion and providing standard complex samples with Keywords?
I have looked at the rh.vita49 loopback demo waveform, and the MSDD device source, as well as the sourceVITA49 and sinkVITA49 component. All of these use either a tcp or udp packet stream.
If the standard is to use sockets to pass VITA49 packets, then where should I be looking to understand how to construct a device that adheres to the standard?
ANSWER
I was able to talk to an experienced REDHAWK developer.
There is no standard, per-se, with that said the approach I took was to make use of the socket.sourceVita49 asset. This asset consumes the Vita49 packets and inserts appropriate keywords etc based upon context packet. This required me update my device to support setting the hardware up to send Vita49 via TCP. This actually provided an easier solution for me, as I wasn't having to bust the VRT apart.
Examples:
The best example I found of consuming Vita49 was the MSDD device asset.
NOTE:
After reviewing the MSDD, it does not look to be too difficult to create a device that consumes VITA49 VRL,VRT packets and produce time stamped samples. I will be investigating that in the future.
Related
I am trying to evaluate the suitability of some different wireless interfaces for our project on 2xRaspberry Pi 4 and currently I’m evaluating Bluetooth Low Energy. Therefore I have written an Central and Peripheral device application with the Qt framework (5.15). In my case the latency time between messages is important, because of some security aspects. The message size of each command is around 80-100 Bytes. In one of my tests I have sent 80 Bytes commands every 80ms. Ideally the messages should be received on the other device in 80ms interval as well. For the LAN (TCP) interface this test works well.
For Bluetooth Low Energy I observed that messages, which are sent from Peripheral to Central work quite good and I measured no big delay. Different results I got for the Central to Peripheral direction. Here, I have received the messages in the interval of 100ms to 150ms really exactly. It seems that there couldn’t be a very big magic behind it, so is there any plausible explanation for this? I tested it with a Python script as well and I observed the same results. So it seems that the Qt implementation shouldn’t be the problem.
During research I found out, that the connection interval may influence this, but in Qt the QLowEnergyConnectionParameterRequest (QLowEnergyConnectionParameters Class | Qt Bluetooth 5.15.4) doesn’t work for me. Is there any command, where I can set the connection interval for test purposes at the command line on Linux?
Kind regards,
BenFR
It is possible that your code is slower from central to peripheral because WRITE is used instead of WRITE WITHOUT RESPONSE. The difference is that WRITE waits for an acknowledgement, therefore slowing the communication down, while WRITE WITHOUT RESPONSE is very much like how notifications/indications work in that there's no ACK at the ATT layer. You can change this by changing the write mode of your application and ensuring that the peripheral's characteristic supports WriteNoResponse.
Regarding changing the connection interval, the change needs to be accepted from the remote side in order for it to take effect. In other words, if you are requesting the connection parameter change from the peripheral, then the central needs to have code to receive this connection parameter change request and accept it.
Have a look at the links below for more information:-
How does BLE parameter negotiation work
Understand BLE connection intervals and events
The different types of BLE write
I am creating a REDHAWK device that outputs either 16 bit signed complex samples, or VITA49 packets. I want the device to be told which output type it should provide when it is allocated.
How should I go about this?
Should I just add a simple property to the front_end_tuner_allocation struct?
Some other recommended approach.
Is there an example that I might look at?
ANSWER
I was able to speak with an experienced REDHAWK developer.
Apparently in situations where the device is capable of producing different data flows then separate Device node specifications should be created. This means that the output port to be used will be dictated when the device is started and should not be configured at run time.
This actually makes sense given the life-cycle of the device and the component receiving the data.
This is how I rationalize it, the component won't be able to control the device until the allocate-capacity is performed. So there would be no way for the component/waveform to setup the device ahead of time.
I am looking at a project that requires the crafting of S1 Application Protocol (S1AP) packets. It is used between a eNodeB and MME of a 4G LTE network. S1AP is IP based and carried by the Steam Control Transmission Protocol (SCTP).
Does anyone have any idea if the current library for SCTP in Scapy is sufficient to do this, or I might have to define a new protocol?
My first goal is to emulate a connection (via a program) to a physical MME, anyone have any suggestions?
Thanks!
It depends on your development environment & requirement. In the case of linux/FreeBSD based development setup, the libsctp and ASN.1 tools should be enough for having S1-AP over SCTP protocol in the interface with the MME.
Coming to Scapy, note that it is based on python.
Scapy seems to have support for all types of SCTP chunks and so it must most probably be fine for your testing.
S1-AP protocol uses ASN.1. For generating S1-AP packets, you should integrate with ASN.1 for S1-AP encoding/decoding and use over scapy. Scapy provides support for ASN.1.
The S1-AP support extension should be done by you. The best part is that you can extend Scapy without having to edit source files for making your automated tool based on the type of requirement.
I'm looking to write my own multiplayer game server (most likely in nodejs) and I was wondering what protocol I should be using to transfer data? Are Datagrams the norm to send information (i realize they don't confirm delivery like HTTP, that can written on top of the protocol)? Any suggestions of performant proven systems would be a real help.
I guess I'm looking for successful techniques in handling the data transfer quickly and effectively (maintaining state on the server and scaling are a separate issue that I have a solid understanding of).
I'm looking to initially support desktop/mobile games (MacOS, iOS, and Android).
For all your protocol needs take a look at socketIO.
Basically your best solution is to rely on websockets which are TCP sockets. socketIO is just a nice cross-browser compliant abstraction.
Either you use standard long pulling techniques or html5 websockets. There is no access to UDP for browser <-> server.
There is a technology that is called RTMFP that Adobe introduced in the latest version of Flash (Flash 10). It allows you to do P2P connection and transfer data directly from a client to an other client without passing by the server. On top of that, it's using UDP to transfer data. I believe that this was originally designed to do video and audio streaming, but you can use it to pass data around.
However the main downside on this technology is the mobile since most of them don't support Flash. In this case you can use Socket.IO and use the server as a router of information as a fallback.
If you want to build your application in Javascript, you can still use it by bridging the functionnality to Javascript. If you want to take a look at a simple version of a bridge, you can take a look at this github project (I am the author).
As a C++ developer of Massive Multiplayer games for 10 years, I can tell you that most of your more advanced games, such as ones in which I was involved (Legends Of Kesmai, Magic: The Gathering Online, Airwarrior II, AVP, NTN Triva) to name a few, TCP is used for most communication simply because you need an ACK / NACK to be sure the data was received from the client. That is not to say UDP doesn't have it's place. In Legends we wrote the the protocol code to use UDP for out of bandwidth delivery of data which wasn't imperative that it be received in proper packet order and complete. Use UDP when you want to do things like update graphic files in the background while the user is playing, etc. This type of delivery is often used for such purposes and allows your TCP packets to arrive as required by your server.
I'm looking to a design a protocol for a client-server application and need some links to some resources that may help me.
The big part is I'm trying to create my own "packet" format so I can minimize the amount of information being sent. I'm looking for some resources to dissect their protocol, but it seems some completely lack packet design, such as SMTP (which just sends strings terminated by CLRF). What are the advantages/disadvantages of using a system like SMTP over a system that uses a custom made packet? Couldn't SMTP use only a couple bytes to cover all commands through bit flags and save bandwidth/space?
Just trying to get my head around all this.
True, but SMTP wasn't particularly optimized for space, nor is it a packet-based protocol. It sits atop TCP, and uses the stream functionality of TCP. You need to decide what is desirable in your protocol: is it performance sensitive? latency? bandwidth?
Is it going to need to run as superuser? If not, you'll probably want to use UDP or TCP.
Are you going to need guarantees on delivery? If so, TCP is probably your best option, unless you are dealing with fairly extreme performance or size issues.
Few protocols these days design individual packets, though many do send very specific data structures across the wire using TCP, or, less commonly, UDP.
If you want to really optimize for space or bandwidth, consider condensing your data as much as possible into individual bits and byte, and defining and packing structures to send it across TCP. Modern network adapters are so optimized for TCP anyway, that there is often little advantage to other strategies.
First of all, are you about to implement an enhanced transport protocol (like RTP on top of UDP) or an application protocol (like HTTP/SMTP)?
There are several things you should think about in both cases concerning your design of the protocol or the demands of your application:
Stream based or packet based,
unidirectional / bi-directional,
stateful and sessionful or stateles,
reliable or best effort,
timing demands,
flow/congestion control,
secure or plain.
Towards an application layer protocol, you should also think about:
Textual or binary data, mapping of application data to network data units/packets, security demands and integrity, etc.
SMTP, HTTP and other TCP based protocols do not concern themselves with packet design because they are stream based. So it makes more sense to talk about protocol design.
As for why use text based protocols vs binary protocols...
Readability of the protocol by packet sniffing programs like Wireshark is very useful.
Also it is often very useful to be able to simply telnet into your port and be able to communicate with the server by specifying plain text.
Also with a protocol like HTTP the actual resource is usually the payload of the communication, the resource can be in binary or any other specified format. So having just the headers and status in plain text is not a bad thing.
TCP is a stream based protocol, not packet based.
Using text with lines makes ad hoc debugging a lot easier
Using text with lines makes it possible to exercise your protocol with telnet