IP modules are not prepared to accept datagrams of more than 576 octects according to RFC791 and ethernet MTU is 1500 octets. Are packets fragmented according to Ethernet MTU or IP MTU.?
From what I'm reading, rfc791 requires 576 for an ip module as the "minimum" buffer size for an incoming ip packet/fragment.
All hosts must be prepared to accept datagrams of up
to 576 octets (whether they arrive whole or in fragments).
IP Fragmentation in general is according to 1500 which is the default MTU of ethernet.
Beware that some vendors support ethernet jumbo frames which can go up to 64k in frame size.
Related
Lets assume Host X has a UDP Socket running on Port 1337.
Now Host Y and Z both send a UDP Packet to port 1337 of Host X.
Are the packets going to be de-muxed?
UDP is a transfer protocol with no guarantees of delivery and doesn't have much of an implementation.
When both host Y an Z send a UDP packet to port 1337, and assuming both packets arrive, the application listening on port 1337 decides what happens with those packages. The application can choose which packet to demux, to demux both or to demux neither.
Hope this clears things up
I setup turnserver 3.2.5.9 for WebRTC
I'd like to do this.
Client-A-->(TCP)-->TURN-->(UDP)-->TURN-->(TCP)-->Client-B
I have tow problems each Client-A and B ,both in different private network each other.
For the Client-A's issue.
The TURN server responds candidates for host srfix relay.
I'd like have a relay candidate as tcp.
However,I only can have udp .
How can I have a relay candidate as tcp.
For the Client-B's issue.
The TURN server responds only host.
So, the Client-B can't have any access to the TURN server.
FW policy, which Client-B is placed, is strict that it isn't allow to use UDP.
However, I think It should access to the TURN server by TCP.
Does anyone know how to tell the TURN server about Clients' Global IPs and TCP ports in both cases.
Here is turnserver.conf
listening-port=80
listening-ip=my-server-global-ip
external-ip=my-server-global-ip
lt-cred-mech
userdb=/opt/turnserver/etc/turnuserdb.conf
realm=my.server.domain
stale-nonce
no-udp
no-stun
Here is Response from Trickle ICE tool at the Client-A
Time Component Type Foundation Protocol Address Port Priority
0.015 1 host 2508812977 udp 10.2.1.17 53175 126 | 32542 | 255
0.059 1 srflx 3607399481 udp Client-Global-ip 53175 100 | 32542 | 255
0.086 1 relay 1628315121 udp my-server-global-ip 54043 1 | 32542 | 255
0.116 1 host 3674902081 tcp 10.2.1.17 9 90 | 32542 | 255
39.827 Done
39.833
Here is Response from Trickle ICE tool at the Client-B
0.012 1 host 1197209968 udp 192.168.95.131 60019 126 | 30 | 255
39.819 Done
39.823
WebRTC does not support allocation of TCP relay candidates.
Note that you can still have TURN/TCP candidates which use TCP between the client and the TURN server, those will have a local type preference of 1 which you can see in the trickle ice tool output.
You need to re-configure TURN server with TCP protocol option. Kurento and Wowza support TCP protocol for WebRTC.
I have an application that sends logs to a log server residing on a different machine. These logs are sent as UDP packets. My problem is that i see UDP log loss. I have a running sequence number in the UDP packets which is printed along with the log message. I saw gaps in the sequence numbers at the log server. At first i suspected my log server to be the culprit but looks like the problem is at the sender machine dropping packets. The environment is:
Both sender and receiver running on HP G8 servers with CentOS 6.4 (2.6.32-358.el6.i686). Here are the things that I have already tried or observed:
The SndbufErrors and RcvbufErrors are 0 both on sender and receiver (/proc/net/snmp)
The ifconfig does not show any errors
The switch to which these machines are connected does not report any drops/erros
Running tcpdump on the sender side (with increased buffer for tcpdump so that the tcpdump reports 0 packets dropped) reveals that the packets missed by the receiver are infact not sent (or at least those packets does not show up on the captupred pcaps)
The maximum rate of the packet's sent is around 30K per second (the rate is not constant. normally it stays at very low around 500 per second with occasional spikes. The packets are lost during these spikes). The interface is 100Mbps link.
The size of the packet varies from around 80 bytes to 300 bytes.
The ring buffer on the NICs are:
Ring parameters for eth0:
Pre-set maximums:
RX: 2047
RX Mini: 0
RX Jumbo: 0
TX: 511
Current hardware settings:
RX: 200
RX Mini: 0
RX Jumbo: 0
TX: 511
NIC driver info:
driver: tg3
version: 3.124
firmware-version: 5719-v1.38 NCSI v1.2.37.0
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
The NIC stats also shows no errors (throug ethtool -S eth0)
If i run my log server on the same machine as sender, there is no log loss.
I am clueless as where these packets are getting dropped (stack/NIC/NW...). I know UDP is un-reliable and packets can be dropped due to multiple reasons. But I am not still not able to find that reason as to why these packets are being dropped in my case at the sender side. On a different sidenote my application has also many TCP connections (around 8-10) with traffic on each connection.
SO_SNDBUF and SO_RCVBUF are difined as per socket buffer size.
But in case of UDP server socket does that means that its overall size for all destinations communicating with that socket , or its a size of single connection from remote address.
Example:
User A is sending data from 3.3.3.3 Port 50000 to server 1.1.1.1 on port 1234
User B is sending data from 4.4.4.4 Port 50000 to server 1.1.1.1 on port 1234
User C is sending data from 5.5.5.5 Port 50000 to server 1.1.1.1 on port 1234
There is single server socket as you see.If SO_SNDBUF and SO_RCVBUF are set to 32KB does that means that total send buffers size and total receive buffer size on server would be 32KB or 96KB?
In the case of UDP, there are no connections, so 'single connection from remote address' has no meaning.
In UDP, destination IP and destination port number are used to demultiplex the packets, but in TCP destination IP, source IP, destination port number and source port numbers (4-tuple) all needed to distinguish between the connections why reasoning for this usage.
This is entirely due to the fact that UDP is connectionless - it doesn't have any concept of connections, so it is only the destination address that matters.