Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  datagrampacket - UDP  (Read 2765 times)
0 Members and 1 Guest are viewing this topic.
Offline Phibedy

Senior Devvie


Medals: 9



« Posted 2012-07-17 14:15:45 »

Now everything works fine,
but I still got three other little questions:
1.What happens, if I send pakets with different threads and 2 or more threads send it the same time on the same port?
2.What happens, if I receive an paket and send one the same time on the same port?
I already read about it, but I am not sure if it causes "real" errors.
3.Why isn´t it possible to add a received packet to an arrayList without using
1  
2  
3  
ServerData.socket.receive(rpaket);
            DatagramPacket packet = new DatagramPacket( rpaket.getData(), rpaket.getData().length, rpaket.getAddress(), rpaket.getPort());
            receivedData.add(packet);



thx for reply
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #1 - Posted 2012-07-20 21:33:05 »

Now everything works fine,
but I still got three other little questions:
1.What happens, if I send pakets with different threads and 2 or more threads send it the same time on the same port?
2.What happens, if I receive an paket and send one the same time on the same port?
I already read about it, but I am not sure if it causes "real" errors.
3.Why isn´t it possible to add a received packet to an arrayList without using
1  
2  
3  
ServerData.socket.receive(rpaket);
            DatagramPacket packet = new DatagramPacket( rpaket.getData(), rpaket.getData().length, rpaket.getAddress(), rpaket.getPort());
            receivedData.add(packet);



thx for reply

You cant send and recieve at the same time, and thats not a problem.
I dont know why you would want multiple threads to be sending packets. You probably have a design flaw somewhere. Its possible, but not good practise - at least not since nio.

You should be able to if it returns a suitable object.

Offline jonjava
« Reply #2 - Posted 2012-07-21 05:37:11 »

Basically what happens is you add the packets you've created in a queue for the Operating System to send.

It's not an issue, though. Since if you have other programs or you need to differentiate between 2 connections (In most cases you don't need to) you just "make" a new connection by simply sending/receiving to another port.

When you send and receive data you send that data in "packets" at a time. This means that your data can't just be received half way - either it comes or it doesn't come at all (UDP).

As an off-note. TCP works pretty much the same way, except TCP automatically checks if the data you send/receive 1) arrives and 2) arrive in the same order it was sent (This can lead the TCP to backtrack for missing packets and cause lag).

If you're making an MMO Server (or server-client application in general) you can for example differentiate between different clients by their ip address. I.e, receive packet, check who sent it, deal with the packet,

Your clients should only need to talk to the server.

And about two Threads receiving at the same. Hmm. Either the packets are shared inconsistently between them (if they listen to the same port) or the OS give both of them a copy. Not sure. I want to try this out. Brb.

[EDIT]: Oh right, it's not possible since the port will be in use (The operating system won't allow it). So, you can receive at the same times no problem from different ports. In most cases you wouldn't need to. Why do you think you would need 2 ports for your program? We could perhaps point out a simpler and more effective way where you'd only need to use 1 port.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #3 - Posted 2012-07-21 07:39:00 »

This means that your data can't just be received half way - either it comes or it doesn't come at all (UDP).

Its possible to send a datagram with no checksum though, so I would certainly believe that corruption is possible. The checksum in udp is not very good either, so smaller errors won't be noticed. Also, remember datagram truncation on some systems. Thats a neat way to lose packet data.

Offline jonjava
« Reply #4 - Posted 2012-07-21 08:35:07 »

This means that your data can't just be received half way - either it comes or it doesn't come at all (UDP).

Its possible to send a datagram with no checksum though, so I would certainly believe that corruption is possible. The checksum in udp is not very good either, so smaller errors won't be noticed. Also, remember datagram truncation on some systems. Thats a neat way to lose packet data.

UDP uses a 16bit checksum so in this case you don't need to worry about it. If the UDP fails the checksum it will drop the packet. I.e, look as if it never arrived to your program. So, if you're using UDP you don't have to worry about it.

Actually lemme paste in here using google-fu:

Quote
UDP used a 16 bit checksum. It is not impossible for it to have corruption, but it's pretty unlikely. In any case it is not more susceptible for corruption than TCP.

Quote
First of all, the "IP checksum" referenced above is only an IP header checksum. It does not protect the payload. See RFC 791

Secondly, UDP allows transport with NO checksum, which means that the 16-bit checksum is set to 0 (ie, none). See RFC 768. (An all zero transmitted checksum value means that the transmitter generated no checksum)

Thirdly, as others have mentioned, UDP has a 16-bit checkSUM, which is not the best way to detect a multi-bit error, but is not bad. It is certainly possible for an undetected error to sneak in, but very unlikely.

Quote
UDP uses a 16-bit optional checksum. Packets which fail the checksum test are dropped.

Assuming a perfect checksum, then 1 out of 65536 corrupt packets will not be noticed. Lower layers may have checksums (or even stronger methods, like 802.11's forward error correction) as well. Assuming the lower layers pass a corrupt packet to IP every n packets (on average), and all the checksums are perfectly uncorrelated, then every 65536*n packets your application will see corruption.

Example: Assume the underlying layer also uses a 16-bit checksum, so one out of every 2^16 * 2^16 = 2^32 corrupt packets will pass through corrupted. If 1/100 packets are corrupted, then the app will see 1 corruption per 2^32*100 packets on average.

If we call that 1/(65536*n) number p, then you can calculate the chance of seeing no corruption at all as (1-p)^i where i is the number of packets sent. In the example, to get up to a 0.5% chance of seeing corruption, you need to send nearly 2.2 billion packets.

(Note: In the real world, the chance of corruption depends on both packet count and size. Also, none of these checksums are cryptographically secure, it is trivial for an attacker to corrupt a packet. The above is only for random corruptions.)

TLDR; don't worry about it.
[size=8pt]
source: http://stackoverflow.com/questions/47901/can-udp-data-be-delivered-corrupted, http://stackoverflow.com/questions/1526485/can-the-data-in-a-udp-packet-be-assumed-to-be-correct-at-the-application-level[/size]

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #5 - Posted 2012-07-21 08:46:26 »

UDP uses a 16bit checksum so in this case you don't need to worry about it. If the UDP fails the checksum it will drop the packet. I.e, look as if it never arrived to your program. So, if you're using UDP you don't have to worry about it.

I didn't think that checksum protected the payload, but apparently it does. My bad.

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #6 - Posted 2012-07-21 08:49:44 »

Read his quotes.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #7 - Posted 2012-07-21 09:26:30 »

Read his quotes.

Those were not there when I posted, in my defence.

Offline Phibedy

Senior Devvie


Medals: 9



« Reply #8 - Posted 2012-07-24 11:14:31 »

Thx  Smiley
Now I get sometimes get a strage error.
Thread (1):
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
   @Override
   public void run() {
      ArrayList<DatagramPacket> receivedData = ServerData.receivedPackets;
      for(;;){
            while(receivedData.size() > 0){

               if(receivedData.get(0).getData() == null){
                  System.out.println("receivedData == null!!!!");
                  System.out.println(receivedData.size());
                  receivedData.remove(0);
                  break;
               }
[...]
thread.sleeps(5)


In another thread (2) I add packets to receivedData.
If Thread (1) calls "while(receivedData.size() > 0)"  shortly after thread(2) added the packet, it´s null. It seems, that thread(2) just increased the size but haven´t added the object yet.
Should I lock the object until is it completely added?
Should I put a "thread.sleep(0,5)" after "while(receivedData.size() > 0)".
Is it better to catch the errors and don´t care about some more packetloss?
Feel free to criticise, if my approach is quite bad.
thx for reply  Smiley
Offline jonjava
« Reply #9 - Posted 2012-07-24 11:43:05 »

Why are you receiving data from the same connection on two different threads at the same time? This will only leads the packets to split inconsistently between the threads.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (53 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (79 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (97 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!