UDP packet managing vis sdlnet

hello

I’m working on a client/server app. that uses both TCP and UDP
protocols. I haven’t had much experience with SDLnet. Currently, the
server side waits for clients to connect and then periodically broadcasts
TCP and UDP packets to all of the connect clients. The client side opens
a TCP and a UDP socket with the server and prints out the contents of the
data it receives from the server.

I seem to have the TCP portion working just peachy. UDP is a
problem. My UDP packets do no go to all of the clients. When the server
tries to send them to all of the connected clients, only the first client
to have connected will receive them. I’m guessing that something’s fouled
with the channels, but I’m not sure.

If anyone wants to take a look at the code, I have it right here at
http://home.uchicago.edu/~davej/{Server.c, Client.c}

I may end up fixing it, but who knows.

thanks,
dave j

I only briefly looked at the code, but I highly doubt you can send UDP and
TCP packets with the same socket or on the same port, at the same time or
while TCP is connected. UDP is basically a send it and forget it protocol,
but whens the last time someone sent UDP packets over like port 80? I doubt
its defined behavior to mix packets like this.

Btw-- UDP packets can be dropped without any warning… although UDP packets
are guaranteed to arrive correctly (i.e. they are CRC’d), there is nothing
in the protocol that causes lost packets to get resent. Also, packets can
arrive out of order. All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

Later,
Matt Johnson
http://home.tampabay.rr.com/optic2000> I’m working on a client/server app. that uses both TCP and UDP

protocols. I haven’t had much experience with SDLnet. Currently, the
server side waits for clients to connect and then periodically broadcasts
TCP and UDP packets to all of the connect clients. The client side opens
a TCP and a UDP socket with the server and prints out the contents of the
data it receives from the server.

I seem to have the TCP portion working just peachy. UDP is a
problem. My UDP packets do no go to all of the clients. When the server
tries to send them to all of the connected clients, only the first client
to have connected will receive them. I’m guessing that something’s fouled
with the channels, but I’m not sure.

If anyone wants to take a look at the code, I have it right here at
http://home.uchicago.edu/~davej/{Server.c, Client.c}

I may end up fixing it, but who knows.

thanks,
dave j


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I only briefly looked at the code, but I highly doubt you can send UDP and
TCP packets with the same socket or on the same port, at the same time or
while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically broadcasts
TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:

I actually understand some of the theory behind UDP, but I’m kinda stuck
on the implementation side of it. Actually, I can’t say that I really
understand what ‘channels’ are in the SDLNet library. I would’ve guessed
you’d just stuff em in a socket and not worry about it anymore. The
channel part has me baffled.

Not broadcast, but the server sends out a beacon to its clients via TCP.

Maybe if I explained what the end project is: I’m modifying someone’s
code that reads in keyboard events from a windows box and sends them via
TCP to its connected clients which are running Linux. The linux clients
read the incoming data, parse them, and has X run them. You’d up having
keyboard control of a bunch linux boxes with a windows machine.

I’m currently adding the mouse support. Mouse movement doesn’t have a
high priority and there’s a lot of it. Therefore, UDP packets make sense
for sending out that data. Before I go there, I wanted to get comfortable
with SDLnet’s library. Which brings me to my current situation.

Any more comments are welcome. thxOn Tue, 14 Aug 2001, Mattias Engdegard wrote:

I only briefly looked at the code, but I highly doubt you can send UDP and
TCP packets with the same socket or on the same port, at the same time or
while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically broadcasts
TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hi,

why don’t you just use stream sockets? Its simple
and straight forward to use. You could get your
project working and then go back to UDP later if
you really need it.

om> ----- Original Message -----

From: david ackley jones [mailto:davej@midway.uchicago.edu]
Sent: Tuesday, August 14, 2001 11:50 PM
To: sdl at libsdl.org
Subject: Re: [SDL] UDP packet managing vis sdlnet

I actually understand some of the theory behind UDP, but I’m kinda stuck
on the implementation side of it. Actually, I can’t say that I really
understand what ‘channels’ are in the SDLNet library. I would’ve guessed
you’d just stuff em in a socket and not worry about it anymore. The
channel part has me baffled.

Not broadcast, but the server sends out a beacon to its clients via TCP.

Maybe if I explained what the end project is: I’m modifying someone’s
code that reads in keyboard events from a windows box and sends them via
TCP to its connected clients which are running Linux. The linux clients
read the incoming data, parse them, and has X run them. You’d up having
keyboard control of a bunch linux boxes with a windows machine.

I’m currently adding the mouse support. Mouse movement doesn’t have a
high priority and there’s a lot of it. Therefore, UDP packets make sense
for sending out that data. Before I go there, I wanted to get comfortable
with SDLnet’s library. Which brings me to my current situation.

Any more comments are welcome. thx

On Tue, 14 Aug 2001, Mattias Engdegard wrote:

I only briefly looked at the code, but I highly doubt you can send UDP
and

TCP packets with the same socket or on the same port, at the same time or
while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically
broadcasts

TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Don’t I lose portability when I use berkeley sockets? That’s pretty much
the reason why I use SDLNet.

-daveOn Wed, 15 Aug 2001, Oisin Mulvihill wrote:

Hi,

why don’t you just use stream sockets? Its simple
and straight forward to use. You could get your
project working and then go back to UDP later if
you really need it.

om

-----Original Message-----
From: david ackley jones [mailto:@david_ackley_jones]
Sent: Tuesday, August 14, 2001 11:50 PM
To: sdl at libsdl.org
Subject: Re: [SDL] UDP packet managing vis sdlnet

I actually understand some of the theory behind UDP, but I’m kinda stuck
on the implementation side of it. Actually, I can’t say that I really
understand what ‘channels’ are in the SDLNet library. I would’ve guessed
you’d just stuff em in a socket and not worry about it anymore. The
channel part has me baffled.

Not broadcast, but the server sends out a beacon to its clients via TCP.

Maybe if I explained what the end project is: I’m modifying someone’s
code that reads in keyboard events from a windows box and sends them via
TCP to its connected clients which are running Linux. The linux clients
read the incoming data, parse them, and has X run them. You’d up having
keyboard control of a bunch linux boxes with a windows machine.

I’m currently adding the mouse support. Mouse movement doesn’t have a
high priority and there’s a lot of it. Therefore, UDP packets make sense
for sending out that data. Before I go there, I wanted to get comfortable
with SDLnet’s library. Which brings me to my current situation.

Any more comments are welcome. thx

On Tue, 14 Aug 2001, Mattias Engdegard wrote:

I only briefly looked at the code, but I highly doubt you can send UDP
and

TCP packets with the same socket or on the same port, at the same time or
while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically
broadcasts

TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hi,

I don’t know what you mean by portability, but sdl net
stream sockets works on windows/aix/linux/beos. I’ve used
it successfully on all systems.

om> ----- Original Message -----

From: david ackley jones [mailto:davej@midway.uchicago.edu]
Sent: Wednesday, August 15, 2001 4:28 PM
To: 'sdl at libsdl.org
Subject: RE: [SDL] UDP packet managing vis sdlnet

Don’t I lose portability when I use berkeley sockets? That’s pretty much
the reason why I use SDLNet.

-dave

On Wed, 15 Aug 2001, Oisin Mulvihill wrote:

Hi,

why don’t you just use stream sockets? Its simple
and straight forward to use. You could get your
project working and then go back to UDP later if
you really need it.

om

-----Original Message-----
From: david ackley jones [mailto:davej at midway.uchicago.edu]
Sent: Tuesday, August 14, 2001 11:50 PM
To: sdl at libsdl.org
Subject: Re: [SDL] UDP packet managing vis sdlnet

I actually understand some of the theory behind UDP, but I’m kinda stuck
on the implementation side of it. Actually, I can’t say that I really
understand what ‘channels’ are in the SDLNet library. I would’ve guessed
you’d just stuff em in a socket and not worry about it anymore. The
channel part has me baffled.

Not broadcast, but the server sends out a beacon to its clients via TCP.

Maybe if I explained what the end project is: I’m modifying someone’s
code that reads in keyboard events from a windows box and sends them via
TCP to its connected clients which are running Linux. The linux clients
read the incoming data, parse them, and has X run them. You’d up having
keyboard control of a bunch linux boxes with a windows machine.

I’m currently adding the mouse support. Mouse movement doesn’t have a
high priority and there’s a lot of it. Therefore, UDP packets make sense
for sending out that data. Before I go there, I wanted to get comfortable
with SDLnet’s library. Which brings me to my current situation.

Any more comments are welcome. thx

On Tue, 14 Aug 2001, Mattias Engdegard wrote:

I only briefly looked at the code, but I highly doubt you can send UDP
and

TCP packets with the same socket or on the same port, at the same time
or

while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically
broadcasts

TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

ok, then I guess I’m not too sure what you mean by stream sockets… I
have used SDLnet’s TCP sockets successfully on Linux and Windows. By
stream sockets, I thought you were referring to BSD sockets. It’s just
that I’m not getting UDP sockets to work with SDLnet. I’m hoping for
suggestions other than ‘use TCP’.

thx, dave j.On Wed, 15 Aug 2001, Oisin Mulvihill wrote:

Hi,

I don’t know what you mean by portability, but sdl net
stream sockets works on windows/aix/linux/beos. I’ve used
it successfully on all systems.

om

-----Original Message-----
From: david ackley jones [mailto:@david_ackley_jones]
Sent: Wednesday, August 15, 2001 4:28 PM
To: 'sdl at libsdl.org
Subject: RE: [SDL] UDP packet managing vis sdlnet

Don’t I lose portability when I use berkeley sockets? That’s pretty much
the reason why I use SDLNet.

-dave

On Wed, 15 Aug 2001, Oisin Mulvihill wrote:

Hi,

why don’t you just use stream sockets? Its simple
and straight forward to use. You could get your
project working and then go back to UDP later if
you really need it.

om

-----Original Message-----
From: david ackley jones [mailto:@david_ackley_jones]
Sent: Tuesday, August 14, 2001 11:50 PM
To: sdl at libsdl.org
Subject: Re: [SDL] UDP packet managing vis sdlnet

I actually understand some of the theory behind UDP, but I’m kinda stuck
on the implementation side of it. Actually, I can’t say that I really
understand what ‘channels’ are in the SDLNet library. I would’ve guessed
you’d just stuff em in a socket and not worry about it anymore. The
channel part has me baffled.

Not broadcast, but the server sends out a beacon to its clients via TCP.

Maybe if I explained what the end project is: I’m modifying someone’s
code that reads in keyboard events from a windows box and sends them via
TCP to its connected clients which are running Linux. The linux clients
read the incoming data, parse them, and has X run them. You’d up having
keyboard control of a bunch linux boxes with a windows machine.

I’m currently adding the mouse support. Mouse movement doesn’t have a
high priority and there’s a lot of it. Therefore, UDP packets make sense
for sending out that data. Before I go there, I wanted to get comfortable
with SDLnet’s library. Which brings me to my current situation.

Any more comments are welcome. thx

On Tue, 14 Aug 2001, Mattias Engdegard wrote:

I only briefly looked at the code, but I highly doubt you can send UDP
and

TCP packets with the same socket or on the same port, at the same time
or

while TCP is connected.

UDP and TCP have separate port spaces so this is not a problem

All in the name of effecieny… thats why UDP is
generally used where packet loss is expected, such as streaming
applications.

It is correct that UDP packets may be lost or reordered/duplicated but
not that they are necessarily more efficient (on some data links TCP
has both higher bandwidth and lower latency). However since you must
implement your own flow control with UDP you can tailor it better to
your needs (and make it more tolerant to dropped packets etc)

Currently, the
server side waits for clients to connect and then periodically
broadcasts

TCP and UDP packets to all of the connect clients.

you can’t broadcast TCP packets but I assume you didn’t use it in a
technical sense.

There can very well be nasty dragons hiding inside SDL_net – I haven’t
ventured into it very far myself. I would prefer to debug it using
dynamite :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl