Develop Reference

JAVA/ connect time out with socket binding

Two parts:
InetAddress ia = Inet4Address.getByAddress(new byte[]{(byte)192,(byte)168,(byte)10,(byte)100});
Socket socket = new Socket();
InetSocketAddress isa = new InetSocketAddress("82.146.58.81", 5277);
socket.bind(new InetSocketAddress(ia, 0));
System.out.println("local_address:" + socket.getLocalSocketAddress());
socket.connect(isa, 1000);
Thread.sleep(1000);
socket.close();
System.out.println("done_1");
InetAddress ia_2 = Inet4Address.getByAddress(new byte[]{(byte)172,(byte)20,(byte)10,(byte)2});
Socket socket_2 = new Socket();
InetSocketAddress isa2 = new InetSocketAddress("82.146.58.81", 5277);
socket_2.bind(new InetSocketAddress(ia_2, 0));
System.out.println("local_address:" + socket_2.getLocalSocketAddress());
socket_2.connect(isa2, 30000);
Thread.sleep(1000);
socket_2.close();
System.out.println("done_2");
First part of code worked, second not - java.net.SocketTimeoutException: connect timed out.
I am trying to communicate with the host "82.146.58.81" through different interfaces.
But only the part that has the default route is successful. Why?
Update: I am worked by Ubuntu 17.10, seems the same problem in Armbian too. Problem not reproducible under Windows7
Update: Wrong OUT interface:
[12979.049742] IN= OUT=enp4s0 SRC=172.20.10.2 DST=82.146.58.81 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=25967 DF PROTO=TCP SPT=48985 DPT=5277 WINDOW=29200 RES=0x00 SYN URGP=0
kostas#work:~$ ifconfig
enp0s16f0u1c4i2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.20.10.2 netmask 255.255.255.240 broadcast 172.20.10.15
inet6 fe80::17c7:4582:897b:11d5 prefixlen 64 scopeid 0x20<link>
ether 86:38:35:c8:f5:39 txqueuelen 1000 (Ethernet)
RX packets 575 bytes 117085 (117.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 686 bytes 82681 (82.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.100 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::80b9:8cf3:92c6:4aef prefixlen 64 scopeid 0x20<link>
ether 00:e0:66:ae:2a:de txqueuelen 1000 (Ethernet)
RX packets 100455 bytes 65543315 (65.5 MB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 75513 bytes 15658830 (15.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
kostas#work:~$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default unknown 0.0.0.0 UG 100 0 0 enp4s0
default gateway 0.0.0.0 UG 101 0 0 enp0s16f0u1c4i2
kostas#work:~$ ping mail.ru -I enp0s16f0u1c4i2
PING mail.ru (217.69.139.202) from 172.20.10.2 enp0s16f0u1c4i2: 56(84) bytes of data.
64 bytes from mail.ru (217.69.139.202): icmp_seq=1 ttl=51 time=508 ms
64 bytes from mail.ru (217.69.139.202): icmp_seq=2 ttl=51 time=187 ms

"However, many OSes do not honour this "hint" and will use the routing table anyway."
Answer here

Why UDP receive buffer size(rx_queue) is not increasing?

In my java server Application, 1000 UDP packets are coming per second. But my application can process only 100 packets/sec. So there are like 900 UDP packets/sec that my server can not process.
The server application is doing something like this.
while(true)
{
serverSocket.receive(receivePacket);
process(receivePacket); // takes around 50ms to complete
serverSocket.send(sendPacket);
}
From my understanding, those unprocessed packets are getting stored in OS's UDP receive buffer. when this buffer will become full OS will drop those packets.
But the problem is when I run the command to see my UDP buffer size.
cat /proc/net/udp
It shows that there is nothing stored on my UDP socket buffer
cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
4: FCA9C11F:C36F 8C719AC6:0035 01 00000000:00000000 00:00000000 00000000 0 0 2983494501 2 ffff880169aff4c0 0
5: FCA9C11F:D3F0 8C719AC6:0035 01 00000000:00000000 00:00000000 00000000 0 0 2983494485 2 ffff8801b9bbedc0 0
16: 7A52BB59:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 38 0 2438608536 2 ffff8807656764c0 0
16: A2EE0D55:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 38 0 2438608045 2 ffff88077ccdd7c0 0
16: A58F466D:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 38 0 2438607809 2 ffff8801129f6240 0
It shows there is no packet drop and tx_queue and rx_queue are 0 in size. So there are no packets stored in UDP receive buffer?
But if I take a tcpdump, then I can see that lots of packets a coming to the server and server can process only 10% all those packets. so the other 90% should be stored in the UDP receive buffer.
What am i missing or not understanding?

udp socket receive buffer size

I am use Netty ( a java network framework) to server UDP request .
I found the
SO_RCVBUF
and
/proc/sys/net/core/rmem_default
and
/proc/net/udp
output confusing:
By the manual of socket( man 7 socket) It explains :
rmem_default
contains the default setting in bytes of the socket receive
buffer.
rmem_max
contains the maximum socket receive buffer size in bytes which
a user may set by using the SO_RCVBUF socket option.
and the /proc/net/udp show's the udp receive queue size :
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
60: 00000000:2F3C 00000000:0000 07 00000000:0003E094 00:00000000 00000000 500 0 2224362 2 ffff810066908cc0
I can get the SO_RCVBUF = 12904, but the rx_queue size is 254100(3E094), and rmem_default is 262142
my confuse is, why the SO_RCVBUF not equals to the rmem_default, and why the queue size not equals the SO_RCVBUF (but larger than it ) ?
It seams the ctx.channel().config().getOption(ChannelOption.SO_RCVBUF)'s value is half of /proc/sys/net/core/rmem_default and the real receive buffer size( queue size ) is also the value of /proc/sys/net/core/rmem_default
so why ctx.channel().config().getOption(ChannelOption.SO_RCVBUF) not equals to the system's config ?

The accepted answer is wrong. The correct alignment is:
tx_queue rx_queue
00000000:0003E094
So rx_queue is 0x0003E094 or 254100. This can be confirmed using netstat -unlp | grep pid , Recv-Q is second column. Example output:
cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
8101: 41FD080A:06A5 00000000:0000 07 00000000:00005A00 00:00000000 00000000 1000 0 3892411 2 0000000000000000 0
netstat --udp -nl
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 23040 0 10.8.253.65:1701 0.0.0.0:*
Here, 0x00005A00==23040

You seem to have misread the output. When you line up the columns properly, rx_queue is zero.

Java SocketException Maximum number of datagram sockets reached

I have a java app program run on centos 6.3 and tomcat 7 as the app container, currently I meet one error : java.io.socketexception Maximum number of datagram sockets reached
we use MulticastSocket class to send message. when this error happened, I check the current server UDP socket count with command: ss -s
Total: 212 (kernel 248)
TCP: 70 (estab 15, closed 44, orphaned 0, synrecv 0, timewait 40/0), ports 22
Transport Total IP IPv6
* 248 - -
RAW 0 0 0
UDP 40 40 0
TCP 26 26 0
INET 66 66 0
FRAG 0 0 0
and I also check the
ulimits -n
The default setting is 32768, seem UDP socket count not exceed max count.
Any ideas for this error?

we use MulticastSocket class to send message.
Why? You only need a MulticastSocket to receive multicasts.
Obviously you are leaking MulticastSockets. Presumably you are creating a new one per message and never closing it.

SAR (System Activity Reporter) reporting more bytes than expected

I was using SAR for monitoring bandwidth in one of my projects and I was not sure if it is reporting correct data. So I wrote a very simple dummy program (in java) for testing it which opens a server socket, opens a client connection to that server socket. The server socket upon accepting that client connection, starts writing bytebuffer (of size 1) in a while(true) loop with 1 sec sleep between each iteration. Ideally, I would expect 1 byte transfer every second on the loopback interface in the "SAR -n DEV 1 100" output but what I see is following:
10:54:53 IFACE Ipkts/s Ibytes/s Opkts/s Obytes/s
10:54:56 lo0 2 113 2 113
10:54:56 gif0 0 0 0 0
10:54:56 stf0 0 0 0 0
10:54:56 en0 0 0 0 0
10:54:56 en1 0 0 0 0
10:54:56 fw0 0 0 0 0
10:54:56 vmnet1 0 0 0 0
10:54:56 vmnet8 0 0 0 0
Anyone who can explain this output ?
thanks,
sandeep

If you're using a TCP connection, you don't transfer just the bytes, you also transfer some header information for each packet. Also, the client will have to acknowledge each packet received.