Is it possible to use google protocol buffers as the serialisation mechanism when only one end of the comms channel is using it?
ie given a client that needs to speak to some 3rd party server or hardware that communicates in some defined message byte structure.
is it possible to specify the exact byte structure to expect using the protobuf IDL? Or does protobuf use it's own byte packing format therefore both ends must speak using protobuf protocol?
If not protobuf is there some library that would achieve this?
No. Protocol buffers has a very rigid layout, that cannot be changed, and is unlikely to match the one you are using unless it is secretly using protocol buffers and just not advertising that fact. The encoding is documented here.
As for alternatives; that would depend hugely on what platform / language / framework you are using. It would not be unusual to find you have to write your own tools for talking the required protocol.
Related
I want to check if there is support for endianness(little endian/big endian) in plc4x modbus library to process the response based on that . I could not find any documentation or example on how to use if it exists.
So, request to same some links here if available.
Right now we currently don't support this, but we are aware of an option to fix this. Till now we haven't implemented any support for this mainly because none of our core contributors has access to such a Modbus device. If you have one particular device in mind, could you please name the Type an model or if you could provide us with such a device ... perhaps we can come up with an implementation.
Is there some direct way (without writing platform-specific code) to collect some entropy from underlying system?
Do you have any plans to add cross-platform entropy collecting mechanism? It will be very useful feature.
Our encryption support is all implemented via a cn1lib which isn't the latest and greatest either but it provides most of the basic stuff we need. We never went into that level of encryption/security when porting that library, if the native platforms support more secure randoms you can use a native interface to map to that and possibly also submit a pull request to the lib.
MTA Subway data (among other data) is formatted in GTFS-realtime. In order to convert the protobuf into a string representation I must run it through some Google protobuf tools using gtfs-realtime.proto. The only problem is that, as can be seen here, the gtfs-realtime-bindings are available only for
NET
Java
JavaScript / Node.js
PHP
Python
Ruby
Golang
Additionally,
We don't provide generated code for C++, use the official protoc compiler for that (from here or here)
None of these are Swift or Objective C. While there is an open issue/request for a Swift/Objective C version from 2016, I was wondering what I can do currently in order to do this. As of now, the only viable solution I see is to have a server parse the data and then GET the parsed data (JSON encoded?) from that server instead of directly from the MTA.
Here is the Google page for protocol buffers. I am not sure, but is there some way to use what is there to read the GTFS-realtime data.
Is that the best path forward? Are there any other possibilities?
As noted by Tony Laudig, having your app directly communicate with the MTA is a breach of their terms and conditions which you almost definitely would have had to agree to in order to get an api key.
Breaking terms and conditions is generally a pretty bad idea. In the case of this API, it seems like your key will be revoked.
Thus, I would not suggest using the library in Tony’s answer. Instead, do what you proposed:
Have a server parse the data and then GET the parsed data (JSON encoded? [—sounds good]) from that server instead of directly from the MTA.
Any of the languages you listed will do the job, it’s just a matter of which you’re most comfortable with.
There is an official library in Objective C for parsing Protobuf. You can compile classes from the GTFS-rt standard and the MTA extension .proto files.
It looks like your planned usage, having the app connect to the MTA directly, doesn't conform to the MTA terms and conditions:
In developing your app, you will provide that the MTA data feed is
available to others only from a non-MTA server. Accordingly, you will
download and store the MTA data feed on a non-MTA server which users
of your App will access in order to obtain data. MTA prohibits the
development of an app that would make the data available to others
directly from MTA's server(s).
I need a serial protocol for an embedded system that has some quirks. Right now it does YModem, but there are hiccups, so I thought I would try Zmodem or Kermit. Zmodem has both code and a clear enough implementation spec.
I can find nothing from which I can implement the file transfer protocol of Kermit from "scratch" (nor usable code).
There's source that isn't well organized and includes full terminal emulators and TCP clients, with all kinds of sections and options for every computer including antiques. E.g. C-Kermit 9.0. I'd spend more time refactoring it to extract just what I need than implementing it outright.
There is an abstruse mathematical paper that I find confusing since it doesn't talk about bits and bytes only something between a formal proof and pseudocode. (Proof.pdf - and it has theorems, proofs, and lemmas!). It claims to be some kind of specification. Maybe buried in there somewhere, but the same problem, I'd have to spend a while extracting the actual coding information.
I need some of the advanced features (full sliding windows), but the Embedded Kermit says it doesn't have those (though has some partial bits or hooks) but does have some other stuff I neither want nor need.
I don't think I would have any trouble writing Kermit from a real specification targeted to programmers as to what goes over the wire (content and timing), or better yet, a clean but full implementation.
I can't find either. Does anyone here know of one?
The kermit protocol was documented in the book Kermit, a File Transfer Protocol by Frank Da Cruz (Digital Press, 1987). There's an online document called Kermit Protocol Manual (1986), which I assume is an earlier version of the book.
Some of the optional features in the manual have never been implemented, and there are also some optional features that have been implemented but never found their way into the manual. If you're interested in these exotic extensions, you will need to browse through this archive of Kermit protocol discussions.
Is it possible to use Objective-C to broadcast audio using the Icecast protocol?
For Node.JS I've found the library nicercast which seems to work pretty well. Is there an open-source equivalent for Objective-C or do I have to implement the protocol myself?
If I'll have to implement the protocol myself, then what do I need to know?
From the Node.JS Library I've seen that essentially, the server broadcasts an MPEG-stream using a normal web server and just sending the raw data over to the client.
Does this MPEG stream contain the metadata or do I have to send it separately?
Thanks in advance
Why not stream to an Icecast server instead? It's small enough to even run on embedded devices without big issues.
The nicercast implementation is nowhere close to being "Icecast compliant" as they claim.
If you want to know why, look at the Icecast sources or e.g. the supported formats.
I know it's en vogue to reinvent the wheel, badly and incompletely. But I'm at least going to remind you that it's not necessarily a good idea.