

Square Releases Open Source WebSocket Client for Objective-C - mikelikespie
http://corner.squareup.com/2012/02/socketrocket-websockets.html

======
tlrobinson
Is there any reason to use WebSockets on native apps other than if you want to
share one server between native and web?

~~~
mikelikespie
I think it's the same reason you would want to use good old HTTP over raw
sockets for a request/response API, even though with a native client you
_could_ just invent your own protocol.

If you want bidirectional communication to your app, it's much easier to make
a server that uses the WebSocket Protocol (tornado, etc.) instead of rolling
your own server and protocol.

------
adamjernst
Thank god. I have worked extensively with cocoa-websocket and socketio-cocoa
and they are a complete mess.

Square has done a lot for iOS open source, with their unit test framework and
other libraries and now this.

------
saurik
So, following up on the link in another comment on this article [1] to
socket.IO-objc [2], one goes through a few forks of cocoa-websocket [3,4,5] to
arrive at zimt [6].

Are there reasons to use SocketRocket over these other libraries (either
socket.IO-objc, or the various forked lineage of cocoa-websocket/zimt)?

(Also, to ask the question I always have to ask: is there a reason for a new
library rather than contributing to one of the existing ones, possibly even
helping Unitt support RFC6455?)

[1] <http://news.ycombinator.com/item?id=3563527> [2]
<https://github.com/pkyeck/socket.IO-objc> [3]
<https://github.com/samlown/cocoa-websocket> [4]
<https://github.com/adamjernst/cocoa-websocket> [5]
<https://github.com/erichocean/cocoa-websocket> [6]
<https://github.com/esad/zimt>

~~~
mikelikespie
Cocoa-websocket doesn't seem to support the latest standard[1]. You can tell
because the handshake has key1 and key2 which is protocol 00[2]

Re: socket.IO, I haven't actually used it, so correct me if my assumptions are
wrong, but the objc client doesn't seem to use WebSockets as a transport. So I
imagine you can get the same bidirectional semantics if by using socket.IO-
objc if you want to limit yourself to servers written in node (or have a
socket.IO bridge).

However, why not go with standards? Since socket.IO supports websockets, the
objc implementation could be backed by SocketRocket easily.

My two biggest complaints against Unitt & cocoa-websocket aside from them not
supporting RFC6455 is having CocoaAsyncSocket as a dependency.

I've dug deep into it's implementation, and even had a prototype of
SocketRocket that used it (basically went from CocoaAsync to dispatch_io to
CFStream), and I'm not too impressed. Also, CocoAsync 2x or 3x more code than
the entire WebSocket implementation without it. It also has drastically
different codepaths for iOS and Cocoa and it's very difficult to see what's
going on. Makes testing more difficult.

The other reason I decided to roll my own is just a learning experience. At
first I wanted an excuse to play with new libdispatch io stuff[3].

[1] [https://github.com/samlown/cocoa-
websocket/blob/master/WebSo...](https://github.com/samlown/cocoa-
websocket/blob/master/WebSocket.m#L33)

[2] [http://en.wikipedia.org/wiki/WebSocket#draft-ietf-hybi-
thewe...](http://en.wikipedia.org/wiki/WebSocket#draft-ietf-hybi-
thewebsocketprotocol-00)

[3]
[http://www.opensource.apple.com/source/libdispatch/libdispat...](http://www.opensource.apple.com/source/libdispatch/libdispatch-187.5/dispatch/io.h)

------
dirtae
We are currently using UnittWebSocketClient in our iOS app to communicate with
a Tornado server:

<http://code.google.com/p/unitt/wiki/UnittWebSocketClient>

It has worked well so far, but I'm glad to see more activity in this area.

~~~
mikelikespie
The reason Unitt didn't work for us is that it isn't updated to work with the
latest WebSocket protocol. This is an issue, especially since there's finally
a standard (RFC 6455)

tools.ietf.org/html/rfc6455

Tornado is nice since it implements some of the legacy versions of WebSockets,
but there are many servers that will probably deprecate them sooner rather
than later.

------
chriseidhof
You guys are constantly pushing out cool stuff, just started using KIF and I
really like it. Thanks for open sourcing guys!

------
listrophy
Great to see this... I've been using libPusher, but it's specific to the
Pusher service (which is actually pretty great).

Perhaps libPusher can just start using SocketRocket as a dependency and wrap
it in Pusher-specific goodness...

~~~
mikelikespie
This would be cool. We've been experimenting with uses for WebSockets. One of
them is mocking push notifications in the simulator. The other is basically
implementing a pusher-like service with a pub-sub model.

~~~
djb_hackernews
Pusher-like service implementations are very easy, I know, I've built one[1]
and there are others[2]!

If you have any questions, feel free to email me.

[1] <https://github.com/danbeaulieu/PushPlay>

[2] <https://github.com/stevegraham/slanger>

~~~
mikelikespie
Rad! Somebody pointed out slanger to me previously, but I was unaware of
PushPlay. Thanks!

------
searching
If I'm using Socket.IO via an Obj-C lib, is there a point to taking a look at
this? Should the Socket.IO community look at integrating this as the engine
behind the client on Obj-C, or is there little/no benefit?

~~~
mikelikespie
I'm unsure what you mean by "Socket.IO via an Obj-C lib". Could you send a
link? It looks like Socket.IO is node (which I don't believe you can use in
iOS).

~~~
rgbrgb
Here's a link to a socket.io client library in Obj-C:

<https://github.com/pkyeck/socket.IO-objc>

------
llz
Does this get around the shitty reverse-proxies mobile providers set up that
kill websocket connections?

~~~
mikelikespie
I can't answer this yet. I'd be curious to hear

