How reliable are pydatagrams?

General Discussion
1

I’ve been doing a ton of reading on UDP and TCP networking over the last few days for a MMORPG project I’m putting together.

Currently I’ve setup a basic server that accepts multiple connections via tcpsockets. The code uses the QueuedConnectionManager library, however all the examples I see pull datagrams off the ConnectionReader.

But in all the reading I’m doing, I’m getting the impression that datagrams are used for connection-less networking, mostly with UDP and are unreliable.

Are the panda Datagrams reliable/guaranteed to be delivered like tcp packets are? Or are they like real datagrams/udp packets that aren’t guaranteed?

I’m worried about data not being received if I start using datagrams, which can really bork a RPG up if the clients suddenly stop getting data accurately from the server.

2

Hi, I know (absolutely none) about panda’s networking, I would like to insert my experience with networking though:

Use TCP for anything that needs to get there (kill events, purchases, etc)

Use UDP for anything that is unimportant (Position updates) In fact, you sort of have to do this in my experience. I tried using TCP for position updates, it only ever bogged the server entirely up (on a lan!)

So tips for position updates: use UDP and only send them every second. Then smooth the character’s movement from the last position to the new one.

I thought I’d try to help at least :smiley: sorry that I have no idea about panda’s networking… :wink:

3

I think it’s the terminology that’s throwing me. Panda uses ‘datagram’ as a really lose term.

Here’s my server connection manager code:

        self.cManager = QueuedConnectionManager()
        self.cListener = QueuedConnectionListener(self.cManager, 0)
        self.cReader = QueuedConnectionReader(self.cManager, 0)
        self.cWriter = ConnectionWriter(self.cManager,0)
        self.tcpSocket = self.cManager.openTCPServerRendezvous(self.port,self.backlog)
        self.cListener.addConnection(self.tcpSocket)

As you can see, it opens a tcpSocket, not a UDP Socket.

The manual states:

That’s tell me that if I fire off a PyDatagram through my tcpSocket it will send it as a tcp packet (guaranteed delivery). However if I change the server configuration to udpSocket it should fire it off as a UDP packet (not guaranteed).

So if I take this line of code:

self.tcpSocket = self.cManager.openTCPServerRendezvous(self.port,self.backlog)

and change it to

self.tcpSocket = self.cManager.openUDPServerRendezvous(self.port,self.backlog)

(or whatever the command is to set it as a UDP socket instead of TCP, I was guessing when I typed this).

That should change all datagrams to UDP datagrams as the socket is now UDP based. Am I right?

Am I getting totally lost here? Or does Panda really configure the datagram to be a UDP Datagram or TCP packet based on the socket type?

I want it to be guaranteed via TCP protocol, so I’m trying to make sure the code I’m using isn’t flopping over to UDP datagrams.

4

The socket type does define the packet format (in my experience), again I’ve never used panda networking, in ANY networking code (python sockets, java sockets, c# sockets, and C++/C cross-platform sockets, and winsock) everything is defined by the socket type.

That’s why most of the time you have to open two sockets, a UDP and a TCP socket both to the server (well the UDP one never “connects”, but you get the idea though)

I think the term datagram may be used as ‘packet’, I could be wrong.

Data sent over sockets is sent in a stream (bytes are sent and buffered on the receiving end) at some point a “end the packet” key has to be sent, to let the opposite side know that they have one full packet now. This stops insane errors, I think panda may be doing this for you.

So, again I could be wrong, I think that datagram means “one packet split out of the data stream” I never designed this though so maybe you should wait for someone like David or rdb to answer this, they probably have more knowledge than I do.

P.S. Try it out in fact, download Wireshark, latch it onto your card and see what type of data it’s sending to the server (or to the client), make sure it’s actually your program though (look at the ports)

5

From the experiments I’ve done datagrams are just a way to take diffrent data types uint32 int16 uint 16 int32 string float etc… and serialize them to be sent over the line

6

I’m pretty sure that’s the case too, but I was hoping somebody could provide me with a definitive answer just in case. In almost every other programming language datagram refers to UDP-specific packets, not TCP.

7

Panda handles it a bit weirdly
For example

myDg = PyDatagram()
myDg.addUInt32(123456)
myDg.addString("Hello world!")

tcpSocket.send(myDg.getMessage())
8

When you’re using UDP, a datagram corresponds one-to-one with a UDP packet. In TCP, of course, there’s no such thing as packets, but a datagram is a unit of data sent on the stream. In TCP, datagrams are encoded end-to-end into the stream of bytes, and extracted the same way.

Just think of a datagram as a unit of data. That’s what the core meaning of the word is, after all. In TCP, datagrams are sent reliably; in UDP, they are not (though they are automatically checksummed by the underlying mechanism, and datagrams that fail the checksum are omitted).

David

9

Thanks David :slight_smile: