0

I am doing an application that will imply reading a lot of data sent to my socket.

The problem I have is whether if should I rely on the socket setReceiveBufferSize, put a big value there to hope that it will gather all the data that I have until I am able to process it, or use a BlockingQueue to put everything there and then process it from another thread that keeps pooling and processing data?

Also is it a bad design if I let the queue with the max number of elements? ( so I'm just telling it, "yeah receive as many element as you'd like"), I'm referring to the memory consumption if I will receive a really big number of elements?

Regards, Aurelian

aureliangtx
  • 317
  • 6
  • 18

1 Answers1

0

A large socket receive buffer is always a good idea, but for TCP windowing/throughput reasons, not because you may be slow reading. You should be aiming to read the input as fast as possible, certainly as fast as it arrives. The proposed BlockingQueue is a complete waste of time and space. If the socket receive buffer fills up, the sender will stall. That's all you need.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • The thing is, I also do some processing on the same thread that I read from the socket, and this is why I may not read as fast as possible. Regarding the stall phase, if the server is sending too much data, with this stall, where is the data being kept? I mean will I loose some data because of this stall? Thanks – aureliangtx Aug 25 '13 at 14:21
  • The data is kept in the socket receive buffer. That's what it's *for.* You won't lose any. – user207421 Aug 25 '13 at 23:08
  • What is the recommended size for send socket buffer and receive socket buffer? I mean some optimal values – aureliangtx Aug 26 '13 at 14:04
  • The socket receive buffer should be set to the bandwidth-delay product of the link, if you know it. That enables the TCP at the other end to 'fill the pipe'. The send buffer can be the same size, or more. – user207421 Aug 26 '13 at 22:24