This is my .proto file
syntax = "proto3";
package helloworld;
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
// Sends another greeting
rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
I declared service and messages here. And I made cc file and header file by protoc.exe
I followed gRPC c++ Tutorial, and i wrote greeter_server.cc
But geeter_server.cc file can't read service Greeter. But it can read variable of Messages
What is the problem?
I included header file well, And i searched google but i can't find answer
help me please
Related
I'm trying to use libmosquitto to make a request (publish to a 'test/topic' topic) and I want to get a response based on the client (sender) id. So that means the client will publish to 'test/topic' and it will automatically subscribe 'test/topic/<client_id>'
The server has already subscribed on 'test/topic' and when it becomes the message, it will send a response (publish) to 'test/topic/<client_id>', which the client subscribed to receive that response in the first place.
The challenge here is how do I get the <client_id>, right. I already done this in python and js, where the client will send metadata or properties in the payload, which the server can unpack to get the client_id. However, I'm using C++ now and it's frustrating because I can't figure out how to get these properties.
Here is an example of how to do this in python. I just want to do the same with c++
I'm using the libmosquitto as I mentionned. I don't even have an example to show because I didn't find how to do this. There is literally no example on how to do this with the mosquitto c++ lib (which is confusing since mosquitto is a famous lib I guess).
I hope someone had a similar problem or can post an example for c++ and mosquitto lib. Thanks in advance.
When in doubt, look at the tests:
const char *my_client_id = ...;
mosquitto_property *proplist = NULL;
mosquitto_property_add_string_pair(&proplist, MQTT_PROP_USER_PROPERTY, "client_id", my_client_id);
mosquitto_publish_v5(mosq, &sent_mid, "test/topic", strlen("message"), "message", 0, false, proplist);
mosquitto_property_free_all(&proplist);
Since you asked in the comments, you can retrieve these properties from published messages by first setting an on_message callback using mosquitto_message_v5_callback_set and the implementing it like so:
void on_message(struct mosquitto *mosq, void *obj, const struct mosquitto_message *message, const mosquitto_property *props) {
std::string topic{message->topic};
if (topic == "test/topic") {
const char *client_id = nullptr;
mosquitto_property_read_string_pair(props, MQTT_PROP_USER_PROPERTY, nullptr, &client_id, false);
if (client_id) {
/* client_id contains a client id. */
}
}
I'm using GRPC to remote call the database and store the data in the response format given by the .proto file. My program is based on CPP programming:
// similar .proto file
message FinalResponse
{
repeated IntermediateResponse finals = 1;
}
message IntermediateResponse
{
string name = 1;
InitialResponse foo = 2;
}
enum InitialResponse
{
COUNTRY_UNKNOWN = 0;
COUNTRY_INDIA = 1;
}
For my case, the request message is empty(no field) so didn't displayed here. I went through the protocol buffer documentation and tried this:
// firstly called the database and stored the intermediateResponse in a vector<pair<string, string>> data
//pseudo-code below:
FinalResponse result;
for cur_data in data:
{
IntermediateResponse *interResp = result.add_finals();
interResp->set_name(cur_data.first);
interResp->set_foo(static_cast<InitialResponse>(cur_data.second));
}
When I'm executing this, there is no syntax/build error but grpc status is saying we didn't get any response back:
ERROR - (12) No message returned for unary request
I want to clarify that service was running from the server side and client is able to detect that service as well, I'm suspecting that maybe the returned data through database is not properly stored in the response message and so GRPC is deducing that we didn't get back any data. Please suggest some work around for this?
Looks like it was the server side issue probably, now with the same changes, it is able to store the response properly.
Maybe server went down for some time and returned error.
I'm trying to receive messages from a published topic in C++. I know in Java it's just client.on('message', (topic, message)). But I couldn't do something like that in a C++ library. How can I do it?
As of now, I've got everything set up and am subscribing to the topic I'm interested in, but I'm stuck on how to fetch the message from there.
MQTTClient client;
void mqtt_subscribe(std::string const &topic) {
if(!mqtt_initialized) {
return;
}
MQTTClient_subscribe(client, topic.c_str(), 1);
}
Your client is connected to nothing, so you have to connect first by calling the Mqtt client constructor of the mosquitopp library witch is the top level cpp interface.
I have a C++ gRPC client and Golang gRPC server. For a bi-directional stream, when the client wants to close the stream, it blocks forever on the call to Finish().
This only happens if there is no error, that is, the server rpc function returns nil. If the server was written in C++, I understand it would have returned Status::Ok.
If the Golang server returns a non-nil error, then the Finish() function returns as expected. The problem occurs only in the case of no error.
Example:
.proto
service StreamTest {
rpc Get(stream StreamCommand) returns (stream Result) {}
}
message StreamCommand{
string cmd = 1;
}
message Result {
string res = 1;
}
.cpp
std::unique_ptr<ClientReaderWriter<StreamCommand, Result>> readerWriter;
bool Get(Result &res) {
return readerWriter->Read(&res);
}
bool CloseClient() {
StreamCommand cmd;
cmd.set_cmd("stop");
readerWriter->Write(cmd);
readerWriter->WritesDone();
Status status = readerWriter->Finish(); // <------ BLOCKING
return status.ok();
}
I have tested the server with a Golang gRPC client and it works fine. Should the server return something other than a nil error? Should I report this as a bug?
Any help is appreciated! Thanks!
I am not familiar with Go, but I know c++ layer. Can you run the client with GRPC_VERBOSITY=debug and GRPC_TRACE=api? That would give more insight into the problem.
I am new to web services. I have written a rest web service which creates and returns pdf file. My code is as follows
#Path("/hello")
public class Hello {
#GET
#Path("/createpdf")
#Produces("application/pdf")
public Response getpdf() {
synchronized(this){
try {
OutputStream file = new FileOutputStream(new File("c:/temp/FirstPdf5.pdf"));
Document document = new Document();
PdfWriter.getInstance(document, file);
document.open();
document.add(new Paragraph("Hello Kiran"));
document.add(new Paragraph(new Date().toString()));
document.close();
file.close();
} catch (Exception e) {
e.printStackTrace();
}
File file1 = new File("c:/temp/FirstPdf5.pdf");
ResponseBuilder response = Response.ok((Object) file1);
response.header("Content-Disposition",
"attachment; filename=new-android-book.pdf");
return response.build();
}
}
}
If multiple clients try to call the web service simultaneousy , Does it impact on my code?
I mean , if client A using the web service and at the same time if client B tries to use the web service will the pdf file gets over writted.
If my question is not proper,Please let me know
Thanks
As you are writing the file to the hard disk multiple calls to the service will cause the file to be overwritten or cause exceptions where the file is already in use.
If the file is the same for all users then you would only need to read the file rather than write it every time.
However if the file is different for each user you might try one of the 2 following options:
You could build the file in memory and then write the binary response directly to the response stream.
Alternatively you could create the file using a unique name, this could be a GUID or a random number this would ensure that you never have a clash between the multiple calls arriving at the server.
I would also ensure that you remove the files