Android grpc client is receiving GOAWAY from server with "too many pings" error. Now I realise that this is probably a server side issue, but I think the issue is that the client channel settings do not match that of the servers.
I have a C# gRPC server with the following settings:
List<ChannelOption> channelOptions = new List<ChannelOption>();
channelOptions.Add(new
ChannelOption("GRPC_ARG_HTTP2_MIN_RECV_PING_INTERVAL_WITHOUT_DATA_MS",
1000));
channelOptions.Add(new
ChannelOption("GRPC_ARG_HTTP2_MAX_PINGS_WITHOUT_DATA", 0));
channelOptions.Add(new
ChannelOption("GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS", 1));
this.server = new Server(channelOptions) {
Services = { TerminalService.BindService(this) },
Ports = {new ServerPort("0.0.0.0", 5000,
ServerCredentials.Insecure)}
};
On Android I have the following channel setup:
private val channel = ManagedChannelBuilder.forAddress(name, port)
.usePlaintext()
.keepAliveTime(10, TimeUnit.SECONDS)
.keepAliveWithoutCalls(true)
.build()
After a few min (however seems to be a random time). I get the goaway error. I noticed that if I stream data on the call then the error never happens. It is only when there is no data on the stream. This leads me to believe the issue is that the GRPC_ARG_HTTP2_MAX_PINGS_WITHOUT_DATA needs to be set on the Android client aswell. Problem is for the life of me I cannot find where to set these channel settings on gRPC java. Can someone point out to me where I can set these channel settings? There are no examples where these have been set.
The channel options being specified are using the wrong names. Names like GRPC_ARG_HTTP2_MAX_PINGS_WITHOUT_DATA are the C-defines for things like "grpc.http2.max_pings_without_data".
You can map from the C name to the key string by looking at grpc_types.h. You should prefer using one of the C# constants in ChannelOptions when it is available, but that doesn't seem to be an option in this case.
These options are not visible in the Java ManagedChannelBuilder API because they are server-specific settings. So instead they are visible on the ServerBuilder. See A8 client-side keepalive for reference to the Java keepalive API.
Related
i am using PJSIP for voice calling. When i used our server, everything fine i.e. call connected, communicate. But when i am using SIP2SIP.INFO server. Registration is OK But Call is not connected. i saw log in SIP2SIP.info there wasn't log of outgoing or incoming call.
so call is not initiate.
char cfg_reg_uri[] = "sip:sip2sip.info";
char cfg_cred_realm[] = "sip2sip.info";
char cfg_cred_scheme[]="digest";
pjsua_acc_config cfg;
pjsua_acc_config_default(&cfg);
cfg.id = pj_str(cfg_id);
cfg.reg_uri = pj_str(cfg_reg_uri);
cfg.cred_count = 1;
cfg.cred_info[0].realm = pj_str(cfg_cred_realm);
cfg.cred_info[0].scheme = pj_str(cfg_cred_scheme);
cfg.cred_info[0].username = pj_str(cfg_cred_username);
cfg.cred_info[0].data_type = PJSIP_CRED_DATA_PLAIN_PASSWD;
cfg.cred_info[0].data = pj_str(cfg_cred_password);
status = pjsua_acc_add(&cfg, PJ_TRUE, &_acc_id);
I noted that we need to use outbound proxy in sip2sip called "proxy.sipthor.net".
but confused how can i used in pjsip code.
please help expert.
If you read the Sip2Sip device configuration page it states that:
" the SIP device must always perform DNS lookups as defined in SIP standard RFC3263 (NAPTR + SRV + A DNS lookups)"
PJSIP supports DNS SRV lookups.
In PJSUA it will only do DNS SRV lookup if you don't provide the port number in the SIP URL.
"sip:xxx#sip2sip.info" will try to do a DNS SRV record lookup first then fail over to DNS A/C name lookup.
and
"sip:xxx#sip2sip.info:5060" will only do DNS A/C name lookup.
What PJSUA will not support automatically is failover support, they say:
"What we've been suggesting is to implement the failover mechanism in the application layer."
If you want a "quick and easy" setup, what you want to do is set the outbound_proxy to "proxy.sipthor.net". e.g.
cfg.outbound_proxy_cnt = 1;
cfg.outbound_proxy[0] = pj_str("sip:proxy.sipthor.net:5060");
If you want a more robust solution, you need to use pjsip's SRV resolution functions to resolve sip2sip.info srv record e.g: "_sip._udp.sip2sip.info" and then set the outbound_proxy records with the result.
The code is a little bit involved.
pjsip_resolver_t* resolver_;
...
status = pjsip_resolver_create( pool, &resolver_ );
...
pjsip_host_info host;
host.flag = PJSIP_TRANSPORT_DATAGRAM; // is using UDP, see pjsip_transport_flags_e
host.type = PJSIP_TRANSPORT_UDP; // if using UDP, see pjsip_transport_type_e
host.addr.host = pj_str("sip2sip.info");
host.addr.port = 5060;
pjsip_resolve(resolver_, pool, &host, token, resolver_cb_func);
...
static void resolver_cb_func( pj_status_t status, void *token, const struct pjsip_server_addresses *addr)
{
...
// use results to fill in the outbound_proxy
}
You could also take it further to support failover, but it looks like sip2sip doesn't have multiple sip servers in there DNS SRV record so it will not be used currently. If they ever add more then it would become more useful.
_sip._udp.sip2sip.info
Server: fritz.box Address: fd00::2665:11ff:fef9:ec51
Non-authoritative answer:
_sip._udp.sip2sip.info SRV service location:
priority = 100
weight = 100
port = 5060
svr hostname = proxy.sipthor.net
sip2sip.info nameserver = ns2.dns-hosting.info
sip2sip.info nameserver = ns1.dns-hosting.info
sip2sip.info nameserver = ns7.dns-hosting.info
Sip2Sip also support STUN setup, so I would also setup the STUN settings on the account as well:
cfg.stun_srv_cnt = 1;
cfg.stun_srv[0] = pj_str("sip2sip.info");
Since your example seems to not provide the port information it should work. To diagnose this further would require see the pjsip log output.
I am using rapns to provide GCM and APNS support. For APNS, I know what unregistered device I must delete via on.apns_feedback (rapns.rb):
on.apns_feedback do |feedback|
device = AppleDevice.find_by_token(feedback.device_token)
device.destroy if device
end
but for GCM, I can't find a way to know what device is unregistered so I can delete it from my database.
I tried with the reflection API, but I'm not getting on.notification_failed and on.error called whenever a Rapns::DeliveryError exception is raised and those methods doesn't seem to give me a way to know the unregistered tokens.
I tried catching the Rapns::DeliveryError, but it doesn't seem to work.
messenger = PushMessenger::Gcm.new
GoogleDevice.find_in_batches :batch_size => 1000 do |devices|
tokens = devices.map(&:token)
begin
messenger.deliver(app, tokens, payload, nil, true)
rescue Rapns::DeliveryError => error
GoogleDevice.destroy_all # Just to see it works
end
end
PushMessenger:
module PushMessenger
class Gcm
def deliver(app, tokens, payload, collapse_key=nil, delay_while_idle=nil, expiry=1.day.to_i)
tokens = *tokens
n = Rapns::Gcm::Notification.new
n.app = app
n.registration_ids = tokens
n.collapse_key = collapse_key
n.delay_while_idle = delay_while_idle
n.expiry = expiry
n.data = payload
n.save!
end
end
end
How can I know the token for these unregistered devices so I can remove them from my database?
I'm using rapns to do pretty much the same, so here my two cents:
First, for Android devices you don't need the device_token to deactivate/remove the device (On GCM device_token == registration_id). You can get that registration_id from the on.notification_failed callback with the Reflection API.
Last, which version of rapns are you using? Right now the last version (3.4.1) has a bug with on.notification_failed, but version 3.3.2 works just fine and you'll be able to do something like:
on.notification_failed do |notification|
device = Device.find_by_token(notification.registration_ids.first)
device.destroy if device
end
Hope that helps.
I am opening a connection setting up a custom protocol like this:
WebSocketSubProtocol d = new WebSocketSubProtocol("MyCustomProto",WebSocketEncoding.TEXT);
mJWC.addSubProtocol(d);
mJWC.open(mURL);
But... Server side, I receive tis in the protocol string
"org.jwebsocket.json MyCustomProto"
How can I remove from the string the "org.jwebsocket.json" ?
I don't wanna do it server side...
Thanks!
I will answer to my own question.
By calling the "addSubProtocol" doesn't seem to be the right solution for couple of reasons:
if you call those 3 lines of code multiple time (if the first time the connection failed for example..) well the the protocol string would be something like
"org.jwebsocket.json MyCustomProto MyCustomProto"
It just keep adding the protocol..
So I found a turn around. Now I don't use that "addSubProtocol" but instead I defined the protocol directly when I create the socket
mJWC = new BaseTokenClient("client||"+code+"||"+name,WebSocketEncoding.TEXT);
Voila.. Now no more "org.jwebsocket.json" anymore
In an attempt to bypass Box file/folder IDs and supporting a number of other services as well I decided to implement with WebDAV since I'm somewhat familiar with it on my linux box. I chose a library based on JackRabbit modified to work on Android which seemed to suit my needs. However, it wasn't long until I ran into a problem.
When attempting to list Box's root entries, multiStatus.getResponses() returns an empty array. When accessing another webdav server I get the responses as expected. Both servers return status code 207, as expected.
My code is below, any thoughts?
EDIT: I can move a file, though listing a directory's entries won't work :/
String host = "https://www.box.com/dav/";
//String host = "http://demo.sabredav.org/";
hostConfig = new HostConfiguration();
hostConfig.setHost(host);
HttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();
HttpConnectionManagerParams params = new HttpConnectionManagerParams();
int maxHostConnections = 20;
params.setMaxConnectionsPerHost(hostConfig, maxHostConnections);
connectionManager.setParams(params);
client = new HttpClient(connectionManager);
Credentials creds = new UsernamePasswordCredentials("BOXEMAILADDRESS", "MYBOXPASSWORD");
//Credentials creds = new UsernamePasswordCredentials("testuser", "test");
client.getState().setCredentials(AuthScope.ANY, creds);
client.setHostConfiguration(hostConfig);
try
{
String propfindUri = host;
DavMethod method = new PropFindMethod(propfindUri, DavConstants.PROPFIND_ALL_PROP, DavConstants.DEPTH_1);
client.executeMethod(method);
Log.i("Status: " + method.getStatusCode());
MultiStatus multiStatus = method.getResponseBodyAsMultiStatus();
MultiStatusResponse[] responses = multiStatus.getResponses();
Log.i("Length: " + responses.length);
for(MultiStatusResponse response : responses)
{
Log.i("File: " + response.getHref());
}
}
catch (Exception e)
{
Log.printStackTrace(e);
}
While Box has some support for WebDAV, we only officially support it for iOS at the moment. Our testing has shown that our implementation of DAV works pretty well with the Windows native DAV client, as well as the Panic-Transmit Mac-specific client. Though the interactions there are not completely perfect.
Box WebDAV does not work well with the native osX (Mac) webDAV client. Expect huge delays as it looks like that client tries to load the whole tree before it displays anything.
Linux users may be able to tell you here on StackTrace which of the various OS webDAV clients/libs they've tried and which ones have worked better than others.
We do have plans to turn the crank and 10x improve our webDAV support sometime later this year, but we do not have a specific date, and just the nature of webDAV clients is such that even when we fix many of the issues with it, some client experiences on webDAV may still suck. For that reason we may only officially endorse a couple webDAV clients/libs per platform.
Hope that helps.
I need to work with a TCP socket over TLS for an app I'm working on. I've been through dozens of examples and while I have no problem getting through the handshake, I can't seem to read the input stream through any means (tried a lot, including readline(), reading to character array, etc). every time I try, the app freezes on that spot. If I debug, it never goes to the next line of code.
In an attempted solution, I decided to move over to using an SSLEngine, since that's supposed to be the Java 1.5 answer to java.nio for SSL. However, I have found one example (here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java) which is more than a little confusing to me, and I've not been successful implementing it. When I try, the unwrap() call yields an empty buffer, where I know (from using OpenSSL on the command line) that the service in question pushes data back down the pipe.
Suggestions are welcome, I've burned way too much time on this already. Here's the relevant code:
SSLEngine engine = sslContext.createSSLEngine(uri.getHost(), uri.getPort());
engine.setUseClientMode(true);
engine.beginHandshake();
SSLSession session = engine.getSession();
int bufferMax = session.getPacketBufferSize();
int appBufferMax = session.getApplicationBufferSize() + 50;
ByteBuffer cTo = ByteBuffer.allocateDirect(bufferMax);
ByteBuffer sTo = ByteBuffer.allocateDirect(bufferMax);
ByteBuffer out = ByteBuffer.wrap(sessionId.getBytes());
ByteBuffer in = ByteBuffer.allocate(appBufferMax);
debug("sending secret");
SSLEngineResult rslt = engine.wrap(out, cTo);
debug("first result: " + rslt.toString());
sTo.flip();
rslt = engine.unwrap(sTo, in);
debug("next result" + rslt.toString());
This implementation is missing some key pieces. Namely the handshake can bounce between several states NEED_WRAP, NEED_UNWRAP, NEED_TASK to negotiate a connection. This means you cannot just call one and then the other. You will need to loop over the states until a handshake has completed.
while (handshaking) {
switch (state) {
case NEED_WRAP:
doWrap();
break;
case NEED_UNWRAP:
doUnwrap();
break;
case NEED_TASK:
doTask();
break;
}
}
A full working example of Java SSL and NIO
Now that said, you should be aware the SSLEngine on Android is broken. Google recommends using threads and blocking sockets according to that thread.
I have written something to make using SSLEngine easier. It can be used with NIO or for other use cases. Available here SSLFacade
unwrap() can yield an empty buffer if what was unwrapped was an SSL handshake message or alert, rather than application data. There's not enough information here to say more. What was the engine status afterwards?
beginHandshake does not proceed the handshake, it is just used to inform the SSLEngine that you want to perform the handshake for the next calls to wrap/unwrap.
It's useful when you want to do another handshake. For the initial one, it is not needed as the first call to wrap will initiate the handshake.
Besides, you have to check the result of the wrap and unwrap methods to know if all the data has been correctly encoded. It can happen that you have to call the methods several times to process all the data.
The following link might help:
http://onjava.com/onjava/2004/11/03/ssl-nio.html
Or this question:
SSL Handshaking Using Self-Signed Certs and SSLEngine (JSSE)