I have a question about the configuration.
I need to have in the same system linux two udpxy installed, one to read from one interface (enp1s0f0) and another from another (enp1s0f1)
I happen to only work on the interface that has the default gateway (enp1s0f0).
In the other I see through tcdump traffic but I can not get udpxy to serve it.


Log result for enp1s0f1:
2017-10-13 14: 56: 21.688070 CEST S (3183) udpxy 1.0-23.9 (prod) standard [Linux 4.4.0-72-generic x86_64]: / usr / local / bin / udpxy -S -a 192.168.89.225 -m enp1s0f1 -p 4222 -c 5 -l /var/log/udpxy-f1.log
2017-10-13 14: 56: 21.688098 CEST S (3183) Server is starting up, max clients = [5]
2017-10-13 14: 56: 21.688119 CEST S (3183) Setting up listener for [192.168.89.225:4222]
2017-10-13 14: 56: 21.688136 CEST S (3183) Setting low watermark for server socket [5] to [10]
2017-10-13 14: 56: 21.688146 CEST S (3183) Created server socket = [5], backlog = [16]
2017-10-13 14: 56: 21.688153 CEST S (3183) Entering server loop [pselect (2)]
2017-10-13 14: 56: 21.688157 CEST S (3183) Waiting for input from [2] fd's, NO timeout
2017-10-13 15: 00: 13.448825 CEST S (3183) No children exited since last check
2017-10-13 15: 00: 13.448859 CEST S (3183) Got 1 requests
2017-10-13 15: 00: 13.448869 CEST S (3183) Accepting new connection
2017-10-13 15: 00: 13.448892 CEST S (3183) Accepted socket = [6] from 192.168.89.249:49977 n = 1 / nmax = 16
2017-10-13 15: 00: 13.448901 CEST S (3183) Accepting new connection
2017-10-13 15: 00: 13.448912 CEST S (3183) Nothing more to accept
2017-10-13 15: 00: 13.448920 CEST S (3183) accept_requests: Sockets accepted: [1]
2017-10-13 15: 00: 13.448927 CEST S (3183) Waiting for input from [3] fd's, with timeout
2017-10-13 15: 00: 13.448937 SEST (3183) No children exited since last check
2017-10-13 15: 00: 13.448944 CEST S (3183) Got 1 requests
pre-process sockets [1]: 6
2017-10-13 15: 00: 13.448955 CEST S (3183) acting on accepted socket [6] (1/1)
2017-10-13 15: 00: 13.448963 CEST S (3183) Reading command from socket [6]
2017-10-13 15: 00: 13.448981 CEST S (3183) HTTP buffer [36 bytes] received
GET /udp/239.0.0.221:8208 HTTP / 1.1
2017-10-13 15: 00: 13.448994 CEST S (3183) Request = [udp / 239.0.0.221: 8208], length = [20]
2017-10-13 15: 00: 13.449002 CEST S (3183) Command [udp] with params [239.0.0.221:8208], tail [] read from socket = [6]
2017-10-13 15: 00: 13.449016 CEST S (3183) udp_relay: new_socket = [6] param = [239.0.0.221:8208]
2017-10-13 15: 00: 13.449110 CEST S (3183) Added client: pid = [3231], maddr = [239.0.0.221], mport = [8208], saddr = [192.168.89.249], sport = [49977 ]
2017-10-13 15: 00: 13.449134 CEST S (3183) process_requests: closing accepted socket [6]
2017-10-13 15: 00: 13.449147 CEST S (3183) Processed [1/1] accepted sockets
newly-accepted sockets [1]: -1
2017-10-13 15: 00: 13.449159 CEST S (3183) All accepted sockets processed
2017-10-13 15: 00: 13.449115 CEST S (3183) Client process = [3231] started for socket = [6]
2017-10-13 15: 00: 13.449166 CEST S (3183) Waiting for input from [2] fd's, NO timeout
2017-10-13 15: 00: 13.449186 CEST c (3231) min socket buffer = [65536], max space to use = [1500], Rmsgs = [1]
2017-10-13 15: 00: 13.449195 CEST c (3231) Setting up multicast listener
2017-10-13 15: 00: 13.449233 CEST c (3231) current receive buffer size is [212992] bytes for socket [2]
2017-10-13 15: 00: 13.449253 CEST c (3231) multicast-group [ADD]
2017-10-13 15: 00: 13.449261 CEST c (3231) Mcast listener socket = [2] set up
2017-10-13 15: 00: 13.449269 CEST c (3231) min socket buffer = [65536], max space to use = [1500], Rmsgs = [1]
2017-10-13 15: 00: 13.449277 CEST c (3231) Data buffer will hold up to [1] messages
2017-10-13 15: 00: 13.449287 CEST c (3231) UDP stream, RTP check enabled
2017-10-13 15: 00: 13.449306 CEST c (3231) socket 2: RCV timeout set to 5 sec, 0 usec
2017-10-13 15: 00: 13.449315 CEST c (3231) socket 2: SEND timeout set to 5 sec, 0 usec
2017-10-13 15: 00: 13.449323 CEST c (3231) current send buffer size is [87040] bytes for socket [6]
2017-10-13 15: 00: 13.449330 CEST c (3231) current receive buffer size is [212992] bytes for socket [2]
2017-10-13 15: 00: 13.449339 CEST c (3231) send buffer size set to [212992] bytes for socket [6]
2017-10-13 15: 00: 13.449360 CEST c (3231) Sent HTTP response code = [200], reason = [OK] to socket = [6]
HTTP / 1.1 200 OK
Server: udpxy 1.0-23.9 (prod) standard [Linux 4.4.0-72-generic x86_64]
Content-Type: application / octet-stream


2017-10-13 15: 00: 13.449381 CEST c (3231) Relaying traffic from socket [2] to socket [6], buffer size = [2048], Rmsgs = [1], pauses = [0]
2017-10-13 15: 00: 18.447120 CEST c (3231) read_buf: socket time-out on read2017-10-13 15: 00: 18.447126 CEST c (3231) read_data - EOF
2017-10-13 15: 00: 18.447159 CEST c (3231) Exited relay loop: received = [- 1], sent = [0], quit = [0]
2017-10-13 15: 00: 18.447185 CEST c (3231) multicast-group [DROP]
2017-10-13 15: 00: 18.447198 CEST c (3231) Mcast listener socket = [2] closed
2017-10-13 15: 00: 18.447224 CEST c (3231) Child process = [3231] exits with rc = [0]
2017-10-13 15: 00: 18.447320 CEST S (3183) * Caught SIGCHLD (17) *
2017-10-13 15: 00: 18.447334 SITE (3183) Waiting on exited children
2017-10-13 15: 00: 18.447349 CEST S (3183) Client [3231] ha

A cross-post for those running out of CPU juice. Yes, because I can.

Thanks to the measurements done by a client (in production, on FreeBSD 10 & 11), now I can state with assurance that running Gigapxy can optimize CPU consumption as much as 2.5 times, compared to udpxy. Dropping the load from 95% to 40% on peaks.

Feels good since I firmly believe that newer software should run faster on older hardware. Sorry, big firms, it's possible. ;)

Well, whoever voted for commercial support, thanks and good news: it's possible. As much as I like to promote my new products, I'm ready to assist the good folks with the old udpxy. Fees will apply.

In other words, feel free to request commercial support if you believe you truly need it. (As I told before, new features are another kettle of fish.) 

Sorry for the cross-post from the competing product (Gigapxy), yet here we are:

Holiday season is upon us (EU too, pun intended :)), so being in the jolly spirit I've reserved five perpetual Gigapxy licenses for FreeBSD 10.x (for up to 8 cores per hardware key) that, as the OS name implies, are free based on my evaluation of the request (I won't issue more than 2 per entity, sorry). The offer lasts until January 1st, 2016. Ho-ho-ho! :)

Post has attachment
Do you often handle a cases of transporting video traffic over large distances (your master source is +3000 km away from the bulk of clients)?  
-
votes visible to Public
17%
Quite often
50%
Rarely
33%
Never

Post has attachment
Is commercial (paid) support something udpxy project could use?
-
votes visible to Public
50%
Yes
50%
No
0%
Doesn't bother me

Tip of the day: if you're using -M (re-subscription) switch in your udpxy settings, try not to. If your subscription 'goes sour' within a time period, this is your network acting up: something is not right in your ISP's multicast settings or your own multicast routing. The -M is a temporary measure (a "clutch"), don't rely on it.

Udpxy has been sub-licensed to Zyxel. This essentially means that I granted Zyxel Corporation the rights to modify the source code at will and use it for commercial purposes. This does not make udpxy a commercial product, neither does it change the licensing terms to the rest of the world, including some similarly-sized players (Asus) - it's still GPLv3 for you.
Wait while more posts are being loaded