0

I've been programming a library for both TCP and UDP networking and thought about using packets. Currently I've implemented a packet class which can be used like the C++ standard library's stream classes (it has << and >> for inputting and reading data). I plan on sending the packets like so:

bytes 1-8        - uint64_t as the size of the packet.
bytes 8-size     - contents of the packet.

But there's a problem. What if a malicious client sends a size measured in terabytes and random garble as the filler? The server's memory is filled with the random garble and it will freeze/crash.

Is it a good idea to let the server decide the maximum allowed size of the received packet?

Or should I discard packets and implement transferring data as streams (where reading/writing would be entirely decided by the user of the library)?

(PS: I'm not a native English speaker, so forgive my possibly hideous usage of the language.)

Hassedev
  • 621
  • 6
  • 17
  • You could always restrict the packet to 32 bits, or even 16. When are you seriously going to need a 64-bit packet size? – user207421 May 28 '13 at 01:05
  • @EJP I selected uint64_t, because I might want to send files bigger than 4 GB. Probably going to make uint32 and 16 available though. – Hassedev May 28 '13 at 13:18

1 Answers1

1

Yes, set a maximum allowed size on the server side. Set it so that the server won't freeze/crash, but not smaller. Predictable behaviour should be the highest goal.

Frank Kusters
  • 2,544
  • 2
  • 21
  • 30
  • Thanks for the answer, I'll accept it when I can. Would it be overreacting if the server automatically disconnected the client if it tried to send too big packets? – Hassedev May 27 '13 at 13:13