Your question is a little ambiguous. I think you are trying to say that you have one desktop app that has many external connections ("Users") using something else (Web browser?).
Otherwise you could mean that you have a desktop app that you are distributing to many users and it connects to a central server--but then what you really mean is that you want to test server performance so I'm guessing that's not it.
Anyway, if my first guess was right, this can be a kind of difficult program.
When I've had to do something like that, I wrote a program to simulate clients connecting and ran it on a different computer. This can work if your data is fairly simple.
If my guess is correct I might be able to offer you a few more tips--maybe if you posted a little more info
---------------------- Edit after comment
What I would do is try to come up with a minimal constant xml message you could send (like the one that you posted) then write a program to open a socket, send the xml and close it. You may have to handle the server response.
I've done this before, it might take a couple days to write a program to do it--the problem can be emulating multiple machines. I'd just try opening multiple connections from a single machine first and if that works you're good to go.
If not (Sometimes each "client" needs a different IP address) you can use Linux (this can't be done easily on windows) set up to act as though one box has different IP addresses. I think you even supply the IP address in your program as you are opening the port, but it's been a few years so this is a little wishy-washy.
Solution #2 (Mentally easier but manually intensive):
If you have a bunch of clients sitting around, you can drive your program with an interesting tool called "AutoHotKey". It's a hacky tool but it's awesome for driving GUI programs. You could record a single AHK script that loops and causes some action on the server, copy it to all the computers and start it running on each one.
There are also a bunch of Very Expensive Tools designed to manage this kind of test. You are getting into an area that I'd call one of the more challenging areas that professional QA people typically encounter.
If you get this to work, however you solve it, put it on your resume.