Sending object over network

[Suzie999]

Hi all.

I'm working on a client server application, eventually to be a POS (point of sale) system.

The model is something like, client (till) does not have access to the database, instead it sends data to the server application, which in turn deals with the database and any other operations which might need to be carried out.

I have my rudimentary client server set up, so far as the server accepts connections from multiple clients.
So my next step is dealing with client sending data to the server, and in what fashion etcetera.

Say I have a class like so...

class Transaction
    {
        public int Type { get; set; }
        public decimal Price { get; set; }
        public decimal Paid { get; set; }
        public decimal Change { get; set; }
    }

I was thinking to send each variable in a different byte array and wait for acknowledgement before sending the next, but that seems a little to much, so then was thinking to put them all in a single byte array and send it once like that (not sure how I would do that incidentally, but that's something else)

Then, and now I'm getting to my question, I began to wonder if it is possible to send the object instance as a whole and cast it somehow at the server side, back to a Transaction class.

I'm probably making no sense, but I'm just after some suggestions, even regarding keywords and or terminology I should be using in my web searches to research the subject.

Thank you kindly for reading, as always. I appreciate your time.

[AssertNull]

EDIT: Below was my original post, before how little memory Transaction requires sunk in. I'm thinking now that the real issue might be Little Endian versus Big Endian and the internal storage of the data on each machine versus the very small amount of data to be transferred (32 bytes?).

You have this tagged with "tcp". What you don't mention is whether you are writing the low-level code that IMPLEMENTS TCP or you are writing the higher level code that USES TCP. For the latter, which is all I have ever done, you don't need to worry about ACKs and packets and how they are sent. I've never written any C# networking, but I have used TCP-based stream sockets to transfer messages in Linux. Splitting the message into packets, ACKing the packets, resending the lost or corrupt packets, reassembling those packets, all that is encapsulated/hidden from the methods I used because I didn't have to worry about that. I imagine whatever C# API you are using (assuming, again, that it's not low-level programming actually implementing TCP) would be the same. As for terminology, the "send" function from the sys/socket.h library talks about sending "messages", not packets (though the word "packet" is used). I have no idea what length the packets are. I don't need to know. I deal with "buffers", "buffer sizes", and "messages". The buffer will be filled in correctly on the receiving end if the socket send worked.

As for how much data to send in each message and what TCP-based protocol to use, you may have to do a little low-level snooping and some trial and error. You don't have to worry about packet loss to actually send the data, BUT depending on your resource demands, your need for efficiency, how much memory you can devote, latency, lag, bandwidth, etc., that might affect how you split the data you send into messages (not packets). For example, if you are live streaming music, you could send all the data in one TCP-based message, but that would be a really bad idea because the person on the receiving end would have to wait for the entire song to be sent to play any of it and you probably would not use TCP at all. On the other hand, if you were downloading a song, you would use TCP and could send the entire song as one message.

Overall answer: it depends, but from your overall description, I would imagine "send all the data at once". Transaction looks like it would all fit in one packet anyway (32 bytes max?). Is there more to this?

[AssertNull]

OK, thought about this a little more. You have a few options. One, send as XML where the outer tag is "Transaction" and you have four inner tags and the values are the text representation of the numbers. You then parse the XML on the other side and stick everything in the correct fields. Upside of this is that you don't need to care at all about the data types or internal storage or programming language on the other machine. Downside is that it's slightly more work to write the function to go to and from XML. Second option is send a text representation of the numbers separated by a space or 0 or whatever. You would need both sides to know what order the different fields are sending the data and you'd have to be very aware of any changes in the code as far as adding fields or changing the order of the storage, problems you don't have with XML. Third option, send as individual numbers. That's somewhat easy with integer, but perhaps not so easy with decimals. You have floats versus doubles versus decimals and who knows how it's all stored.

All in all, safest, most foolproof, most stress free way, convert Transaction to XML, write that XML to a byte buffer, and send as one message. I suppose things can still go haywire and one side could be sending in ASCII and the other side UTF-16 or whatever and not realize it, so make sure that's not an issue.

[Suzie999]

Thank you, that has given me something to think about, and xml never even crossed my mind.
Currently I am using system.net and system.net.sockets, and from those TcpClient class and NetworkStream and the likes, so no low level stuff, but I'm thinking of using the underlying Socket class, because I'm unsure if I can use AsyncCallback methods using TcpClient class.

The Transaction class above (which I believe to be about 52bytes) is just an example but in reality will not be much larger anyway.

I have been looking into what I mentioned in first post "put them all in a single byte array and send it once like that", and I believe the term I needed to know was 'data serialization' and seemed pretty neat since Socket.Send() takes byte[] as argument.

I am creating both server and client, so I am not under any restraints as to how to implement anything, although I may want to create a client app to be ran on an android device in the future, so xml might be a better option.

Thanks again for your comments and advise, I really appreciate it.

[pritaeas]

As opposed to XML, JSON is another option. Both are easy to read when debugging, JSON is only a little less bulky.