1

As is usual these days I have a question about my networking adventures.

I'm building a UDP to TCP relay server, with some success, but the following scenario is an onion in my ointment.

Let me first explain how things work: - Server spawns, checks stuff and forks off to become a daemon. - A listener socket is created on a specified NIC and port. - This socket accepts incoming connections which are then expected to send a HTTP REST request to specify which multicast address they'd like relayed from the Linux server at hand. - This is then handled, et cetera :) That all works.

In fact it all works fine, until I tested the following:

  • Have 2 TCP output NICs, 1 UDP input NIC -> and thus 2 processes running.
  • Take 120 inputs from each (240 in total), both from an identical range of UDP addresses.

After the client application hits 120 and attempts to pull the same fast one on the next NIC, things go wrong in a sense that connecting to the mcast address (this code is proven to work and just fine) succeeds but no data is received. Much to dismay of client, but it gets worse.

After a bit the accept() call in the second process yields error code 24 (too many files) and it will keep doing this ad infinitum regardless of if I close all outstanding connections for both server processes.

However, if I stick to 120 inputs (I just have 120 multicasts available internally here) and put 80 on 1 server card and TCP NIC and 40 on the other, there's no trouble.

Regardless of my many recent bickerings with network stuff, I'm still novice as it gets, so anyone got some useful info for me?

Much appreciated, and if more details/info/code is needed, I'll happily supply.

nielsj
  • 1,499
  • 12
  • 24

1 Answers1

0

You're leaking connections somewhere. Make sure they get closed in all possible code paths when you read end of stream or get an error from them.

user207421
  • 305,947
  • 44
  • 307
  • 483