I want to learn more about sending and receiving packets with Obj C. I want to learn more about packet IDs and types. Any ideas on some easy tutorials apart from the Apple Documentation?
Thanks guys!
Note: I do have basic knowlage of how to send packets. But I need to learn more about types and IDs. At the moment Im failing to make a login with login.minecraft.net.
Holy layer violation, batman!
I think what you really want to learn about is HTTP communication under iOS, not TCP/IP packets. In this day and age, there is no reason to dip down to TCP/UDP unless you are inventing a new protocol. For every protocol that exists with any popularity, there is a library that encapsulates it.
In this case, it looks like Minecraft is built on HTTP. Which is no surprise; unless your game needs realtime interaction, HTTP is a ubiquitous protocol that routes through anything.
Thus, I'd suggest you start with one of the HTTP programming guides.
Related
I'm completely new in the NFC field, I want to build an application by using Mifare classic 1K with ST25R3911B, For that purpose i have to make proper communication between them by which i can do communication between them(Like to read/write operation).
I'm getting success to read UID, but rest of the things i'm not understand like how to authenticate or which is the proper command by which i can do communication or shares information between them.
If anyone have experience or any knowledge regarding that please help me,
Any kind of help would be appreciated!
Thank in advance!
I haven't used this chip, but I see its datasheet says that it supports Mifare as a custom protocol that you need to implement yourself as there is no generic method that is handled by the chip itself. That would mean you will need to implement the protocol based on NXP documentation including proprietary cryptography that is used there. If its only your private pet project, you could probably get away with some reverse engineered implementation that is floating around the internet, but the right way to do it is to contact NXP and obtain the license. Probably a way easier solution would be to replace the chip with something already licensed by NXP.
I work at an IP camera company and we currently have an outdated CGI HTTP API interface. The CGIs are implemented in C.
I would like to learn and implement a new HTTP RESTful API so that the following type of things can be performed:
http://[ipaddr]/api/video/start
http://[ipaddr]/api/video/stop
I would like to write this RESTful API from the ground up in my spare time so I can learn this new skill.
I am very experienced in embedded C programming and Web technology front end (HTML, JS, CSS, etc), however, I would like to implement the link between the front end web UX and the application code (and/or web backend).
I would like advice on the current methods of implementing HTTP APIs. I really like to learn the 'right way' to do things before I start.
I have found that all the things I have seen such as OAuth, XAuth, REST, SOAP, implementation languages is a bit overwhelming!
Is there anyone on Stack Overflow that could provide a sensible path to learn these things? I'm very adept at self-learning but could just do with a few pointers in the right direction.
I would like to write whatever I can in C ideally as that would be the easiest way to get into the application code. However, if people recommend another language I'm happy to go with that if there are clear pros.
Get yourself a copy of Richardson and Ruby's RESTful Web Services (O'Reilly). They talk about how to design and implement RESTful services using several different technologies. It's so good you almost don't need anything else except RFC-2616 (HTTP 1.1) and Roy Fielding's original dissertation on REST.
There are a lot of great libraries to build on (depending on how much you want to learn directly). In the Java world, the Apache HTTP Client library is a good foundational layer. A REST framework like RESTlet automates much of the rest for you, making it relatively simple.
First, you've got to figure out what your webserver is going to be, something which is probably going to be driven by your choice of OS. Windows or Linux? Or something else?
If you're using Windows, you'll likely be using something like ASP.NET or WCF; there's good REST support in those, and you can easily find some good documentation. This will probably require implementation in a managed language, though, so expect a bit of learning curve from that.
If you're using Linux as your webserver, you'll probably want to use Apache as your webserver software, which would imply any number of different possibilities for server software; PHP, Python, etc. You can likely easily invoke C from those languages, although there are probably easier ways to do what you want than invoking C from there. Of course, Linux as a webserver gives you additional options for server software; you could always go with node.js and Express for your REST API; there's a bit of learning involved to do it well, but for blistering speed, it's hard to beat node.js.
start and stop are not resources but actions, and do not belong in a URL.
Instead you should use PUT or PATCH to send a boolean such as stream=true or stream=false to a URL like http://[ipaddr]/video (no need for /api/ either)
The client sends the new state, and the camera reacts. Once the state has been changed (video started or stopped) it responds with a 200, with the new state in the response body, or 204 with no response body. Or if the operation is lengthy, you can respond with 202 Accepted and no response body.
The same can be used to start and stop /audio streams.
For more info, please read http://weblogs.java.net/blog/mkarg/archive/2010/02/14/what-hateoas-actually-means
I fear I may be displaying my ignorance with this question, but here goes...
I would like to use WCF to implement interprocess communication between a .NET app and a third-party app written in Qt. The Qt app has a plugin architecture that, if I choose to, can be used to bootstrap some .NET classes to handle WCF cleanly at both ends, but I'd rather keep the codebase native and therefore I'm thinking of ways to make sure that whatever I send down the wire with WCF, I can reassemble at the other end using classes available in Qt.
Qt has a SOAP message class, so I figured the preferable solution - and the one that's closest to the one we've hacked together already - is to send SOAP messages and pick them up off a QLocalSocket. Question is, is it possible to force WCF to encode messages as SOAP over a NetNamedPipeBinding, and if so, is it wise to do so?
I'm feeling rather wary at this point that my question might not make complete sense due to my shaky understanding of the technology involved. If this is the case, please take the time to explain why instead of just saying 'no'.
edit #1: I figure an update is warranted, as I've investigated some and should report my findings.
Firstly, I have found that Qt is a pig. The QtSoapMessage class I mentioned, it turns out, doesn't exist in the current version, and is available only as an after-market source package that you have to compile yourself. It took me many hours of googling to find out why this wasn't working. The Qt documentation is utterly dreadful, Qt Creator is counterintuitive in the extreme, and I've all but lost patience with it so haven't pursued this idea any further as yet. Furthermore, it isn't obvious how exactly I am to pass the socket data into the soap message constructor, which takes a QDomDocument, whereas the API for reading XML from a socket uses a QXmlStreamReader or somesuch. There doesn't seem to be any conversion between them.
You actually have a different problem to the one you think you have.
WCF will by default exchange SOAP messages over the NetNamedPipeBinding.
However, the message exchange is layered over some Microsoft proprietary protocols for transaction flow, message framing and encoding, which means that if on the Qt side you pick up a byte stream directly from a QLocalSocket you will have a lot of work to do to implement these underlying protocols before you will be able to get at the SOAP infoset itself.
It is possible to configure the NetNamedPipe binding to remove some of these protocol layers, but not all of them - the framing protocol will always be there, for example.
You might like to read my blog for a lot more detail on this.
Is there a "smart" UDP protocol analyzer that can help me reverse engineer a message based protocol?
I'm using Wireshark to do the sniffing, but if there's a tool that can detect regularities in the protocol (repeated strings, bits of the protocol that are CRC/Checksum or length, ...) and aid the process that would help.
You are asking for a universal inference engine. The best way to try to recover the protocol (assuming you are in a jurisdiction that permits this) is to understand the underlying message transfer from the beginning of a session, and then trying to manually simulate the behaviour of each party through a sequence of ping-pong message trials. This way you develop an understanding of the message structures and their functioning.
Using the UDP frame boundaries is a good place to start looking for structure.
If you have no documentation, you will find that even if you gain a good understanding of the protocol, expect to be surprised many times during the project.
If you can, have your existing systems carry out exactly the scenario you need to use, and then simply replicate the same sequence with payload (and any checksum) changes only. This way you can possibly achieve the requirement without a comprehensive understanding of the protocol.
For an example of the effort in doing this you could look at a historical review of the Samba project at A bit of history and a bit of fun.
I'm considering using AMQP (using qpid) to enable a mixture of Python and Java services communicate with each other. Basic text messaging seems simple enough but, as with every other messaging technology I've investigated, that's where it seems to stop. Except for building instant messaging applications, I would have thought sending strings wasn't a particularly useful thing to do yet example after example demonstrates sending unformatted text around.
My instinct then is to use XML (de-)serialization or something similar (JSON, YAML, Protocol Buffers etc.) which has good library support in both languages. Is this a best practice and, if so, which (de-)serialization protocol would people recommend? Or am I missing the point somewhere and should be quite content sending small bits of text?
Owen, may I offer a few words about RabbitMQ.
AMQP is a binary protocol and you can certainly do much more than send strings around! Which Python client do you plan to use? We recommend Barry Pederson's client for most uses: http://barryp.org/software/py-amqplib/ You are most welcome to come to the RabbitMQ list and ask any questions you like about anything in relation to your post and the comments :-)
As James points out, JSON is goodness. RabbitMQ supports JSON-RPC over HTTP connecting to an AMQP back end. People also use RabbitMQ with Orbited for comet type apps.
In addition we are fans of, and support XMPP, and STOMP too which James invented. STOMP is handy for a certain class of messaging apps and RabbitMQ supports it for both direct and topic based routing. We've found it a fine way to interop with ActiveMQ, preferring it to JMS in that scenario.
I hope you find the right server for your use cases, and recommend you try out different combinations, for best results.
Cheers,
alexis
For what it's worth, I've been having a good experience using AMQP + Protocol Buffers.
If the sender is serializing the messages, you will probably need to include an id in the header so that you know how to de-serialize on the receiving side. However, this isn't too much trouble to accomplish.
XML or JSON are probably the easiest. Protocol buffers is cool but I'd treat it as an optimisation to think of later on if you really need to (as its a bit harder to use being essentially a binary wire format).
BTW you might want to look at Stomp rather than AMQP; its got way more client libraries and supported message brokers. e.g. Apache ActiveMQ which is way more popular than qpid or rabbitmq - or indeed any JMS provider would work just fine.