I have tried, unsuccessfully, to use websockets in objective-c with the following two libraries:
http://code.google.com/p/unitt/wiki/UnittWebSocketClient
https://github.com/zootreeves/iOS-WebSockets
In both cases I was unable to establish even a basic connection to a server (runnning on localhost). I was wondering if someone could please provide or point me in the direction of some code that will just simply connect to a server via a websocket and/or perform a handshake.
Ideally, it would be nice if the code could use one of the above libraries, but at this point I'm open to anything that'd work.
I've posted about some issues with UnitT beore but I haven't received any feedback so I'm not sure exactly what step I'm messing up on. Appreciate any help, thanks!
We just released SocketRocket. It supports the latest standard, RFC 6455, which neither ZTWebSocket, nor Unitt does. No CocoaAsyncSocket needed to boot.
Also, libPusher is experimenting with SocketRocket too.
The libPusher library uses the ZTWebSocket object. And we have a number of clients who've developed iOS applications against our service. So, the ZTWebSocket object works and should be a good starting point. The libPusher library would be a good reference for usage.
The key to making UnitT work is to find out what version of the specification is your server running. Then you use the correct version for the client. The latest (rev17) of the specification FINALLY allows for multiple versions and having the server send back an appropriate response, but none of the prior versions do. Therefore, you may not receive a meaningful error from the server, just a disconnection. Do you know what version your server is running?
Related
The GWT RPC mechanism is great for client initiated communication. We're looking for a solid, supported way to do Push notifications from the server to the clients. All the solutions we can find are several years old and don't seem to work with newer versions of Eclipse and GWT.
We're prepared to use the Google App Engine if that helps.
We can roll our own socket code if that helps, as well, but we are Java developers. Writing JavaScript to do socket work would be a last resort, although if that's what it takes and there are examples we could probably handle it.
Any pointers to sample code or suggestions as to packages to use are greatly appreciated.
You could use the Atmosphere Framework. They have a gwt20 module which works great with gwt.
As far as I know there are two possible solutions.
First you can use Errai. Errai has an event bus which also can be used on the server:
https://docs.jboss.org/author/display/ERRAI/Messaging+API+Basics?_sscc=t
I did not use it, but think it is possible to do server push.
The second framework I know is gwt-comet:
https://github.com/rzschech/gwt-comet
I did not use one of them. But if I would look for a server push solution, I would give gwt-comet a try.
While this sounds silly, I haven't been able to find a way to get the IP of the client in Play 2.0. It was available in 1.2.x as Http.Request.remoteAddress, but 2.0 (I primarily checked the Scala API, but I did a quick check of the Java one too) only seems to provide information about the server side of the request in play(.api).mvc.Request. Is there something I'm missing? The closest hack I can think of right now is setting it up behind a reverse proxy and then checking X-Forwarded-For, but this doesn't work too well in dev.
EDIT:Coming back to this answer, this was added in playframework 2.0.2: see release announcement on https://groups.google.com/forum/#!msg/play-framework/Z97GQ2VnR5M/T-STGaeuN68J%5B1-25%5D and more importantly the API documentation at http://www.playframework.org/documentation/api/2.0.2/scala/index.html#play.api.mvc.Request
As you can see there is now support for Request.remoteAddress
Original:
There is currently a bug open for this in the tracker: https://play.lighthouseapp.com/projects/82401/tickets/256-add-back-requestheaderremoteaddress
I think that hacking the play2.0 libraries to include the linked patch is currently the best bet. It is probably still cleaner than to use a proxy with the sole purpose of adding XFF headers, and using those to determine the IP.
Please check this Github project at https://github.com/orefalo/play2-xforward
I took the code from Play1 and ported it to Play2, it should work the same.
Still a work in progress...
I am new to Blackberry app development. I need to call REST webservice from blackberry application using JDE 4.7. I searched but not got any solution. Anyone help pls?
sri
You have to make an HttpConnection request and read the data as an InputStream... have a look at this tutorial Calling REST based web services
I appreciate this an old post - but it has been updated so someone is looking at it, so I thought it appropriate to contribute.
I am sorry, but I can not recommend the code supplied the link from another answer called "Calling REST based web services".
I have made a comment explaining this on the site, along the following lines:
"In my opinion this code is flawed because it does not consider the different connection methods, nor does it consider different encodings. More over it does not consider the Event Thread or provide reasonable error checking and logging. I appreciate that this is just a sample, but I think the author has a responsibility to make people who might use this code aware of how it should be used properly. And this code will cause more problems that it solves. Refer to the supported BlackBerry documentation and web sites for better samples."
Sorry, I am not as familiar as I should be of the questions asked on stackoverflow, but questions like this come up regularly on the BBRY forum here:
http://supportforums.blackberry.com/t5/Java-Development/bd-p/java_dev
I recommend that you go on that forum and type network in the Search box on that site and you be presented with a range of tutorials and KB articles that discuss all aspects of networking. In this particular case I would recommend this:
http://supportforums.blackberry.com/t5/Java-Development/What-Is-Network-API-alternative-for-legacy-OS/ta-p/614822
Networking is not trivial on the BlackBerry, do not expect a cut and paste of the code supplied to work for you. Specifically you should be aware of:
a) The various connection methods, the costs associated with each and the impact that using each might have (e.g. transcoders or caching)
b) The Event Thread, how to get off it and back on when processing a response
c) Logging and reporting so that you can investigate problems when they occur (and they will).
Personally, given that all OS 4.7 devices can be upgraded to OS 5.0 and should be, since OS 5.0 is better, I would forget supporting OS 4.7. Instead look at OS 5.0 and above support and use ConnectionFactory.
I'm looking to respond to an event from a web browser, hopefully any web browser. I'm working solely on windows and I came to the conclusion a custom protocol (I.E. myprot://collection/of/strings) is the best approach here (any objections?). But, handling an instance of this protocol seems to be a little less straight-forward. All I need is that collection of strings auto-magically passed to my already running application! (the app will only respond to these links while in a specific waiting state)
So answer me this, if you can, Whats the 'popular' method of handling them or better yet Whats the 'best' (subjective - I know) way to do it?
Although your answers don't need to be specific to my language, I am using Delphi for development.
Thanks!
Why not use the regular urls? http://localhost/myhandler/collection/of/strings. To the best of my knowledge custom protocols only work for IE and you still need to install the handler on the client computer.
In the past I used custom protocols in one of my projects to support laptops working offline, but it was back in the time when installing IIS on a laptop was a call for trouble. but now - what's the point?
I want to try developing an XMPP server component using XEP-0114: Jabber Component Protocol.
Which server do you recommend and why? I'm talking about ease of development, community support, documentation, examples, etc.
That's a hard question to answer, because I doubt there are many developers involved in developing across multiple XMPP projects and languages.
I can throw out a few personal perceptions but... I could be off-base!
What you're really looking for is which libraries would be recommended for component development. All the servers support the component protocol, so all you really need is a socket connection to the server and some helper routines to make the repetitive stuff like message parsing easier.
Where the server might matter is if you need tighter integration.
For example if you want your component to scale the same way as Ejabberd then you'll probably want to use exmpp.
If you need to deploy your component alongside Openfire into Java only enterprises, then you'll probably want to use smack.
If you are familiar with Python and want to prototype quickly use Wokkel.
I don't think documentation is going to be great for any of the libraries (haven't looked at them all though!) but that shouldn't be a huge burden. All you really need a good book on how the XMPP protocol works and then some sample code from the library and it's fairly easy to move on from there.
For an easy-to-use testing server I like openfire. Good instructions, easy to hook in components, and a good web interface for administration. Debugging is more of a "tail -f" on the logfiles, slightly java-ish.
I've used XCP professionally, but that's really for commercial use. It works well but if that's not your target deployment it's not worth the effort. I'm not sure if you can buy it separately any more.
I tried using ejabberd and I gave up quickly. I found the documentation for setup and administration awful. The config files are not self describing and there's no good walk through on the ejabberd site. It may be able to even fry my eggs in the morning for breakfast, but I couldn't get past install with the time I'd allotted to it.
For Openfire, there is something called Whack, which is a Java library for creating server components (XEP-0114).
Since the communication is over sockets, I presume the same code should work for any well designed XMPP server (such as ejabberd). However, I have only tested it with Openfire and it works quite well.