Sign in to follow this  
Nethfel

sdl_net udp_bind question...

Recommended Posts

Hi all, I'm hoping someone could point me to something I've yet to find :(... Basically, I've found quite a few tutorials and sample programs when it comes to base TCP connections and base UDP connections - and they've been tremendously helpful. I was wondering if anyone knew of any tutorials or commented sample source that uses the sdlnet_udp_bind. I did look at the sample code, and it does make sense to a point, but I was hoping to see maybe a sample chat client/server that utilizes the bind functionality with the ability to have multiple clients connect simultaneously ('m not talking multiple chat rooms or anything like that, just a general single space with channel binds so maybe I can understand a bit more how binding works on both client and server side)

Share this post


Link to post
Share on other sites
I was a super noob too... :(
I know SDL_net is very hard to find tutorial and tutorial are useless--I have experience...
You can make modify on this code:
http://gpwiki.org/index.php/SDL:Tutorial:Using_SDL_net
I believe you have read this...
Now I tell you how I write the code,this is a pseudo code of chatting server.(Don't know if this is noob way):

Client:
1.Open a usable port. If 65535 not works,use 65534,then use 65533 and so on.(Don't know if this is good way.)
2.resolve host,the port in SDLNet_ResolveHost must same as port that server opened,and host too.
3.send packet, packet data is 12345(Do it with SDlNet_Write16())
4.wait a packet that data is 54321,if cannot recieve,go back to step 3.(avoid data-loss)
5.send the port that you using to server(You have to record the port in step 1)
6.chat
7.close connection

Server:
1.Open a port
2.wait for packet
3.receive packet
4.if packet data is 12345,change to reading mode{
5.wait for packet that data is a port
6.resolve host(Name:test[client_num] Host:NULL port:Use what client sent)
7.SDLNet_UDP_Bind(socket, client_num, test[client_num]); client_num++;
8.send a packet that data is 54321, change to normal mode
}
9.Receive what client said,send to every client with channel
10.close connection

Here is some tips:
1.Use one packet only(Don't know why it cannot work with multi packet.)
2.Use SDL_Delay to make a delay to save CPU.
3.Don't forget to use "packet->len = sizeof(packet->data)+1;"
4.Try to do the above pseudo code yourself(If I give my code to you,you learn nothing),you may need to modify it when need.

**I am still new to SDL_net.Again,I don't know if this is noob way(but at least it works :p).

Hope it help.Do not afraid to ask when you need more help :)

Share this post


Link to post
Share on other sites
Quote:
Original post by game over
I was a super noob too... :(
I know SDL_net is very hard to find tutorial and tutorial are useless--I have experience...
You can make modify on this code:
http://gpwiki.org/index.php/SDL:Tutorial:Using_SDL_net
I believe you have read this...
Now I tell you how I write the code,this is a pseudo code of chatting server.(Don't know if this is noob way):



Hey, thanks for your reply. The pseudo code is fine - I deal with it regularly (and many times that regularly is just dealing with instructions from my boss lol :) )

Now, I want to make sure I understand a couple of things if you don't mind...

Quote:

Client
3.send packet, packet data is 12345(Do it with SDlNet_Write16())
4.wait a packet that data is 54321,if cannot recieve,go back to step 3.(avoid data-loss)
5.send the port that you using to server(You have to record the port in step 1)
.
.
.
Server
4.if packet data is 12345,change to reading mode{
5.wait for packet that data is a port
6.resolve host(Name:test[client_num] Host:NULL port:Use what client sent)
7.SDLNet_UDP_Bind(socket, client_num, test[client_num]); client_num++;
8.send a packet that data is 54321, change to normal mode


Unless I'm misreading here - you've sent 12345 to the server, the server is now in reading mode; but the client is waiting for 54321 to continue on - looking at it, it seems step 4 and 5 should be swapped on the client portion of the activity.

Then, once on the server the client is bound to a given channel - the data that comes in will show their channel in
packetData->channel

I so from the server side if it's from an address that isn't already bound to a channel, that packetData->channel == -1 so I can use that for easy filtering.

In this particular case, the server is using the bind functionality, but the client is not. On the client side, I was reading in the docs about SDLNet_UDP_Send - when I fill out a packet - if I have bound the server to a given channel, can I just fill in the channel and not worry about the IP address (ie: do you know if SDLNet_UDP_Send will fill in the dest IP address if you just send by channel) or do you still need to fill out the destination IP address?

Thanks again, what you've given so far has been a tremendous help!

Share this post


Link to post
Share on other sites
I don't really like SDL_net, because I feel it doesn't give you much over basic Winsock/Berkeley sockets. I think you're generally better off just learning basic sockets. If you want a high-performance platform-independent wrapper, I recommend boost::asio.

That being said, something in your reply made me react a little bit. Servers and clients should not be in "reading" or "writing" modes. Servers and clients should always be on the look-out for packets arriving (a packet arriving from the network will be buffered by the network stack until you ask for it with recv()). Similarly, they should also always keep the "action" going, by pumping the window event loop, running game simulation, etc. Thus, packets arriving generally should be treated as "events" within the game, or perhaps a data stream similar to a gamepad input. And packets going out should generally be scheduled on some regular schedule, so that you can manage the amount of bandwidth used.

Perhaps you're already doing this, but if not -- the sooner you learn this way of programming, the better!

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
I don't really like SDL_net, because I feel it doesn't give you much over basic Winsock/Berkeley sockets. I think you're generally better off just learning basic sockets. If you want a high-performance platform-independent wrapper, I recommend boost::asio.


I had used basic sockets a long time ago, but honestly, I prefer a wrapper to take care of the dirty work, and although I could probably write one (granted it'd take some time to get back up to speed as I haven't coded using sockets in like 8 years), I prefer to not re-invent the wheel - plus the last program set I wrote w/ networking was a client/server where there wasn't a constant stream of data I had to worry about keeping up with - plus (if I remember correctly) it was TCP and not UDP, so UDP is new to me overall :).

You may be right that sdl_net doesn't offer enough to be worth while, I am at this point experimenting with it to see if I like it at all, but just needed some clarification on things. My original goal with my post was to better understand what/how sdludp_bind functionality works :)


Quote:

That being said, something in your reply made me react a little bit. Servers and clients should not be in "reading" or "writing" modes.


Not sure if you're saying this to me or to the original replier - yes, I know that they should be on the look out for packets as you describe below - in my case, I was simply using the repliers terminology to make it simple for him/her to reply back since that's the terminology they used - plus as this was a simple chat server/client example, there's no real action to worry about in terms of running the loops. But you are right, terminology is important, and I should have used better terminology in my reply.

I figured once I found the networking library I wanted to use, and felt comfortable with it, I would then work on integrating the I/O into passing its data into the event stack of the ultimate game (although, I'm happy to admit, there is a lot of experimenting and understanding I'll have to experience before I get to this point)

Quote:

Servers and clients should always be on the look-out for packets arriving (a packet arriving from the network will be buffered by the network stack until you ask for it with recv()). Similarly, they should also always keep the "action" going, by pumping the window event loop, running game simulation, etc.


Very true, and a valid point.

Quote:

Thus, packets arriving generally should be treated as "events" within the game, or perhaps a data stream similar to a gamepad input. And packets going out should generally be scheduled on some regular schedule, so that you can manage the amount of bandwidth used.


This is a good point - I hadn't gotten to this stage yet, and I had thought about bandwidth control (basically about how many outbound packets/s) but I hadn't really considered implementation.

Thanks for your input!

Share this post


Link to post
Share on other sites
Quote:
it seems step 4 and 5 should be swapped on the client portion of the activity.

No. When server running step 4,client can running otheer step.
Quote:
In this particular case, the server is using the bind functionality, but the client is not.

We only need to bind on server because client only need to send packet to server so we no need to bind in client.
Quote:
I was reading in the docs about SDLNet_UDP_Send - when I fill out a packet - if I have bound the server to a given channel, can I just fill in the channel and not worry about the IP address

I had such idea too but it not works... :(
because channel in client and channel in server are not same!
It is mean if you sending a packet in client with channel 1,then you send a packet with channel 1 in server,packet may not recieve correctly...


And somthing I have to tell you.This client and server is LAN only...I have just tested with my friend...We must make some edit in this step:
Quote:
6.resolve host(Name:test[client_num] Host:NULL port:Use what client sent)

As you see,Host is NULL so it only send packet to LAN clients.
I am finding some way to get the host of client.
If you have any idea to do that,please let me know.I wonder how to do that.
thanks.

EDIT:SDLNet_UDP_GetPeerAddress() may do what we want,but I don't know how to use it...yet...

[Edited by - game over on March 8, 2010 4:37:12 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this