problem sending big packets

[Ashkan Saeedi Mazdeh]

I'm trying to send webcam data over network by sending color array of GetPixels() but due to a big package system.net gets an error, the size is smaller than max package in uLink

my camera supports 160X120 as smaller resolution.

 

Project file is attached.
--

Ashkan Saeedi Mazdeh

co-founder MindHammergames

Skype: ashkan_gc

cell: +(98)9193046544

LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh

http://mindhammergames.com

[Aidin Abedi]

Hello Ashkan,

The texture 160x120x4 = 76800 bytes + (a few bytes protocol header) is actually larger then the maximum internet guarantied packet size (some routers allow higher but there is no guaranty), which is 1400 bytes (the default value of uLink.Network.config.maximumTransmissionUnit). However, uLink will automatically split a too big reliable RPC into smaller fragments, send the fragments separately and then assemble them back into one RPC again without the application even knowing. But this has not been added for unreliable RPCs yet, because  fragmenting a unreliable RPC has the potential to be used as a DOS attack to a greater extent. So there needs to be additional safeguards against that before implementing it for unreliable too. Automatic fragmentation of unreliable RPCs will most likely be added in uLink 2.0, but not for uLink 1.x.

In short: if you change networkView.UnreliableRPC to networkView.RPC when sending the pixels, it will work. But if you want use unreliable to avoid the overhead cost of reliability, you can split the pixels into smaller blocks and send the blocks individually to a receiver method like this:

[RPC]

void WebCamPixels(int x, int y, int blockWidth, int blockHeight, Color[] pixels)

{

targetTexture.SetPixels(x, y, blockWidth, blockHeight, pixels);

}

Sincerely,

Aidin

--
 
 

[Ashkan Saeedi Mazdeh]

Hey

Thanks for the fast answer. I'm aware of router limitaions and was just testing it for LAN usage. I might test it later on for voice as well. I know that real algorithms and ways of doing these are really different and use compressed formats.

Sending unreliable parts might cause some of the packets of a frame arrive and some not and then i should track them somehow to see if i can create the frame or not but is a possible solution and maybe better than sending 25 reliable huge packets.

 

P.S each pixel is 3 byes because i'm not getting alpha values.

 

Cheers for the great job that you are doing :)

2012/10/2 Aidin Abedi <aidin...@gmail.com>

--
 
 

[Aidin Abedi]

Hey,

I've moved the discussion to the support forum, because more might find this interesting too:

http://forum.muchdifferent.com/unitypark/index.php?p=/discussion/comment/1093#Comment_1093

I also added additional suggestions to my previous answer including how to avoid serializing the alpha channel.

Cheers,

Aidin

--