SFML UDP problems

I have not used SFML at all.
Have you tried just using regular sockets/winsock?

You should ask on the sfml forums for this type of questions. I googled this for you:
http://www.sfml-dev.org/forum/viewtopic.php?p=18610&sid=c24ab365051831a354fc520255efe9e8

Oh right thanks. I was running both tcp and udp in my test @ same port.

So the solution was to use different port numbers?

My belief is that TCP and UDP port numbers are unrelated - the packets are multiplexed by IP protocol first and then the TCP and UDP protocol implementations multiplex over the port ranges inside the respective packets. There is no reason why the TCP implementation should even be aware of what ports are in use by UDP, and vice versa.

I suspect the problem was that the client was requesting a specific port to bind to, rather than picking a random port (typically by requesting the OS bind them to "port" 0). Can you confirm that this solution works.

Looks like neither my solution or yours work.

Packets stop arriving after few seconds. I've noticed however that it works in LAN. I've forwarded ports on both pcs that are over internet, so its not the case.

[font="arial, sans-serif"]Packets stop arriving? That implies that packets were arriving
fine until then. So the solution does work - in that for some time
packets are arriving, yes?

The problem of packets stopping is elsewhere, and probably unrelated.
It sounds like you have some timing issue in your program then, if it
works on a LAN and not otherwise - are you testing on localhost too as
well as over the internet? Are you sure that you are sending packets
when you say they are not arriving? Have you looked using network
monitoring tools to ensure that the packets are being lost by the
application and not dropped on the wire?

I've forwarded ports on both pcs that are over internet ...[/quote]
Only the server should need its port forwarded, again the client
should be picking a random port by asking the OS for port 0.[/font]

Packets stop arriving after few seconds.

You need to understand where the problem occurs.

client -> sender -> firewall -> internet -> firewall -> receiver -> server

Hook up WireShark or tcpdump at each of those arrows, and verify that data is flowing at each point. If you find a point where it isn't, you know where the problem is.

However, from the comment that "it works on LAN," I'm going to make a set of guesses:
1) You are using a wrapper for TCP sockets (not UDP)
2) You are writing "packets" to the socket on the sending side
3) You are reading "packets" from the socket on the receiving side
4) You expect each "send" to correspond to one "receive"

This is not the case in TCP. As soon as the network feels like it (data aggregation, packet re-transmit, smart proxy, etc), the "packet" will be concatenated with other packets, and then maybe split in the middle. A TCP socket is a stream, very much like a file on disk. The additional problem with sockets is that recv() may return less than you asked for, even when more data will come later, whereas with a file on disk, if you get less than you asked for, you know you're at the end of the file.

If this is, indeed, the problem, then I suggest that you read the [FAQ]. It answers this particular problem just fine! It also answers a lot of other questions you may be having or running into in the future.