request
Creating a communicating app: what to think about
14/02/12 18:44 Category: Software engineering | Network
There are a few things to remember if you intend to create a network using application.
First of all, never assume your link will always be up and running.
- What to do if you can’t connect to your network ?
- What about if you got disconnected ?
- How and when will you notice a connection failure ?
Secondly, always avoid synchronized request, even if it’s true they are easier to create than asynchronous one.
- You can’t really cancel a synchronized request, you can only either destroy the thread it is running on, or wait for a timeout.
- With the asynchronous way you can start working on the result before it has been totally retrieved.
Thirdly, reduce the quantity of data you need to send and receive to a minimum.
If an XML message is easy to create and read, it has also a poor efficiency regarding the quantity of information it contains for the length of the message. Regarding transmission efficiency, the best method is to work on raw data, without any encapsulation, but it’s also the worst method considering debugging. A good alternative is the use of JSON, quite light and still human readable.
The fourth point concerns protocols designing. If you are conceiving your own one, you should keep in mind it may be subject to updates. That’s why it is always a good idea to send a version number in your messages. It would be helpful for maintaining compatibility with older versions of your software that would still work with an older protocol.
This list isn’t exhaustive and will most certainly be updated.
First of all, never assume your link will always be up and running.
- What to do if you can’t connect to your network ?
- What about if you got disconnected ?
- How and when will you notice a connection failure ?
Secondly, always avoid synchronized request, even if it’s true they are easier to create than asynchronous one.
- You can’t really cancel a synchronized request, you can only either destroy the thread it is running on, or wait for a timeout.
- With the asynchronous way you can start working on the result before it has been totally retrieved.
Thirdly, reduce the quantity of data you need to send and receive to a minimum.
If an XML message is easy to create and read, it has also a poor efficiency regarding the quantity of information it contains for the length of the message. Regarding transmission efficiency, the best method is to work on raw data, without any encapsulation, but it’s also the worst method considering debugging. A good alternative is the use of JSON, quite light and still human readable.
The fourth point concerns protocols designing. If you are conceiving your own one, you should keep in mind it may be subject to updates. That’s why it is always a good idea to send a version number in your messages. It would be helpful for maintaining compatibility with older versions of your software that would still work with an older protocol.
This list isn’t exhaustive and will most certainly be updated.