Problem with QUdpSocket

[goetz]

-There is no connect() statement that connects a signal to your slot.-
(sorry, looked in the wrong place)

[soroush]

Thanks for your reply,

I tried debuging and found that server emits player disconnection messages immediately after running this line:
@socket.write("(init team-name (version 14))");@
but calling socket.state() returns QAbstractSocket::ConnectedState even after server says player is disconnected. Naturally anything is not returned to client when server thinks player is disconnected....

I think there is a problem with server. that is written in c and c++ completely. it works fine with its own client (rcssclient).

Any ideas?

[andre]

Well, we obviously don't know the protocol used by your server, so it is hard to go into that. My cat shattered my last crystal ball, you know...

What is funny in this, is that you're talking about connecting and disconnecting in the context of UDP. UDP is a connectionless protocol. It just sends datagrams, and does not guarantee that they arrive or arrive in order. There is no concept of a connection (like TCP does offer) in UDP.

[soroush]

So,... why server says:
@
...
A player disconnected : (team-name 1)
...
@
when I send initialization message? I'm completely confused. :-/

[andre]

How should we know why your server would say that? We have no access to that server or what it does! Perhaps ask the maintainer of that service why it behaves the way it does?

[goetz]

[quote author="Andre" date="1302171752"]What is funny in this, is that you're talking about connecting and disconnecting in the context of UDP. UDP is a connectionless protocol. It just sends datagrams, and does not guarantee that they arrive or arrive in order. There is no concept of a connection (like TCP does offer) in UDP. [/quote]

I think it's to certain degree because of this paragraph in "QUdpSocket docs":http://doc.qt.nokia.com/4.7/qudpsocket.html":

bq. The most common way to use this class is to bind to an address and port using bind(), then call writeDatagram() and readDatagram() to transfer data. If you want to use the standard QIODevice functions read(), readLine(), write(), etc., you must first connect the socket directly to a peer by calling connectToHost().
[Highlighting by me]

[andre]

That might be it yes. The Qt API is a bit weird in this point.

[goetz]

[quote author="Andre" date="1302174200"]That might be it yes. The Qt API is a bit weird in this point. [/quote]

Once we have the "new stuff":http://developer.qt.nokia.com/blog/view/qt_documentation_our_new_roomieon DevNet we can add a big warning :-)

[andre]

Yep. Already have some places in mind where I'd like to add some thoughts...

[dangelog]

[quote author="Andre" date="1302174200"]That might be it yes. The Qt API is a bit weird in this point. [/quote]

It's not weird. For decades UNIX has supported connect(2)ing UDP sockets, with well-definite semantics. Qt simply does the same thing.

[andre]

The group of people working with Qt is obviously broader than well-versed unix programmers. I find it weird to talk about connections when you are dealing with a protocol that does not handle connections. I looked it up what it does in Unix. It seems that it does two things:

set a default host address where data packages are send to

limit receiving datagrams to only those from the host you "connected" to.

The QUdpSocket documentation mentions neither, but seems to do something like 1) at least. What's more, it first states that UDP is connectionless, and then in the next paragraph, explains that you need to connect to use certain methods. Excuse me, but I find that weird and inconsistent, no matter what older Unix API may use the same kind of terminology.