Pretty much anything that can exist as digital information can be sent from one computer to another, using virtually any protocol (including the protocols Photon uses, the main ones being UDP and TCP).

Photon itself doesn't provide built-in functionality for handling files the way that you want to, however, Photon can send byte arrays, which is what is is good at. Virtually anything can be encoded and decoded to/from a byte array, including files. So, to send files using Photon, the first step would be to figure out a way to convert your file to a byte array, and then back to a file on the other end. There are a number of ways to do this, of which you should be able to find with a quick google search.

Next, you're going to need to make some considerations. Photon is mainly designed to be used as a way to send small, frequent messages between many peers. Commonly, while using Photon as the solution for a networked game for example, we will see that the size of each message being transferred is often in the lower end of the Kilobyte scale. Files, however, quickly use up a huge number of bytes and one small file is likely to be much larger than the common size of a packet that Photon would expect to handle, which would mean that even using Photon to send small files could result in complications. You could work-around this by hacking away at the config file to allow Photon to handle much larger packets, but I would highly advise against this.

If you are not planning to send large files, or frequently send files, try the above solution. If you find that you are not able to get the functionality that you need from Photon, without making drastic changes to the config, then I would suggest hosting your files on an accessible web-server, or file hosting service such as Amazon S3, and simply access the files using a simple HTTP request (separately from Photon).

I hope this helps.

We strongly recommend to use TCP when you insist to send messages of such sizes, as with UDP Photon will perform pretty badly for such huge messages.

Could you give us a little more info on the above? Is it because of "reliable" messages? Definitely keen to know more.

Thanks for the input.

There's quite a bit to talk about here, all very useful information so lets get started!

Setting client expectations

It doesn't make sense to use a less reliable/preferred method simply because the requirements call for it. Requirements can be changed

This is one of the biggest challenges that we face as developers, in general (in any field). The key is setting the expectations of your client. Clients will always want the moon and the stars, and if you turn around to them and say "i'll make it happen", then they will never expect anything less. The idea is to be brutally honest, in a way that they will understand. So, instead of saying "i'll make it happen", you will start with "let me do some research into the best way to do what it is that you want to do, so that I can come back to you with advice", or at least something along those lines. That way, you're setting expectations, and are more in control of what technology and solutions are used. Never, ever, be defeated into using the wrong tools for the job.

Your requirements

Okay so moving on to your actual requirements. Correct me if I am wrong here, but from what I gather so far, your requirements are simply:
- you simply need a way for your "android" peers to "listen" for messages authorized by a server
- you only need a one-way communications (server to android). You may at some point need an android to server communication (file uploads, data modifications etc etc), of which you should be able to do with any one-way communication model.

Potential solutions

As we're on the Photon forum, we'll talk about Photon first. You've already started looking into the built-in applications that come with the server SDK (such as the load-balancing application), but bear in mind what Photon, as a solution, actually is. Photon is merely a low-level framework, that provides tools to use certain, robust, protocols to communicate between computers (such as UDP and TCP). What you see in the built-in applications is the extension of this low-level framework, where these applications make use of it's excellent handling of UDP and TCP communications to implement additional functionality, such as rooms and loadbalancing.

Personally, even if you were to go on to use some of the features that are implemented in the built-in applications, such as rooms and loadbalancing, you would still be using a tiny fraction of what Photon actually offers. I wouldn't necessarily call this "using the wrong tool for the job", but it comes very very close.


If you have experience in web development technologies such as LAMP or WAMP environments, you'll know the traditional request-response (sometimes called question-answer) environment. Using this sort of a model would pose challenges such as making it so that the client (android) has to regularly request updates, rather than the server regularly sending updates to the client. In my eyes this is such a minor issue when you consider how much better these types of environments are at handling file transfers; and when you consider the fact that you don't need the peer-to-peer communications that Photon and similar environments offer. You just need that one-way communication.


To take things a step further, and a little beyond my own knowledge, there are relatively new web-based environments that are more based on the type of communication that you are looking for. Instead of having to request and wait for a response to make any form of communication, these environments revolve around listening for events, which is closer to what it is that you want to do. One of these new technologies is called "node.js". You can read more here: https://en.wikipedia.org/wiki/Node.js. Since it's basically setting you up with a web environment, you would communicate with the server using basic HTTP requests, rather than make a UPD/TCP connection as you would with Photon. Android has many ways to make HTTP requests, so this shouldn't pose any challenges.


This might not be the information that you were looking for, but I can't help but feel that you're currently going down a path that is going to make yours and your client's life much more difficult than it needs to be. A web-based environment I personally feel would be much better suited.