Sending byte arrays through events

Options
Minassian
edited June 2012 in DotNet
Hi again :)
So I was having this dilema: viewtopic.php?f=6&t=1704
and decided to try with an operation / event solution.
Right now I'm sending an operation to the server passing the ID and the texture serialized in a bytearray, and the server triggers an event to the clients with the same data.
Simple, but it doesn't work.
The sender client gets a lot of QueueOutgoingReliableWarning, QueueSentWarning and eventually a DisconnectByServer.

I assume the byte[] its too big to pass it in a parameter straight away.

Should I cut it down into smaller pieces, receive them in the server, send them using events and put it all together in the rest of the clients ?
How big should the pieces be ?
Is there a standard way to do this or should go ahead and do it manually, passing an extra parameter to know when the last chunk arrived and nasty things like that ?

Thank you.

Comments

  • dreamora
    Options
    cutting it will not change the problem.
    Photon does that on its own too.

    Your problem is that you simply try to push more than the connection can hold and with a sufficient level of lose you will no longer be able to send the keep alive ping in which case you get disconnected. Normally calling service more often helps but not if the line itself is flooded

    Try to reduce the data you send itself down to a reasonable level or ensure a corresponding minimum upstream bandwidth and kick all others.
    That and make use of channels to priorize the relevant things, with your data transfer being less relevant and hence getting throttled down.

    I would normally recommend to not send such massive byte blobs through the realtime network.
    make the client upload them to a webservice and send the url to that place through so everyone can fetch it from there. webservices are significantly better suited at providing large data blobs than realtime networking solutions that are meant to send many distinct data packets as fast as possible, not a single massive one 'somewhen'

    also ensure to not use the load balancing server or if you do ensure that you use a custom operation which makes the server broadcast it, not some 'dedicated master client' and ensure that your photon server runs on a reasonable server. 10mbit++ upstream if you try to push through images or uncompressed audio is a bare minimum, trying to do it from home connections is unlikely going to work out unless you are on a highspeed glasfiber line.
  • Awe I was pretty lost after trying a million different things.
    I started using PNG compression which reduced the image size to the half, but still same problem.

    So I'm going to set up a webservice and when a new texture needs to be sent, I will only replicate the URL and parallely upload the data to the WS.
    When each client finally sees the object with the URL, it will start trying to fetch it from the webservice.

    Thank you very much for your response dreamora, always very helpfull.
  • dreamora
    Options
    For truely small sizes on the images, you would likely want to favor jpg or even gif if possible which cut down the size massively.
    Or DXT / pvrtc.

    depends a bit on engine and platform.
  • Ah yes, but I'm working with Unity which has the convenient aTexture2D.ConvertToPNG() function already there.
    I think for the prototype its going to be ok, but I'll see how to go with JPGs for the real deal thx.
  • duke
    Options
    I've been thinking about this kind of thing for things over ~1kb. Your particular situation would require pushing the texture to a webservice and then the url to other clients to download, but for more general situations, i'd have anything < 5mb on a web content server, providing a direct URL (requiring an auth token) to them to download it, and for anything large, have them asynchronously pull down a torrent (via monotorrent, for example), where the main seeder is your content server/s, and any p2p action is a bonus.