UDPOpen() acting weird...

[Xand3r]

shouldn't

UDPOpen() and UDPSend()

return an error if the port that i'm trying to open isn't open?

whenerver i UDPOpen() i don't get an error... even if i try to connect to ports that i know for sure that are closed :|...

same for UDPSend()

any ideeas?

Edited March 16, 2008 by alexmadman

[martin]

shouldn't

UDPOpen() and UDPSend()

return an error if the port that i'm trying to open isn't open?

whenerver i UDPOpen() i don't get an error... even if i try to connect to ports that i know for sure that are closed :|...

same for UDPSend()

any ideeas?

What do you mean the port is closed? Can you show some code that doesn't work?

[The Kandie Man]

shouldn't

UDPOpen() and UDPSend()

return an error if the port that i'm trying to open isn't open?

whenerver i UDPOpen() i don't get an error... even if i try to connect to ports that i know for sure that are closed :|...

same for UDPSend()

any ideeas?

User Datagram Protocol is a connectionless protocol that does not make a actual connection with the target IP and port. In addition, it has no error correction and no flow control. It is the protocol with the least overhead but it is completely unreliable as a result. If you want it to be reliable, you have to write your own flow control, error correction, and handshaking at the Application Layer of the OSI model.

- The Kandie Man ;-)

[Xand3r]

ok... (though i think i tested it before and it worked... nvm)

can u tell me how can i know if a mysql server is listening to a port or not?(it's not tcp.. it's udp..)

[martin]

It is the protocol with the least overhead but it is completely unreliable as a result.

- The Kandie Man ;-)

I think it is overstating the situation to say UDP is completely unreliable.

It depends on where and how you use it. If you use it to connect between PC's on a local network for example, then it is very fast (because of the lack of overhead) and there is very little chance that there will be problems.

Lots of very complicated pieces of equipment use UDP in real time control with many different ports open to different PC all exchanging data at high speed at the same time.

It is not completely reliable, and neither is TCPIP, but I would admit that for communications over the internet for example it is a questionable choice.

[Jos]

It is not completely reliable...

Isn't that the same as unreliable ?

I agree that it will work fine most of the time and especially when in a LAN environment but it is true there is no error checking thus should be called unreliable and requires some sort of errorchecking and handshaking.

Jos

[martin]

Isn't that the same as unreliable ?

Jos

Similar, but not the same as what I objected to which was "completely unreliable". In the last year I have transferred a many MBytes back and forth using UDP and never had a problem so that's why I don't think it is completely unreliable. But I wouldn't claim that it is guaranteed to work.

To me "completely" is the same as "totally". So if something is completely unreliable it never works. If it is completely reliable it never fails. Unreliable means, to me, that it does work but it will often stop, break down, fail etc. It's possibly the difference between what I would understand when talking to someone (in England say) compared to what the dictionary says I should understand. So it could be that I'm wrong.

Edited March 15, 2008 by martin

[Xand3r]

... ok so i understand it's not reliable , i kinda knew that but... since

mysql works on a udp port... i've got to use udp and not tcp

[The Kandie Man]

I think it is overstating the situation to say UDP is completely unreliable.

It depends on where and how you use it. If you use it to connect between PC's on a local network for example, then it is very fast (because of the lack of overhead) and there is very little chance that there will be problems.

Lots of very complicated pieces of equipment use UDP in real time control with many different ports open to different PC all exchanging data at high speed at the same time.

It is not completely reliable, and neither is TCPIP, but I would admit that for communications over the internet for example it is a questionable choice.

The reason I don't like UDP is because it has no flow control. As a result, it can send frames through a network that are received by another machine in the wrong order. In addition to that, the frames can be corrupt. For a LAN, UDP would be an acceptable choice, but even then, I would be very careful if I were sending critical information. Sending database queries, like alexmadman is asking, could become risky if the queries retrieve data or add data to a database that is not in the correct order. For example, Computer 1(client) could send information to Computer 2(server).

The data being sent from Computer 1 could look like this:

Username:Jon,Occupation:Software Developer,Location:UK

The frames could look something like this(brackets indicate a frame):

[userName:Jon,][Occupation:Softwar][e Develop][er,Location:][uK]

Even if the data is not corrupted, it could be received by Computer 2 out of order as:

[Occupation:Softwar][userName:Jon,][e Develop][uK][er,Location:]

As a result, the server would add the following to the database:

Occupation:SoftwarUserName:Jon,e DevelopUKer,Location:

Which is butchered beyond belief. This of course is still unlikely, but it is very possible if you have a network with many computers that are constantly querying a database server. The routers could routinely redirect frames through different paths to the server based on network traffic. The end result could be very similar to what I am describing above. Even with the fact that none of that data was corrupted and there was 0% "packet" loss, the data that was sent to the server was jumbled to a point where it is useless information.

I personally would use UDP only for things that aren't critical. Examples include: streaming music and querying a site for information regarding a software update.

Anything that needs reliability should use Transfer Control Protocol, because as long as a stable connection is possible, it guarantees the successful transfer of data. If a stable connection is lost, TCP will immediately(after the designated timeout) stop the transfer and notify the program that is transferring the data that the connection was lost. If data is sent that is corrupted, the receiving machine will re-request the corrupted frames from the sending machine and the sending machine will resend them. If the frames are received out of order, the receiving machine will re-order them so that they are in the correct order automatically and then send them to the application.

This doesn't mean UDP is useless, it just is just completely unreliable in the sense of the definition of the word unreliable. I would say that UDP is extremely useful for those that don't need error correction, those that don't want overhead, those that want to write their own error correction and flow control, or those that simply don't care if the data is received correctly 100% of the time. For those types of situations, UDP is pure gold.

That's just my two cents.

@alexmadman

You will need syntax regarding the formatting that the server uses when it receives information from its ports and the formatting that the server uses when it sends out information. As far as what port the server is listening, you can use TCPView. It shows what ports, both TCP and UDP, that certain processes are using. The MySQL server is likely to be listening at port 3306 with both TCP and UDP protocols. This is the official port used by MySQL databases according to Wikipedia.

- The Kandie Man ;-)

[Xand3r]

tnx kandie man... when i tried to see if the mysql server was oppening a tcp port too i tried

tcpconnect("localhost",3306) (the server is local) and as it did not work... i thought it wasn't open

when i tried tcpconnect("127.0.0.1",3306) it worked