acmacalister / jetfire Goto Github PK

How to solve the delay problem

Is there a way to disconnect a JFRWebSocket without causing an error code=1000, "continue frame before a binary or text frame"?

On High Sierra Beta (17A362a)

From my OS X command line application When I try to connect to URL ws://127.0.0.1:10134
I see success

But from my OS X app, when I connect to same url, I am seeing

2017-10-06 17:38:14.739725-0700 crafttest[70526:6739789] [] nw_socket_connect connectx failed (fd 14, 127.0.0.1:10134 stream, pid: 70526): [1] Operation not permitted
2017-10-06 17:38:14.739934-0700 crafttest[70526:6739792] [] nw_connection_get_connected_socket 1 Connection has no connected handler
2017-10-06 17:38:14.739956-0700 crafttest[70526:6739792] TCP Conn 0x60c000162400 Failed : error 0:1 [1]
2017-10-06 17:38:14.749492-0700 crafttest[70526:6738000] websocket is disconnected: The operation couldn’t be completed. Operation not permitted

Is there any chance that you could make a new CocoaPod release from master?

I am particularly keen to get the changes from #36 😄

“ -(void)websocketDidDisconnect:(JFRWebSocket_)socket error:(NSError_)error {
NSLog(@"websocket is disconnected: %@", [error localizedDescription]);
[self.socket connect];
}”
I perform the above methods , but "self.isCreated" is NO. how to reconnect?

Hello,

I have a reconnection routine. If websocketDidDisconnect:error is called I call a performSelector afterDelay (here I just put 1 second to avoid any UI freeze).
So basically if my server is off I should log every second a websocketDidDisconnect:error .

But I've observed [self.outputStream write:[data bytes] maxLength:[data length]]; is sometimes very slow to be executed.
Do you have an idea on that ?

Thx !

Is this line correct?

Shouldn't it be this way:

details[NSLocalizedDescriptionKey] = detail;

Hi, I need a help.. i'm trying to implement socket for obj-c but i'm facing below issues .. same IP and Port i try to implement on swift socket.io its connect ,.. but obj-c its return disconnected .. i don't know why kindly do needful .. they are using socket >v1.0 is it support for that version

urlRequest = "<CFHTTPMessageRef 0x600000169240(0x600000169250)> { GET request, url http://192.168.17.7:5000 }"

websocket is disconnected: (null)

I have met a crash at

[self.inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
    [self.outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
    [self.inputStream open];
    [self.outputStream open];
    size_t dataLen = [data length];
    [self.outputStream write:[data bytes] maxLength:dataLen];
    while (self.isRunLoop) {
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    }

The Line [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]; always crash when I create many socket in a short time. Maybe there is a third sdk conflict with these above code.

And I spent half day to fix this problem , and finally I find a way to avoid this bug. The code is:

    [self.inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:@"JFRWebSocketRunLoopMode"];
    [self.outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:@"JFRWebSocketRunLoopMode"];
    [self.inputStream open];
    [self.outputStream open];
    size_t dataLen = [data length];
    [self.outputStream write:[data bytes] maxLength:dataLen];
    while (self.isRunLoop) {
        [[NSRunLoop currentRunLoop] runMode:@"JFRWebSocketRunLoopMode" beforeDate:[NSDate distantFuture]];
    }

I am not sure why this crash happend, neither not sure why my fix can works.

But I think should let you know this issue.

JetFire only supports client-side connections. Server connections are required for apps that want to do P2P messaging (such as mine.)

The necessary bits are:

• Running a listener socket to accept incoming TCP connections
• Parsing the HTTP request on an incoming connection
• Modifying the way messages are sent (i.e. not masking the contents)

You may be able to steal code or at least ideas from PocketSocket's implementation 😉

Hi guys,

I was wondering if you were aware of this vulnerability when using certificate pinning?

I stumbled upon this when reading the latest SocketRocket commit.

Thanks a lot,

I'm getting weird performance issues when trying to connect to the host. In case if it's unsuccessful, i'm reconnecting and here is the screenshot of profiler log.
https://www.dropbox.com/s/efz3r1g8d0ezjq3/Screen%20Shot%202015-06-11%20at%2018.28.29.png?dl=0
Shouldn't worker thread stop when attempt is unsuccessful?

JetFire runs its background stream handler by dispatching a block to a system concurrent dispatch queue, starting a runloop, and running it indefinitely until the socket closes. This works, but I believe it's bad form for a couple of reasons:

1. The system dispatch queues are supposed to be used for short tasks and shouldn't be blocked for large amounts of time.
2. You're creating a runloop on a thread you don't own. And the runloop remains in existence (but idle) after you're done with it, since the thread will be reused by other tasks afterwards.

I think it would be safer/cleaner to simply start an NSThread instead. It's a simple change — just call +[NSThread detachNewThreadSelector:...] instead of dispatch_async.

Even better is the approach used by PocketSocket: share one background thread/runloop to receive NSStream events for all sockets. (But it only makes a difference if a lot of sockets will be open at once.)

[Note: I haven't used JetFire yet; I'm still kicking the tires of various Cocoa WebSocket libraries.]

Thread 7 Crashed:
0   CoreFoundation                       0x0000000181a51b78 CFHash + 268
1   CoreFoundation                       0x0000000181a52f70 CFBasicHashGetCountOfKey + 496
2   CoreFoundation                       0x0000000181a52d34 CFSetContainsValue + 144
3   CoreFoundation                       0x0000000181a80614 CFRunLoopRemoveSource + 224
4   CFNetwork                            0x00000001821eab30 SocketStream::write(__CFWriteStream*, unsigned char const*, long, CFStreamError*) + 440
5   CoreFoundation                       0x0000000181a6e30c CFWriteStreamWrite + 416
6   sling                                0x00000001002663f8 -[JFRWebSocket initStreamsWithData:port:] (JFRWebSocket.m:269)
7   sling                                0x0000000100265c64 -[JFRWebSocket createHTTPRequest] (JFRWebSocket.m:221)
8   sling                                0x0000000100265580 __23-[JFRWebSocket connect]_block_invoke44 (JFRWebSocket.m:135)
9   libdispatch.dylib                    0x00000001815c5630 _dispatch_call_block_and_release + 20
10  libdispatch.dylib                    0x00000001815c55f0 _dispatch_client_callout + 12
11  libdispatch.dylib                    0x00000001815d3a88 _dispatch_root_queue_drain + 2136
12  libdispatch.dylib                    0x00000001815d3224 _dispatch_worker_thread3 + 108
13  libsystem_pthread.dylib              0x00000001817d9470 _pthread_wqthread + 1088
14  libsystem_pthread.dylib              0x00000001817d9020 start_wqthread + 0

This is unfortunately all I have, a crash via Hockeyapp. It's a pretty common crash for our users, but I've never been able to reproduce it so I can't give you a backtrace or something like that.

My socket server require to put in query/parameters upon connect, may i know how to add in the query/parameter by using this library?

What are your thoughts on adopting a style guide for this project?

At Yahoo we typically recommend these:
Apple's Coding Guidelines for Cocoa
NYTimes Objective C Style Guidelines

Along with some project-specific guidance.

Hello!

For some time, about 2 weeks, we experience random crashes happening on app startup, while WS attempts to connect to server. Seems change in this place was introduced in this commit: ae6d655.

Unfortunately, we haven't found any way to reliably reproduce the issue, it seems to happen randomly. I attach screenshot with as much data, as we were able to collect. This particular one comes from iPhone 5c and jetfire 0.1.4.

Thanks for help!

When we put the certificate in local and set ‘userPublicKeys=Yes’.Then run into line 124 of JFRSecurity.m may be crash! Because self.pubKeys is nil.

More of a suggestion than a issue, I needed to use client side certificates, the way I got around this was to create a dictionary property on JFRWebSocket called additionalOutputStreamProperties which is then enumerated over applying the setProperty:forKey: for each entry to the output stream, adding something like this to JetFire would make it easy to handle any niche use case.

I'm experiencing a crash in -(void)dequeueWrite:(NSData*)data withCode:(JFROpCode)code.

This crashes on line line 656 for JFRWebSocket.m: NSInteger len = [self.outputStream write:([frame bytes]+total) maxLength:(NSInteger)(offset-total)]; with EXC_BREAKPOINT (code=1).

I'm using the latest version of your code (branch master), iOS 8.3 on device, iPhone 6.
The connexion in made on a secure websocket (wss:// protocol).

Here are the variable states during the call:

total   uint64_t    0
offset  uint64_t    65
frame   NSConcreteMutableData * 91 bytes
len     NSInteger   4341676604

This is very random, I experienced it several times but did not manage to re-create it on demand.
Hope this helps..Thanks.
Also, I'm not messing with thread, I send all JFRWebSocket messages from the main thread.

new to GitHub so maybe not the right avenue for this...

I was surprised when I compiled on Xcode 8.3.2 and got a warning.

JFRWebSocket.m -dequeueWrite:withCode: line 36
SecRandomCopyBytes(kSecRandomDefault, sizeof(uint32_t), (uint8_t *)mask_key);

Normally a warning doesn't throw me but the text of this was onerous enough that I thought I would report it.. "...Ignoring return value of function declared with 'warn_unused_result' attribute"

Perhaps the code could or should be refactored to avoid this warning?

Steve

I wanted to close web-socket if some timeout is elapsed and no ping was received from server, but there is no listener for ping received, is there other mechanisms how to close web-socket on client if server dies?

How to set timeout ?

Bump up either the major number or the minor number, as the user code may need to change due to nullable in the methods/delegates/properties.

How to solve the problem of delay

Is there some way to use a pinned SSL certificate? If there were a way to pass a URL request rather than a URL to init, this could be just handled by CFStream. i.e. with Socket Rocket I used to do something like:

    NSURL *url = [NSURL URLWithString: ServerSocketURLString];
    NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];

    NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"servercertificate" ofType:@"cer"];
    NSData *certData = [[NSData alloc] initWithContentsOfFile:cerPath];
    CFDataRef certDataRef = (__bridge CFDataRef)certData;
    SecCertificateRef certRef = SecCertificateCreateWithData(NULL, certDataRef);
    id certificate = (__bridge id)certRef;

    [request setSR_SSLPinnedCertificates:@[certificate]];

    self.socket = [[JFWebSocket alloc] initWithURLRequest:request];

    self.socket.delegate = self;

Thanks!

Got new crashlog for you:)

Thread : Crashed: com.apple.root.default-qos
0  CoreFoundation                 0x0000000182a45830 CFHash + 256
1  CoreFoundation                 0x0000000182a41e24 CFBasicHashFindBucket + 1000
2  CoreFoundation                 0x0000000182a419e0 CFDictionaryGetValue + 160
3  CoreFoundation                 0x0000000182ac02f4 _CFStreamUnscheduleFromRunLoop + 116
4  Thred                          0x0000000100257d58 -[JFRWebSocket disconnectStream:] (JFRWebSocket.m:282)
5  Thred                          0x0000000100257bf8 -[JFRWebSocket stream:handleEvent:] (JFRWebSocket.m:266)
6  CoreFoundation                 0x0000000182ac0070 _signalEventSync + 192
7  CoreFoundation                 0x0000000182acce88 _cfstream_solo_signalEventSync + 236
8  CoreFoundation                 0x0000000182b20240 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
9  CoreFoundation                 0x0000000182b1f4e4 __CFRunLoopDoSources0 + 264
10 CoreFoundation                 0x0000000182b1d594 __CFRunLoopRun + 712
11 CoreFoundation                 0x0000000182a492d4 CFRunLoopRunSpecific + 396
12 Foundation                     0x00000001839814c8 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 316
13 Thred                          0x0000000100257a60 -[JFRWebSocket initStreamsWithData:port:] (JFRWebSocket.m:240)
14 Thred                          0x00000001002570b0 -[JFRWebSocket createHTTPRequest] (JFRWebSocket.m:196)
15 Thred                          0x0000000100256558 __23-[JFRWebSocket connect]_block_invoke (JFRWebSocket.m:110)
16 libdispatch.dylib              0x0000000194eb1994 _dispatch_call_block_and_release + 24
17 libdispatch.dylib              0x0000000194eb1954 _dispatch_client_callout + 16
18 libdispatch.dylib              0x0000000194ebe780 _dispatch_root_queue_drain + 1848
19 libdispatch.dylib              0x0000000194ebfc4c _dispatch_worker_thread3 + 108
20 libsystem_pthread.dylib        0x000000019509122c _pthread_wqthread + 816
21 libsystem_pthread.dylib        0x0000000195090ef0 start_wqthread + 4

Thank for your awesome library.
My service asked me to subscribe to a destination, but i don't know how to do it.
I've read Stomp Websocket document, it said that it has a method "subscrible".
Can you help me? Thank so much.

Our users are experiencing this crash a lot. Can you please look into this?
This is also mentioned here
#43

Here is crash report part:

Thread : Crashed: com.apple.root.default-qos
0 CoreFoundation 0x18242db78 CFHash + 268
1 CoreFoundation 0x18242ef70 CFBasicHashGetCountOfKey + 500
2 CoreFoundation 0x18242ed34 CFSetContainsValue + 148
3 CoreFoundation 0x18245c614 CFRunLoopRemoveSource + 228
4 CFNetwork 0x182bc6b30 SocketStream::write(__CFWriteStream, unsigned char const, long, CFStreamError*) + 444
5 CoreFoundation 0x18244a30c CFWriteStreamWrite + 420
6 MyApp 0x10029b128 -JFRWebSocket initStreamsWithData:port:
7 MyApp 0x10029a994 -JFRWebSocket createHTTPRequest
8 MyApp 0x10029a2b0 __23-[JFRWebSocket connect]_block_invoke44 (JFRWebSocket.m:135)
9 libdispatch.dylib 0x181fa1630 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x181fa15f0 _dispatch_client_callout + 16
11 libdispatch.dylib 0x181fafa88 _dispatch_root_queue_drain + 2140
12 libdispatch.dylib 0x181faf224 _dispatch_worker_thread3 + 112
13 libsystem_pthread.dylib 0x1821b5470 _pthread_wqthread + 1092
14 libsystem_pthread.dylib 0x1821b5020 start_wqthread + 4

Hi ,
Thanks for Providing the SDK , I like the way u formulated the methods and code in a Structured way . I want to implement the SDK in one of my company Project . After integrating the pod file , i have followed the steps which u have mentioned in Readme file , but i am facing with error .

Error : websocket is disconnected: The operation couldn’t be completed. (JFRWebSocket error 1.)
Note : I have checked with my host, it is working fine in android , but when it comes to IOS , it is showing the above error.

Can u please check this and let me know , where was the problem .

I am testing in Xcode 9.1

Thanks .

Trying to handle a loss of network connection in our app I have found inconsistencies when trying to reconnect. The two ways I test loss of network are, using Apples "Network Link Conditioner" with 100% loss and pulling out the Ethernet cable. When my error delegate method (websocketDidDisconnect:error:) is called I just wait a small amount of time and call connect again on the same JFRWebSocket instance, I also call writePing: periodically when I have a connection to test its still connected. If the connection is broken by Network Link Conditioner, my error delegate method is called every time I try to reconnect until the network is restored and I can connect. But if I pull out the Ethernet cable, my error delegate method is called when the connection is broken, but when I try reconnecting again my error delegate is never called so there is no way for me to know the re-connection attempt failed and I should wait a bit and try again. I guess the second behaviour based on the method name websocketDidDisconnect:error: make senses, but then there isn't a way to an attempt to connect failed.
Is reusing the same JFRWebSocket after network loss OK or should I create a new instance all together? Maybe I should be calling disconnect on JFRWebSocket before I try reconnect? Maybe I have discovered a bug?
Thanks

Great project, it was really easy to add websockets support to an app I'm currently building. However, the socket connection always disconnects after one minute. Is there an easy way to keep the connection open, or do I need to keep a timer myself to send ping messages every 30 seconds or so? Or is the server supposed to send these ping/pong messages every once in a while?

I want to share several issues I found. Maybe it can be useful to someone.

When I was looking for Web Sockets library in ObjC, this was referenced as the best one. So I used it in my application. But then I got a few crash reports. I didn't have any since release in App Store. I haven't reviewed this code good enough before adding it. When I did, I found several issues in it. I found that it is "mostly working", but for production code, it is not good enough. Generally speaking, code just needs refactoring. Still, I want to thank the authors, it was a good start point for me anyway.

1. crash in [JFRWebSocket dealloc]: #70

2. [JFRWebSocket writeError:] may be called many times, and it always sends closing-handshake packet, even if it was already sent. This creates redundant traffic and violates the protocol.

3. [JFRWebSocket disconnect] does not ensure socket closure. It relies on server to close it first, and usually it does so. But there should be a timeout, after which socket is forced to close.

4. Calling [outputStream write: maxLength:] in [JFRWebSocket dequeueWrite: withCode:] is not safe. Must be called from run loop queue, in which outputStream was created.

5. Should wait for NSStreamEventHasSpaceAvailable event instead of trying to call [outputStream write: maxLength:] forever in loop in [JFRWebSocket dequeueWrite: withCode:].

6. *((uint16_t *)(buffer + offset)) and *((uint64_t *)(buffer + offset)) may crash because of misalignment.

7. The [JFRWebSocket processRawMessage] method is the most confusing. It seems unmaintainable. I'm almost sure it is buggy. I found it easier to rewrite it completely than try to correct it.

8. There are also few race condition issues, for example when using isCreated and didDisconnect properties.

Note that I don't use JFRSecurity class in my project (I removed it), so I don't tell anything about its issues if there are any.

When the server send massive packets to the client, main thread has stuck for dispatching delegation in the below codes.

https://github.com/acmacalister/jetfire/blob/0.1.5/JFRWebSocket.m#L611-L619
https://github.com/acmacalister/jetfire/blob/0.1.5/JFRWebSocket.m#L621-L629

I've removed dispatch_async() and received packet pooling on onText, and fire delegation using NSTimer.

What do you think about this scenario?

😱

I am getting some crash reports from [JFRWebSocket dequeueWrite:withCode:] with crash logs similar to this:

Exception Type:  SIGTRAP
Exception Codes: #0 at 0x2c70e39a
Crashed Thread:  16

...

Thread 16 Crashed:
0   CoreFoundation                       0x2c70e39a CFHash + 130
1   CoreFoundation                       0x2c70f2dc CFBasicHashGetCountOfKey + 1110
2   CoreFoundation                       0x2c70ee43 CFSetContainsValue + 100
3   CoreFoundation                       0x2c741d33 CFRunLoopRemoveSource + 228
4   CFNetwork                            0x2c2e67bf SocketStream::write(__CFWriteStream*, unsigned char const*, long, CFStreamError*) + 428
5   CFNetwork                            0x2c2ea9f9 WriteStreamCallbacks::_write(__CFWriteStream*, unsigned char const*, long, CFStreamError*, void*) + 34
6   CoreFoundation                       0x2c732b31 CFWriteStreamWrite + 358
7   Intercom                             0x003b895b __50-[JFRWebSocket dequeueWrite:withCode:]_block_invoke (JFRWebSocket.m:656)
8   Foundation                           0x2d502251 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 6
9   Foundation                           0x2d46d2ed -[NSBlockOperation main] + 146
10  Foundation                           0x2d45faa7 -[__NSOperationInternal _start:] + 772
11  Foundation                           0x2d504bbb __NSOQSchedule_f + 184
12  libdispatch.dylib                    0x3a5295b1 _dispatch_queue_drain + 950
13  libdispatch.dylib                    0x3a523f85 _dispatch_queue_invoke + 82
14  libdispatch.dylib                    0x3a52ab9b _dispatch_root_queue_drain + 336
15  libdispatch.dylib                    0x3a52bcd7 _dispatch_worker_thread3 + 92
16  libsystem_pthread.dylib              0x3a682e31 _pthread_wqthread + 666
17  libsystem_pthread.dylib              0x3a682b84 start_wqthread + 6

Any ideas what might be causing this? The block in dequeueWrite:withCode: does quite a lot so I'm not sure what the culprit could be.

On master, reconnecting to the same object seems to be broken.

For example if I create and connect to a new JFRWebSocket and some time later call disconnect, any attempt to call connect on that same object will fail.

This seems to be a regression since 0.1.2.

On a related note, I think it may be a good idea for all calls to websocketDidDisconnect:error: to be centralized so that the websocket connect is always cleaned up. The current behaviour is confusing as the delegate can get multiple websocketDidDisconnect:error: calls (for example if I receive an "Invalid HTTP upgrade" error, isConnected is still true and a few seconds later websocketDidDisconnect:error: is called again).

/////////////////////////////////////////////////////////////////////////////
//
//  JFRSecurity.h
//
//  Created by Austin and Dalton Cherry on 9/3/15.
//  Copyright (c) 2015 Vluxe. All rights reserved.
//
/////////////////////////////////////////////////////////////////////////////

This needs to be changed as it doesn't comply with your Apache 2.0 license.

e.g. how it is done in Starscream

//////////////////////////////////////////////////////////////////////////////////////////////////
//
//  SSLSecurity.swift
//  Starscream
//
//  Created by Dalton Cherry on 5/16/15.
//  Copyright (c) 2014-2016 Dalton Cherry.
//
//  Licensed under the Apache License, Version 2.0 (the "License");
//  you may not use this file except in compliance with the License.
//  You may obtain a copy of the License at
//
//  http://www.apache.org/licenses/LICENSE-2.0
//
//  Unless required by applicable law or agreed to in writing, software
//  distributed under the License is distributed on an "AS IS" BASIS,
//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//  See the License for the specific language governing permissions and
//  limitations under the License.
//
//////////////////////////////////////////////////////////////////////////////////////////////////

Files that need to be changed:

• Jetfire.h
• Jetfire-Mac.h
• JFRSecurity.h
• JFRSecurity.m
• JFRWebSocket.h
• JFRWebSocket.m
• AppDelegate.h
• AppDelegate.m
• ViewController.h
• ViewController.m

Each time I connect / disconnect, I see a new thread hanging, waiting forever in the disconnectStream method.

I do see a 'socket did disconnect, error: Error Domain=JFRWebSocket Code=1000 "continue frame before a binary or text frame"' logmessage, so it should be disconnected and stopped?

It seems to block on [self.writeQueue waitUntilAllOperationsAreFinished], which has 1 pending operation.
Does anyone have an idea how to resolve this?

jetfire has 5 leaks of Core Foundation Objects that are flagged up using the Static Anaylser.

I think most can be fixed using __bridge_transfer rather than simply __bridge

If self.isConnected == YES in dealloc, then the following line crashes in dequeueWrite:

__weak typeof(self) weakSelf = self;

objc[1409]: Cannot form weak reference to instance (0x6000000f6b80) of class JFRWebSocket. It is possible that this object was over-released, or is in the process of deallocation.

I'd like to request being able to use Pings to a server and having the server send a Pong back.

We'd then be able to handle the Pong with a callback.

https://github.com/koush/AndroidAsync
https://github.com/square/SocketRocket

I think both of these libraries support being able to use Pings.

Presumable its suppose to be set in -[JFRSecurity initWithCerts:publicKeys:] but self.certificates is only set no matter what the value of publicKeys

Good day.
I'm trying to use jet fire 0.1.5 on a project using iOS 7, but it won't let me do that, it highlights syntax errors on both JFRSecurity .h and .m files. I thought it supported iOS 7 and above.

Should I stick with 0.1.4?

The Jetfire API is not thread-safe, and it is not explicitly declared as such. Either add a note that instances of JFRWebSocket should not be accessed by multiple threads, or make the API thread-safe. My preference is for the later – putting the responsibility on the library, not the client.

Delegate Callbacks

Most of these occur on the private connection queue, not the specific delegate queue:
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L330-331
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L452-453
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L459-460
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L465-466
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L492-493
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L531-532
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L539-540
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L553-554

Unsafe Setters

In a few places, there are checks like if (!self.property) self.property = X;. These are not thread-safe because the setters are not atomic. A common very difficult-to-find crash occurs when two threads wander into such blocks and invoke the runtime-generated setter at the same time. The result will be a -release race condition – both threads can release the original value, and leak one of the new values.

https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L143-L145
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L625-626

Unsafe Mutable Access

This one is an edge case – addHeader:forKey: adds a value to the dictionary on an arbitrary client thread, while -connect triggers enumeration of the same collection on the private connection thread. The easiest way to fix this is to use an immutable copy of the collection internally.

Self-reference Cycles

More of a side-effect of multi-threading with blocks than a bug. Using self within a block creates a strong reference which has a few funky side effects. Particularly around deallocation behavior of the instance. For example, in dequeueWrite:, a strong reference to self is created and enqueued onto operation queue. This means that the instance will have a +1 retain count for each write operation and continue to live on – processing operations – after the client/app code has released it:
https://github.com/acmacalister/jetfire/blob/master/JFRWebSocket.m#L630

Most use of the self reference within async blocks should use a weak reference. You can check to see if the weak reference is nil at the start of execution, and (usually) safely retain it for the duration of the block. This should happen anywhere dispatch_async is used with self. Much written on this

We're seeing occasional deadlocks where jetfire is the only active thread. Any chance this starscream issue is also a jetfire issue? I'm guessing not.

daltoniam/Starscream#164 (comment)

I believe you need to call the onDisconnect() at the end of - (void)doDisconnect:(NSError*)error

Any plans for supporting WebSocket compression?

Some random links:
http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-13
http://stackoverflow.com/a/19300336/592463