I would like to know what is the best choice for a connection client-server.
I have to say I'm working with boost, and I'm not in trouble with how to to that, but when, for send, receive and connect. Could someone help-me please?
Related
I write a peer-to-peer messenger. After the two peers have established a connection, they want to know whether the other has sent him a message. If not, it sends a message itself. So I need a function that tells me how many bytes are still to be read on the socket. I looked in the documentation, but didn't find it.
When I was just asking the question I was redirected to Ruby TCPSocket: Find out how much data is available. However, I use an SSL socket and it doesn't seem to have .ready?.
Does anyone know a version of the function for the SSLSocket?
I would be very happy about answers!
I am wondering the best practice for long lived GRPC calls.
I have a typical Client --> Server call (both golang) and the server processing can take up to about 20-30 seconds to complete. I need the client to wait until it is completed before I move on. Options that I see (and I don't love any of them):
Set timeout to absurd length (e.g. 1 min) and just wait. This feels
like a hack and also I expect to run into strange behavior in my
service mesh with things like this going on.
Use a stream - I still need to do option #1 here and it really
doen't help me much as my response is really just Unary and a stream
doesn't do me much good
Polling - (i implemented this and it works but I don't love it) - I
do most of the processing async and have my original GRPC call
return a transactionID that is stored in Redis and holds the state
of the transaction. I created a different GRPC endpoint to poll the
status of the transaction in a loop.
Queue or Stream (e.g. Kafka Stream) - setup the client to be a
listener into something like a Kafka topic and have my server notify
the (Queue || Stream) when it is done so that my client would pick
it up. I thought this would work but seemed way over-engineered.
Option #3 is working for me but sure feels pretty dirty. I am also 100% dependent on Redis. Given that GRPC is built on HTTP2 then I would think that maybe there is some sort of Server Push option but I am not finding any.
I fear that I am overlooking a simple way to handle this problem.
Thanks
Long-lived gRPC channel is an important use case and fully supported. However, one gRPC channel may have more than one TCP connection, and TCP can get disconnected due to inactivity. You can use keep-alive or HTTP/2 ping to keep TCP alive. See this thread for more details.
None of the options you mentioned address the issue that your server takes a while to respond. Unless there’s something I’m missing, nothing in your question is a gRPC issue.
I am building a new application that receives data from a number of external devices and needs to make it available to a number of different components. ZeroMQ seems purpose-built for the "data bus" aspect of my architecture.
I recently became aware that zmq STREAM sockets can connect to native TCP sockets and send/received messages. Using zmq throughout has a lot of appeal, but I have one problem that I don't know how to get around.
One of my devices needs to be set up. That is, I connect a socket to it, send it some configuration information, then sit back and wait for it to send me data. The device also has a "reset" capability (useful in some contexts), that requires re-sending the configuration information. Doing this depends upon having visibility to the setup/tear-down stage of the socket interface. I need to know when a new connection is established, so I can send the necessary configuration messages.
It seems that zmq is purposely designed to shield me from that knowledge. Is there a way to do what I want? Or should I just use regular sockets for this interface?
Well, it turns out that reading (the right version of) the fine manual can be instructive.
When a connection is made, a zero-length message will be received by the application. Similarly, when the peer disconnects (or the connection is lost), a zero-length message will be received by the application.
I guess all that remains is to disambiguate between connect and disconnect. Still looking for advice from the community, if others have dealt with this situation before.
Following up on your own answer, I would hesitate to rely on that zero length connect/disconnect message as your whole strategy - that seems needlessly fragile. It's not clear to me from your question which end is persistent and which end needs configuration information, but I expect that one end knows it's resetting and reconnecting, and that end needs configuration information from the peer, so it should ask for it with a message when it needs it, to which the peer responds with the requested information.
If the peer does not yet have the required configuration information before it receives some other message, it could either queue up that work or it could respond back with the need for the config, and then have the rest of the network handle that need appropriately.
You shouldn't need stream/tcp sockets to make that work, it should work with more standard ZMQ socket types, you just need to build the robustness into your application rather than trying to get it for free from TCP/socket actions.
If I've missed your point, and what I'm suggesting won't work for some reason, you will have to give more specific information about your network topology for anyone else to understand what a suitable solution might be.
Does anyone know if OpenToks sendSignal() method is peer to peer? Or does it get routed through OpenTok's servers? We are looking to send image and video files P2P, but the signaling method seems a bit slower than webRTC's native data channel. I'm wondering if there is something extra happening under the hood.
From the documentation, you should be able to send to a specific end: https://tokbox.com/developer/sdks/js/reference/Session.html#signal. What you need to do is to specify a Connection object.
I have a network of MS SQL servers connected to each other with (C++/C#)clients connected to them. and I'm about designing a way of messaging between clients and server-client messaging.
I've alread read about MS SQL Service Broker and other Brokers like Apache Qpid.
but still I cant find out how would this work, I would be thankful is someone could provide me with better sources or if someone has already worked with such an issue.
How could I make sending and recieving messages between clients without possible?
and please make sure this is no school homework or university course project.
I would really appreciate any helpful comment or advice...
+++Thanks+++
MSDN has quite a bit of technical information regarding SQL Service Broker. It is fairly high-level, but if you dig / read enough you will be a pro in no time.
http://msdn.microsoft.com/en-us/library/ms166043%28SQL.90%29.aspx
There are also a bunch of useful code samples floating around on the internet that should get you up and running so you can start experimenting.
http://blogs.msdn.com/b/sql_service_broker/
http://www.mssqltips.com/tip.asp?tip=1836
Best of Luck!
Why not poll? It's easy, the "dumbest thing that could possibly work".
I suggest you consider polling unless you have established what the problem with polling is.
Considerations:
Timeliness. How quickly must the message be recieved?
Frequency. How many messages are sent to each client per hour? Per day?
Plus, if your application has a connection heartbeat anyway, you could have it report whether there are any new messages and kill two birds with one stone.
If you are affraid of doing a
//PSUDO Code
while(!stopped){
try{
message = receiver.fetch(timeout);
}catch(TimeoutException){
//handle
}
}
You could always prefetch, set the prefetch:
receiver.setCapacity(100);
and then you could use the available messages functionality, but in all reality, this sounds like polling, in a backwards way ;)