Problem in PUN RPC sending byte[]

ktweedy1 ✭✭

I am trying to do this, but some how the bytes[] parameter in the RPC is kicking me out of the room.

byte[] w_bytedata = textureCache[0].EncodeToPNG();
photonView.RPC("SlideShowSetImage", PhotonTargets.Others, textureCache[0].width, textureCache[0].height, w_bytedata);

If I remove the byte[] parameter it works fine.

I am simply trying to send an image through the network. What could be going wrong? How should I send a block of bytes? Are there since limitations? The files I am trying to send are about 100k.


  • I think I figured it out. The pictures actually ended up being 600,000 bytes. Seems once I get over about 500k i start seeing this problem.

    Any suggesting on how to send a large block? Going to break it up into 100k blocks and see how well it does.

    Is there a preferred block size I should stay within? Wonders what issues I could run into when the servers receives the block of bytes and has to send it out to 100 users.
  • Photon is more or less for small packages to a lot of users.
    If you send a lot of data like your 600kB, you will probably run into trouble. If this is done by several players in a room, all have to receive this data and wait for it. As it's so big and nothing can go missing, we have to send everything in reliable fragments. There is no indication how much data is in transfer like this currently and you have no clue when it's going to finish.

    We think that exchanging images and data like this could best be done with a web service in combination with Photon. Store the data somewhere, give it an ID and send this ID by Photon to allow others access to it. This way you keep the channels open for realtime communication via Photon.
  • right, understand. but my customer is specifically asking to not use a web server.

    Are there some general parameters that I should stay within, like how offen should i send a package and what size I should stay under.

    Thinking to create a coroutine that loops sending blocks and sleeping for a period of time. How big of a block should i send and how long should i sleep?

    Also, wondering if there is a concept of another low priority channel I could send through. I am using PUN.

  • ktweedy1 wrote:
    right, understand. but my customer is specifically asking to not use a web server.

    Then you best inform your customer that his game will cost him a lot for traffic and proper bandwidth connection, resulting in costs of up to 20 times as much per user as normal games would. The connection speed has to be at least an order of a magnitude faster than for regular game connections if he wants to push through large binary blobs along the same connection that handles the realtime game communication without causing all unreliable game data to be severly impacted by it.

    ktweedy1 wrote:
    Thinking to create a coroutine that loops sending blocks and sleeping for a period of time. How big of a block should i send and how long should i sleep?

    This will not change the problem in any form.
    1. Coroutines are not parallel, while they do their job they are still blocking (though thats not going to impact anyone as Photon runs in a distinct thread)
    2. This is not just a problem of the client that sends it (unless his bandwidth is not large enough. Reasonably you can hope for 30-50kb/s upstream, potentially even worse so at 600kb, you grant to kill the client as thats 20-30s) but a problem of the server and all other players that get trash flooded.

    Your upstream will also not be as fast as a webservice upstream could likely be as something like amazon etc sits behind a CDN which give even better up / downstreams.
    So the question is really: what is meant to be pushed over and at what frequency. If its 600kb onetime then it can be solved but otherwise ...

    Optimally you would ensure that the data you send can be sent as fast as possible, for latency / lag fighting reasons I would attempt to ensure its within 0.2s, at worst 0.5s unless its a turnbased game
    If it takes longer it will block him out, if it takes significantly longer, the whole room might suffer it and the client might even drop out.
  • Hi, these are pictures for slide show presentation, like when you save a powerpoint as .jpgs. So just at a start of a meeting we need to copy these pictures. Ideally the first picture will happen quickly but the rest could be transferred slowly.

    W only need to copy the pictures needed then we are done until the new slide show needs to be loaded.

    It's just during the picture copy we have to send these blocks. What we see happening is sometimes while we are uploading the picture we are dropped from the room. Seems to be more stable with packets in the 1000 to 5000 bytes but that takes a little while to copy which sounds likes they will just have to live with.

    I am thinking we need realiable packets unless I can track fails and request them. Wonders if there are any settings that can be used so we don't get the room drops.

    Or if there was some kind of burst send where they understand while they are getting a picture their client may not update in realtime.
  • What else does your game / app need to do aside of sending these data?
    Will there be anything that justifies the hazzle through which you are and will be going especially while using UDP for filetransfer which in itself is already suboptimal?

    All in all it sounds to me like:
    0. You might want to experiment with the timeout configuration in the Photon config and see if that solves the 'drop problem'

    1. You might want to init the connection basing on the TCP instead of UDP protocol. You gain nothing from UDP if you need constant streams and reliability anyway aside of the UDP packet overhead and potential trouble with global UDP blocks on firewalls and routers, a thing that will especially hit you for connections from / to really protected business environments but especially gov and educational environments.

    2. You might want to replace PUN with the normal Unity client SDK instead to get more control (or heavily modify PUN for your purpose but that not only takes time and requires you to learn the regular SDK anyway, it also makes updating PUN a serious chore, a thing that would trivial if you use the regular Unity client SDK)
  • Hi, thanks, right not we don't do much else except sit, walk around, chat. It for having an online meeting.