I am writing a client and server library for local IPC. Client and Server both has classes which make use of named pipes to send data between two processes. I want to write functional test to test client-server libraries.
My idea is to create client in functionaltest, mock a server in a separate executable, launch server using CreateProcess and send data to server. But in such case I won't have any control on mock server and checking data sent by client cannot be validated on server.
Can anyone suggest me how to write client server functional test so I can validate functionality of both modules.
Here are couple of tests I'm thinking of,
1. Client connects to server.
2. Client disconnects gracefully from server.
3. Client sends some data to server.
4. Server disconnects client connection selectively.
5. Server shutdown/client shutdown
6. etc.
Thanks,
Ajay
For testing, run the client and server code in the same process using separate threads.
Related
I am following the ListFeatures() example in this tutorial: https://github.com/grpc/grpc/blob/v1.31.0/examples/cpp/route_guide/route_guide_client.cc
My server is in Java and my client application is in c++.
I have both the server and the client running locally. What I am observing is that my application crashes when I try to read the stream response via `reader->Read(&feature). I can verify that the server receives the api call and is sending responses back. I am also able to successfully hit the server from bloomRPC.
Any ideas why I can't receive responses in my c++ client application?
Much appreciated!
I had this problem when the context used to create the ClientReader fell out of scope. The context needs to be persistent while the ClientReader is in use.
I have a websocket client in python implemented using tornado.websocket.
WebSocketClientConnection
which connects to a server at remote end and communicate over websocket. Earlier I had implemented the ping/pong like feedback mechanism at application layer to ensure if the remote endpoint is still responsive.
I just recently updated my tornado package and I came across the ping_interval in WebSocketClientConnection. I removed the old ping/pong mechanism at application layer and added this ping_interval in my implementation.
After this updates the websocket is getting closed after the mentioned ping_interval timeout. The server at remote end handles the ping at transport layer and respond accrodingly.
currently I have not implemented the ping method so should I have to implement ping method for WebSocketClientConnection?,
should I have to send any data in ping method?
do I have to implement any method to handle the response send by remote server for the ping request?
No, It's implemented by default.
You may but don't have to.
I assume that by response you've ment pong. If you're using ping_interval you don't have to process pong, but if you're sending pings manually you have to control timeouts by yourself so you have to process pongs by implementing tornado.websocket.WebSocketClientConnection.on_pong method.
I have a gRPC server written in C++ which is running on a server say Gabroo
Gabroo:~/grpc/examples/cpp/stream_server$ ./stream_server
DB parsed, loaded 1 features.
Server listening on 0.0.0.0:50051
The client is running on same server and exits after receiving the message.
Gabroo:~/grpc/examples/cpp/stream_server$ ./stream_client
DB parsed, loaded 1 features.
-------------- GetFeature --------------
Found feature called PatriotsPath,Mendham,NJ07945,USA at 40.7838, -74.6144
Found no feature at 0, 0
Now if the server wants to send a message to client but client is not listening for any message is there some configuration needed so that client is in listen mode continuously for stream messages from server.
If it is not available inbuilt would infinite loop and checking for message every 1 secs be a good approach. I personally don't like this approach.
Regards !!!
This can be solved using RPCs of different arity. Most generally, you could define a bi directional stream between client and server. That way, if a stream is open, the client will be listening, ready to receive messages from the server.
If you use case is more specific, and you only need on client RPC per stream, then you could consider using Server streaming RPC.
I've got server running in background and a program which should display data from server. I want to somehow launch method in my program from server. So server should be a sender, but how to do it ?
There is no reason why a server can't also be a client, just implement the interfaces from both sides and you're good.
The main thing to worry about is deadlocking: if you have a single threaded program which is waiting for the reply of the server, then it will not handle the request that the server sends, so the server is stuck and will not send a reply to the program.
This can be solved by starting the server implementations on different threads and letting them not block on the client thread.
Even better is to avoid having a server send back requests before sending replies, but cascading requests (forward requests to more specialized servers) should be no problem.
I want to develop a Qt5/C++ client-server application using remote procedure calls (RPC).
Idea:
The server listens for incoming connections of multiple clients.
Clients offer a set of procedures/services the server can call in order to collect data from clients and inform other clients about changes.
And here is the catch:
The RPC libs i've seen so far seem to expect the server to offer a service the clients may call. But I want to do the opposite. Clients should offer services the server may call.
The direction is important, because I want to enable port forwarding on the server side only, not on the client side.
The libs I've checked are:
QtRpc2 (https://github.com/brendan0powers/QtRpc2)
grpc (http://www.grpc.io)
Questions:
Is there a reason these libs offer services on server side only?
Did I maybe only miss that part in the documentation?
Is there an RPC lib that does offer client side service offering?
gRPC supports bidirectional streaming, which may meet your needs.
Clients can open a long lived connection to a server, and then the server can "call" the clients by sending responses on the stream.
The client can respond by sending another message on the stream.
http://www.grpc.io/docs/tutorials/basic/c.html