Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Any way to resolve local UDP port in SFML 1.6?  (Read 3886 times)

0 Members and 1 Guest are viewing this topic.

D

  • Newbie
  • *
  • Posts: 12
    • View Profile
Any way to resolve local UDP port in SFML 1.6?
« on: December 15, 2010, 01:48:16 am »
Hi. I'm starting out with SFML and the networking side of it. My question is following: Am I able to resolve the local port that is used by sf::SocketUDP? I took a look at the SFML2.0 api, which has this method, which will eventually return the port I'm after. But is there a way to do that in 1.6?

I'm a complete beginner what comes to networking, so I'll explain a little more why I think I need that port.

Server binds a port (in my test case 51337). When client sends something to that port, it sends it via another free port, which is assigned to it by operating system. Right? So if server returns something to client after getting the packet from client, it replies it to the port that the data came from. But if the client wants to receive that data that server just sent, it needs to bind the socket it's using. And because I cant resolve the local port, I'll need to manually bind some port, which causes problems if I run another client and it uses the same port.

Does my thinking make any sense, or am I completely lost? :D Thanks for advance.

(I'm using SFML 1.6, C++ and Mac OS X 10.6)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Any way to resolve local UDP port in SFML 1.6?
« Reply #1 on: December 15, 2010, 08:14:04 am »
You can't get this port in SFML 1.6.

But to solve your problem, you can try to bind your socket to port 0, I think the OS will give you a free port (not sure about that, though).
Laurent Gomila - SFML developer

D

  • Newbie
  • *
  • Posts: 12
    • View Profile
Any way to resolve local UDP port in SFML 1.6?
« Reply #2 on: December 15, 2010, 09:43:33 am »
Thanks for the answer. I tried binding it to 0, with no luck. Strange, I thought this was kind of a basic functionality, but I'll test the 2.0 out then.