Cannot reconnect to gRPC server after client crashed - swift

I did a lot of research but could not find a solution for my problem with gRPC:
Summary;
After my swift gRPC client application crashes, no gRPC client can connect to my gRPC Server anymore (see errors below)
My Setup:
I have a Swift frontend application and a Rust backend.
The rust backend runs a gRPC Server (tonic) https://github.com/hyperium/tonic to which a rust client (also tonic) and a Swift client (https://github.com/grpc/grpc-swift) can connect to.
After the Swift client crashes, none of the clients can connect anymore to the server.
The rust client reports:
Error: Status { code: Cancelled, message: "h2 protocol error: protocol error: stream no longer needed" }
The swift client reports:
StreamClosed(streamID: HTTP2StreamID(1), errorCode: HTTP2ErrorCode<0x8 Cancel>, location: ".../swift-nio-http2/Sources/NIOHTTP2/HTTP2StreamChannel.swift:820")
What I've tried
I setup a http2 keepalive in the server, but that didn't do anything.
I tried to reproduce the same effect by purposefully crashing the rust client - without success.
I'm not even sure wether to look at the swift-grpc and tonic libraries or grpc itself (for me it looks like the server closes the stream on purpose)..
Has anyone an idea what i could do to fix this?
Thanks in advance!

Related

Connecting to Openfire using Icelink

I’m trying to build a voip app with openfire on server-side, Icelink on client-side in xamarin android.
The problem is the openfire client(running on port 5222) does not respond at all even from the local host.
For example when i try 192.168.1.xx:5222 in my browser, it is always in acquire stat and does not response anything.
I have checked all the primitive things and tested the server with Spark and it works fine!

Connect to C++ REST sdk SERVER on Windows from LAN

I have a server written on C++ REST SDK.
There's http_listener which listens to "http://localhost:34568".
When I try to send a request in browser or from the client to localhost it works fine and I get the responses from my server. But the point is to use the application in network. And here where the problem comes.
When I try to request the server from the other PC using IP(192.168.1.103:34568) I get "HTTP Error 400. The request hostname is invalid."
I'm aware that that could be some firewall issues but it's turned off. Also I tried to set port rules in brandmauer and it didn't help.
And even more! I got XAMPP running Apache server and when I do the same thing but with (192.168.1.103:80) I do get the response from Apache and have an access.
Anybody had something similar or somebody knows what the problem is about?
Listen to local ip address or to your network name (dns):
"http://xxx.xxx.xxx.xxx:34568" or
"http://your_network_name:34568"
So, if you have multiple network adapters, you can choose which one.

Swift socket invalid HTTP upgrade

Good day,
I've established very simple Python server (Twisted framework) on localhost:80. It works ok with telnet - i can send and recieve simple messages. But i need to connect Swift iOS app client to this server. App running on simulator.
I'm using Socket_IO_Client_Swift framework. At this moment, i've just created socket object with "localhost:80" parameter and call connect() method on start of application.
Server can see the signal from client, but client disconnect immidietly after connection with this message:
Got event: disconnect, with items: Optional((
"Invalid HTTP upgrade"
What can i do to fix this, and what is HTTP upgrade?
Thanks

"connection refused" when my play app makes http call to itself

I am implementing a heartbeat endpoint/route using play 2.2.1 built with Scala 2.10.2 (running Java 1.7.0_45). When
the heartbeat endpoint is called, I want the controller to make http calls to localhost. If all of those
calls are ok, then the heartbeat endpoint will return an OK http response.
When I execute the following url from curl, I get the expected 200 response:
http://localhost:9000/oauth2/token. I am also able to telnet to localhost 9000.
I am also able to use WS successfully with an external URL:
WS.url("http://www.example.com").withHeaders("Content-Type" -> "application/json").get()
However, when I execute it from within my play app, I get a 500 tcp_error response.
WS.url("http://localhost:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://127.0.0.1:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://HostName:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
Here is the exact error message I receive:
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
Do I need to configure something to allow a play application to make calls to itself? Is this a network problem on
my box? If so, why do curl and telnet work? If a network issue, then it must be a jvm specific networking issue?
Could it be a security problem with play calling to itself? Not sure where to go next.

TLS Socket connection through Nodejs

Im trying to establish a TLS socket connection to chat.facebook.com port:5222 through Nodejs.
Im using the following code :
var a=require('tls');
var b=a.connect(5222,'chat.facebook.com',function(){console.log("connected");});
b.on('error',function(error){console.log(error);})
But it is not getting connected and instead giving an error :
[Error: 140089045411648:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:683:]
I have tried a similiar connection to encrypted.google.com:443 and console readily fired a "connected" .
Can someone guide me what i have been missing or what can be done to overcome this problem.
xmpp with tls uses "STARTTLS", a protocol upgrade from plaintext to encrypted. See http://xmpp.org/rfcs/rfc6120.html#tls for details.
(It means you have to send some unencrypted xml stuff first, and wait for the other end to confirm your choice to upgrade to TLS)