Home/ Questions/Q 7762397
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T14:23:30+00:00

Okay, so my goal is to build a easy to use protocol for sending

  • 0

Okay, so my goal is to build a easy to use protocol for sending data over tcp. basically, it would send a message, and an object(of unknown type) over tcp. To send, it would only require one method call and to receive it would only require one also.

So this is how I was thinking to format the “message”.

length_of_message – “A string that is a message” – length_of_Object – object

length_of_message would be a set number of bytes. along with length_of_Object.

the actual message string and the actual object would be of variable length.

If the actual class of the object wouldn’t be know, could I just declare it as a “generic object” somehow? and then get its class name from the “generic object” and the message would tell the receiver what to do with the object?

It would be simple if it was a constant object type but i want to be able use one send function and one receive function for ever object that needs to be send/recieved.

Any suggestions?

Thanks,
Andrew

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Make sure you aren’t reinventing the wheel (unless doing so is your primary goal).

    With that in mind, consider:

    • Implement and use the NSCoding protocol. It allows for the efficient archival of complexly connected object graphs, including cycles.

    • Instead of raw TCP, use HTTP. While it adds a bit over overhead in the headers, the body can be straight encoded data. More importantly, HTTP is ubiquitous. It routes through just about anything whereas other protocols might be blocked (think proxy servers).

    • Via HTTP, you can leverage compression. If one side of your communication pipe is an existing web server of some kind, it probably already supports gzip’d communication. Compressing an NSData (that would be the result of NSCoding) is trivial.

    • Alternatively, stick with straight plists.

    Unless you truly have some requirement that makes the above inviable, you are likely better off leveraging the above technologies instead of rolling a new one.

    With that said, what you propose is fine. I would add, possibly, a structure like:

    [HEADER][MSGID][LEN][TYPE][DATA of len][POST]

    Where the POST is a known sequence of bytes that the receiver can verify to make sure that, maybe, all the data was received correctly. Or you could go whole hog and integrate a checksum. Or sub-pieces could be repeated, as needed (i.e. [LEN][TYPE][DATA] over and over.

    • 0