Environment: Linux 5.4.0-137-generic #154-Ubuntu 2023 x86_64 x86_64 x86_64 GNU/Linux
I have an application that receives UDP traffic. To receive the traffic I use the socket and join to multicast (MC) group with a specific source address.
I run two instances of my application on separated isolated CPU cores (which means they will not interrupt each other). They both join to the same MC group from the same source address (but with different multicast addresses). Then I am receiving traffic on both applications. When I close the first application with CTRL-C, socket which used to receive in this application is leaving from the MC group. And in the same time, I see a small number of dropped packets in the second application.
Sequence to reproduce drops:
Run application 1 and join socket 1 to MC group with source A
Run application 2 and join socket 2 to MC group with source A (the same)
Stop application 1 and socket 1 leave from MC group - at this time see drops in application 2 on socket 2.
This issue is not reproduced when I join/leave to MC group without a specific source address (means when I use any source IP_ADD_MEMBERSHIP/IP_DROP_MEMBERSHIP)
When I first stop application 2 and socket 2 leaves from MC group - there aren't any drops in application 1 on socket 1.
To join socket to MC group I use the function:
setsockopt(sock, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, ..., ...);
To leave socket from MC group I use the function:
setsockopt(sock, IPPROTO_IP, IP_DROP_SOURCE_MEMBERSHIP, ..., ...);
Also, this is not reproduced on Red Hat Enterprise Linux 8.1
Could please someone help me? Or maybe someone has any ideas on what can I check or in which direction I can dig deeper?
I also tried to run this sequence:
Run application 1 and join socket 1 to MC group without source address
Run application 2 and join socket 2 to MC group with source A - at this time see drops in application 1 on socket 1
Stop application 2 or application 1 and don't see the drops
Related
I've read a lot of theory about sockets and Client-Server connection on this forums but some points remains blurred or some answers does not satisfy me completely.
Also, i'd like my words to be confirmed, completed or corrected :
1)_ A socket is made out of IP source (IP of the Client), Port source (a port automatically and randomly choosen by the OS between 1024 and 65535), IP destination (127.0.0.1 ? Something i don't get here), Port destination (developper defined-by port for the server) and protocol type.
There may be something wrong in those lines already.
But considering it is true, how can the server differenciate two processes accessing the server from the same machine ? (Understand, how the developper can make any difference if he wants to prevent multiple access from the same machine).
The only difference would be the source port which is auto-filled by the OS. In this case, it would act like it was a totally different machine, right ?
2)_ I heard there was actually a pair of sockets. One generated by the Client, and one by the server.
Is there really a need for the server to have a second socket ? Is this socket a simple replica to keep a copy in the "Client currently connected"-list or is it a different socket, with different values ?
3)_ When does a Client should "disconnect" ? At each query ? At the end of some process ? Other ?
Thanks for enlightenment !
1)_ A socket is made out of IP source (IP of the Client), Port source
(a port automatically and randomly choosen by the OS between 1024 and
65535), IP destination (127.0.0.1 ? Something i don't get here), Port
destination (developper defined-by port for the server) and protocol
type.
I wouldn't say a "socket is made" out of those data points; rather a TCP-connection can be uniquely identified using just those data points:
1. Source IP - the IP address of the client computer
2. Source Port - the port number (on the client computer) that the client is sending packets from and receiving packets on
3. Destination IP - the IP address of the server computer
4. Destination Port - the port number (on the server computer) that the server is sending packets from and receivign packets on
5. Protocol type - what communications-protocol is in use (i.e. either TCP or UDP)
But considering it is true, how can the server differenciate two
processes accessing the server from the same machine ?
It can differentiate them because the 5-tuple (above) will be unique for each of the two connections. In particular, in the TCP packets the server receives from process #2, field #2 (Source Port) will be different from the value it has in the packets received from process #1.
The only difference would be the source port which is auto-filled by
the OS. In this case, it would act like it was a totally different
machine, right ?
The server can act however it was programmed to act -- but in most cases the server will be programmed not to care whether two client connections come from the same physical machine or not. To most servers, a client is a client, and a client's physical location is not that important.
Is there really a need for the server to have a second socket ? Is
this socket a simple replica to keep a copy in the "Client currently
connected"-list or is it a different socket, with different values ?
A socket is a just data structure that lives in a computer's memory to help it keep track of the current state associated with a particular network connection. Since both the client and the server need to keep track of their end of the connection, both the client the server will have their own socket representing their endpoint. (Note the difference between a "TCP-connection", which you can imagine as an imaginary/virtual wire running from one computer to another, and the two "sockets", which would be the imaginary/virtual connectors at the ends of that wire, that attach the wire to the client-program on one end, and the server-program on the other end)
3)_ When does a Client should "disconnect" ? At each query ? At the
end of some process ? Other ?
Whenever it wants to; it's up to the programmer(*). There are startup/shutdown costs to opening and connecting a new socket, but there is also some ongoing memory and CPU overhead to keeping a socket open indefinitely, so the programmer will have to make a design decision about whether he wants to keep sockets open over extended periods, or not.
(*) Note that in a modern OS, if the client program exits or crashes, the socket will be automatically closed and the connection automatically disconnected by the OS.
I am generating UDP packets on a 100 multicast groups on one VM Ubuntu 16.04 machine and subscribe to those groups on the other VM Ubuntu 16.04 machine. Both are on a HP server run by Hyper-V manager. The problem is that my application only receives 2 out of 100 groups. However, when Wireshark is capturing, the application starts receiving all messages.
I found several other similar questions like this one, where it explains that because Wireshark is running in promiscuous mode, it allows all packets to get through (through what?), and this explains why my application starts "seeing" them too. Thus, changing the Ethernet interface configuration to promiscuous mode allows the application to receive all the messages without running the Wireshark.
But what is the problem with the other packets that are not normally received? I tried to cross-verify the hex-dump of the "good" and "bad" messages and they don't seem to be different. The check sums for on the IP and UDP levels are correct. What else could be the problem?
Multicast ip range 239.1.4.1-100
Destination port 50003
Source port range ~33000 - 60900
firewall is disabled
EDIT:
It looks like when the application is subscribed to only 8 multicast groups, it works fine, however, if subscribed to more than 8, it receives only 2 (if they end on .7 or .8) or none, as described above. So, I would assume that the packets are correct. Could the problem be in the network settings? Or the application itself - need to find the bug in the script I did not write.
EDIT2:
I installed the ISO image on the other machine (Virtual box instead of HP Windows Server) and it works as it should. Thus, I assume my application works fine and all the ubuntu OS configurations are correct. Now I put all the blame on the Virtual Manager/settings. Any ideas?
It sounds as if you didn't tell the kernel about them.
See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
You have to use setsockopt with IP_ADD_MEMBERSHIP. And be sure to use the correct values for your local interfaces.
Scenario:
Process 1 creates a socket and subscribes to a multicast group using the IP_ADD_SOURCE_MEMBERSHIP option [Group: 224.0.0.30 Source: 192.168.0.1 Device:eth0]. Binds the socket to 224.0.0.30:5555.
Process 2 creates a socket and subscribes to a multicast group using the IP_ADD_MEMBERSHIP option [Group: 224.0.0.30 Device: eth0]. Binds the socket to 224.0.0.30:5555.
Both processes are running simultaneously on the same box.
A source with IP 172.10.1.1 sends a packet with multicast destination 224.0.0.30:5555.
Will process 1 receive the multicast packet? Or will it be filtered out by the kernel?
Thanks.
From man 7 ip:
IP_ADD_SOURCE_MEMBERSHIP (since Linux 2.4.22 / 2.5.68)
Join a multicast group and allow receiving data only from a
specified source.,,,
This means that your first process will not receive packets sent from source 172.10.1.1.
But reading further:
... This option can be used multiple times to allow receiving data from more than one source.
, which might be useful for you.
Happy Spring Festival - the Chinese New Year.
I'm working on server programming, and stucked in 10055 Error.
I have a TCP client application, which can simulate a huge amount of clients.
Hearing that 65534 is the maximum value of tcp client connections of one computer,
I use Asio to implement simulation client which start 50000 asynchronous tcp connects.
pseudocode:
for (int i=0: i<50000 ; ++i)
asyn_connect(...);
Development Environment is:
windows xp , x86 , 4G memory, 4 core CPU
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort=65000
The result is:
when connects come up to 17000 , 10055 Error occur.
I tried another computer ,the Error occur at 30000 connections, better but not enough good.
( the server app runs at another computer, also using Asio ).
The question is:
How to successfully start 50000 client connections at one computer?
Cou could try to do it more blockwise:
Eg. start with 10000 connections. As soon as 5000 connections were successful start the next 5000 async_connect calls. Then repeat that until you have reached your target. That would at least put less stress on the IO completion port. If it doesn't work I would try with even smaller blocks.
However depending on where the OS runs out of memory that still won't help.
Do you start asynchronous reads directly after the connect succeeds? These will also drain the memory resources.
I am a very beginner to WebSphere MQ world and this is what I'm looking for:
I have to create a simple system with 2 Machine (sender and receiver) to share messages on a queue:
PC 1 sender --> Queue --> PC 2 receiver
Both machines are Windows based and actually are on the same physical PC using virtualbox P1 (host) and PC 2 (guest)
Here is what I have done following online guides:
PC 1 sender:
Websphere MQ (full trial) installed
on MQ Explorer:
Queue Manager "QM.01" created
local Queue "Q.01" created with use=Transmission
channel sender "CH.01" created with queue=Q.01 and some doubts on connection which actually is 1414
PC 2 receiver:
only MQExplorer installed
try to create a remote queue manager with sender IP, 1414 port, and
CH.01 channel --> error 2539 (something wrong on PC 1 configuration
try to create a remote queue manager with sender IP, 1414 port, and
default SYSTEM.ADMIN.SVRCONN channel --> error 4036 (something wrong
with account authentication, I tryed to use the same "Adminitrator#PC
1" user. I've also tried to create the remote queue manager on PC 1
itself with the same result)
I suppose my error could be on PC 1 channel, its icon has a yellow or blue triangle and status=trying are not good.
Ps. forgive me if some setting name are not matching the English version, I have to translate them.
Now that I've been able to configure a remote QMgr on client PC I would learn how to write a simple program (maybe in Java) to read from a queue on the remote queue manager.
I've found a few guides but, before starting in Java, I tried to test amqsget and amqsput from command prompt.
There are no problems from the server machine (with Websphere full trial installed) but the console can't recognize the command from the client (with both Websphere client and MQ Explorer installed)
Where are my mistakes, or what passage have I missed?
When you have an application that needs to talk to a QMgr over the network, you create SVRCONN channels such as SYSTEM.ADMIN.SVRCONN. The application using a SVRCONN channel is able to open queues directly and put or get messages from them. There is no need to create a transmission queue or set USAGE=XMITQ in order for client applications to work.
When you have two QMgrs that need to communicate, you connect them using MCA channels. On the sending QMgr, these include SENDER, SERVER and CLUSTER SENDER. On the receiving QMgr there would include RECEIVER, REQUESTOR or CLUSTER RECEIVER channels. Any of the outbound channels (SDR, SVR or CLUSSDR) require a transmission queue.
In the example you described, there is only one QMgr therefore no SDR, SVR or CLUSSDR channel is required. You will need to use a SVRCONN such as SYSTEM.ADMIN.SVRCONN. You did not mention having defined a listener but apparently you did or else you would not have received a 2539 MQRC_CHANNEL_CONFIG_ERROR message. The reason you get 2539 is because you are attempting to connect with a client to a channel designed for QMgr-to-QMgr connections. The 4036 is because the configuration is incorrect.
Delete CH.01 and redefine it as a SVRCONN channel.
Alter Q.01 with USAGE=NORMAL
Configure WMQ Explorer to connect to CH.01.
As Shashi mentioned, take a look at some of the basic docs. These include...
Introduction to WebSphere MQ
Designing a WebSphere MQ architecture
The Quick Beginnings manuals have been broken up but the main sections are indexed here.
You may also wish to review the WMQ Security Lab for V7.1 and earlier posted at T-Rob.net. Although it is a security lab, it comes with scripts that build the lab environment, including SVRCONN and SDR/RCVR channel pairs, as well as an extensively illustrated lab guide.
Thank you for your response,
Following your indication I've understood I don't need two QMgr as I supposed,
but only one on the sending machine.
Therefore I have changed the query usage to normal, deleted the channel and leave other configuration by default:
SYSTEM.ADMIN.SVRCONN channel and LISTENER.TCP on 1414 port are automatically created.
I've tried also to redefine a channel named CH.01 as a SVRCONN channel
(Channel > new > server connection channel; and then choose between SYSTEM.ADMIN.SVRCONN, SYSTEM.AUTO.SVRCONN or SYSTEM.DEF.SVRCONN)
but unfortunately I wasn’t able to "Configure WMQ Explorer to connect to CH.01".
Anyway every attempt I have made to connect from the second PC are now ended with a AMQ4036 error; even if I’ve set in the CH.01 MCA Properties the ID user as my PC administrator and I have enabled the user identification on PC 2 as administrator#PC 1.
What I'm trying to achieve is to replicate an application used by company which receives data from a remote queue.
The queue connection specification given for test are: Server Name/IP, Port and Channel name.
This is the reason why I'm trying to replicate it creating a QMgr on the receiving PC, because when I tried with the default test information on my company machines it worked creating a QMgr with all the test queues avilable.
I'm now on holiday and I can't have more specific information about my company settings but I hope to be able to replicate a configuration like that.
Regards,
Flavio.