I am using Spotify in my iOS application in order to list and play a playlists. Initially I connect appRemote and fetch essential playlist contents with the following scopes such as .appRemote, .playlist, . playlistReadPrivate etc.
App is working fine but if I receive a phone call, then my appRemote was getting disconnected with the below log:
AppRemote: Disconnected with error: Error Domain=com.spotify.app-remote.transport Code=-2001 "End of stream." UserInfo={NSLocalizedRecoverySuggestion=Reconnect to the Spotify app., NSLocalizedDescription=End of stream., NSLocalizedFailureReason=One of the streams has reached the end.}
I tried disconnecting appRemote in app WillResignActive state and also reenabling(Reconnecting with appRemote.connect()) in foreground state. None of them helps. Is there any way to fix this issue or we have to reauthorize once again. Any help will be much appreciated. Thanks.
I've tried in:
- (void)appRemote:(SPTAppRemote *)appRemote didFailConnectionAttemptWithError:(NSError *)error
to handle reconnect attempts with a counter variable and increasing delay
[self performSelector:#selector(connect2Spotify) withObject:self afterDelay:3.0];
not perfect...but works in most cases..
-(void)connect2Spotify
{
if (self.appRemote!=nil)
{
if (!self.appRemote.connected){
self.appRemote.connectionParameters.accessToken = self.token;
[self.appRemote connect];
}
}
}
in our react native app we are using web sockets, sometimes when we have an abnormal closure (websocket: close 1006 (abnormal closure): unexpected EOF)
the event onclose/onerror is not called right away, but after 20-60 minutes later (on ios only). Please note, this issue appears only in background.
this cause our app to not knowing the connection is closed, and it is not initiating new connection
we have tried listening to the network with wireshark but the problem only occurs sometimes and we did not manage catching it for a last 24 hours.
How can we detect such event?
our code:
initiateConnection = (url) => {
this.conn = new WebSocket(url);
this.conn.onopen = this._handleConnectionOpen;
this.conn.onerror = this._handleConnectionError;
this.conn.onclose = this._handleConnectionClose;
this.conn.onmessage = this._handleMessage;
};
_handleConnectionClose = data => {
Log.info('WS - connection closed', data.reason);
};
_handleConnectionError = data => {
Log.info('WS - connection closed', data.reason);
};
I'm using the following code:
_broadcastReceiveSocket = [[GCDAsyncUdpSocket alloc] initWithDelegate:_broadcastHandler delegateQueue:_broadcastQueue];
BOOL successfulStart = [_broadcastReceiveSocket bindToPort:BROADCAST_PORT error:error]
&& [_broadcastReceiveSocket joinMulticastGroup:BROADCAST_HOST error:error]
&& [_broadcastReceiveSocket beginReceiving:error];
To start a socket listening for UDP broadcasts.
But I can only seem to run this code once in the simulator. After that I get an error back saying "Address already is use" from the bindToPort command.
The only way I have found so far to fix this is to reboot the machine. Which from a developers point of view is totally impractical.
I have had this working just fine. Any ideas what could have changed?
You have to close the socket (or destroy it completely) by sending it the close message.
I'm trying to implement support for Apple's enhanced Push Notification message format in my Rails app, and am having some frustrating problems. I clearly don't understand sockets as much as I thought I did.
My main problem is that if I send all messages correctly, my code hangs, because socket.read will block until I receive a message. Apple doesn't return anything if your messages looked OK, so my program locks up.
Here is some pseudocode for how I have this working:
cert = File.read(options[:cert])
ctx = OpenSSL::SSL::SSLContext.new
ctx.key = OpenSSL::PKey::RSA.new(cert, options[:passphrase])
ctx.cert = OpenSSL::X509::Certificate.new(cert)
sock = TCPSocket.new(options[:host], options[:port])
ssl = OpenSSL::SSL::SSLSocket.new(sock, ctx)
ssl.sync = true
ssl.connect
messages.each do |message|
ssl.write(message.to_apn)
end
if read_buffer = ssl.read(6)
process_error_response(read_buffer)
end
Obviously, there are a number of problems with this:
If I'm sending messages to a large number of devices, and the failure message is sent half way through processing, then I'm not going to actually see the error until I've already tried to send to all devices.
As mentioned earlier, if all messages were acceptable to Apple, my app will hang on the socket read call.
One way I've tried to solve this is by to reading from the socket in a separate thread:
Thread.new() {
while data = ssl.read(6)
process_error_response(data)
end
}
messages.each do |message|
ssl.write(message.to_apn)
end
ssl.close
sock.close
This doesn't seem to work. Data never seems to be read from the socket. This is probably a misunderstanding I have about how sockets are supposed to work.
The other solution I have thought of is having a non-blocking read call... but it doesn't seem like Ruby has a non blocking read call on SSLSocket until 1.9... which I unfortunately cannot use right now.
Could someone with a better understanding of socket programming please point me in the right direction?
cam is correct: the traditional way to handle this situation is with IO.select
if IO.select([ssl], nil, nil, 5)
read_buffer = ssl.read(6)
process_error_response(read_buffer)
end
This will check ssl for "readability" for 5 seconds and return ssl if it's readable or nil otherwise.
Can you use IO.select? It lets you specify a timeout, so you could at limit the amount of time you block. See the spec for details: http://github.com/rubyspec/rubyspec/blob/master/core/io/select_spec.rb
I'm interested in this too, this is another approach, unfortunately with it's own flaws.
messages.each do |message|
begin
// Write message to APNS
ssl.write(message.to_apn)
rescue
// Write failed (disconnected), read response
response = ssl.read(6)
// Unpack the binary response and print it out
command, errorCode, identifier = response.unpack('CCN');
puts "Command: #{command} Code: #{errorCode} Identifier: #{identifier}"
// Before reconnecting, the problem (assuming incorrect token) must be solved
break
end
end
This seems to work, and since I'm keeping a persistent connection, I can without problems reconnect in the rescue code and start over again.
There are some issues though. The main problem I'm looking to solve is disconnects caused by sending in incorrect device tokens (for example from development builds). If I have 100 device tokens that I send a message to, and somewhere in the middle there is an incorrect token, my code lets me know which one it was (assuming I supplied good identifiers). I can then remove the faulty token, and send the message to all devices that appeared after the faulty one (since the message didn't get sent to them). But if the incorrect token is somewhere in the end of the 100, the rescue doesn't happen until the next time I send messages.
The problem seams to be that the code isn't really in real time. If I were to send in, say, 10 messages to 10 incorrect tokens with this code, everything would be just fine, the loop will go through and no problems will be reported. It seems that write() doesn't wait for everything to clear up, and the loops runs through before the connection is terminated. The next time the loop will be run, the write() command fails (since we've actually been disconnected since the last time) and we would get the error.
If there is an alternative way to respond to the failed connection, this could solve the problem.
There is a simple way. After you write your messages, try reading in nonblocking mode:
ssl.connect
ssl.sync = true # then ssl.write() flushes immediately
ssl.write(your_packed_frame)
sleep(0.5) # so APN have time to answer
begin
error_packet = ssl.read_nonblock(6) # Read one packet: 6 bytes
# If we are here, there IS an error_packet which we need to process
rescue IO::WaitReadable
# There is no (yet) 6 bytes from APN, probably everything is fine
end
I use it with MRI 2.1 but it should work with earlier versions too.
am connectting the MQ with below code. I am able connected to MQ successfully. My case is i place the messages to MQ every 1 min once. After disconnecting the cable i get a ResonCode error but IsConnected property still show true. Is this is the right way to check if the connection is still connected ? Or there any best pratcices around that.
I would like to open the connection when applicaiton is started keep it open for ever.
public static MQQueueManager ConnectMQ()
{
if ((queueManager == null) || (!queueManager.IsConnected)||(queueManager.ReasonCode == 2009))
{
queueManager = new MQQueueManager();
}
return queueManager;
}
The behavior of the WMQ client connection is that when idle it will appear to be connected until an API call fails or the connection times out. So isConnected() will likely report true until a get, put or inquire call is attempted and fails, at which point QMgr will then report disconnected.
The other thing to consider here is that 2009 is not the only code you might get. It happens to be the one you get when the connection is severed but there are connection codes for QMgr shutting down, channel shutting down, and a variety of resource and other errors.
Typically for a requirement to maintain a constant connection you would want to wrap the connect and message processing loop inside a try/catch block nested inside a while statement. When you catch an exception other than an intentional exit, close the objects and QMgr, sleep at least 5 seconds, then loop around to the top of the while. The sleep is crucial because if you get caught in a tight reconnect loop and throw hundreds of connection attempts at the QMgr, you can bring even a mainframe QMgr to its knees.
An alternative is to use a v7 WMQ client and QMgr. With this combination, automatic reconnection is configurable as a channel configuration.