File Transfer

aisaac0009
2015-10-22 03:43:46

I have a quick question. I'm using photon server with the loadbalancing API in android. The employer I am doing this work for wants file transfer functionality from the server to the android. Is this recommended? It's part of the messaging functionality he is wanting. Can files be sent through the connection that android makes to the photon server application? I think he has his mind set on this.

He's not making a game, just using Photon server for it's excellent features using pure Android SDK, no Unity or anything of that nature.

Comments

donnysobonny
2015-10-22 15:47:17

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.

Kaiserludi
2015-10-23 13:08:45

Hi @aisaac0009.

@donnysobonny has already given an excellent answer, but let me add a bit more.

Photon is optimized for small messages with a message size range of up to a few kb. It performs best for messages below about 1kb, but is also working fine for messages of just a few kb (like 5-10kb or so).

The Photon C++ Clients, including the one for Android NDK, have been successfully used with message sizes of up to several megabytes by released games in the wild. 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.

I don't know of anyone who has used the Photon Java Android Client with such message sizes, so I can't say how well that will work if at all.

In general Photon is not intended to be used for file exchange and a dedicated FTP or HTTP file server will do a much better job at this specific task than Photon.

donnysobonny
2015-10-23 14:46:45

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.

Kaiserludi
2015-10-23 15:57:52

@donnysobonny:

I can't tell out of my had why exactly UDP is so much slower for bigger messages than TCP with Photon, but it doesn't really matter too much for you as a user as there isn't much that you could do about it other than using TCP if you intend to send messages over maybe 10kb or so.

We don't care enough about this issue to analyze it in detail, as we rather prefer to concentrate our development efforts on making Photon better in what it is intended to be used for, not on making it better as a UDP fileserver.

aisaac0009
2015-10-30 05:07:10

This is extremely helpful, and I will probably do the actual transfer through native code. It doesn't make sense to use a less reliable/preferred method simply because the requirements call for it. Requirements can be changed. I think he just doesn't want to run ftp or apache or anything of this nature, but wants the photon server to run everything. I know I certainly don't want to code more than I have to, and adding support for multiple file types sounds like a pain in the ass and a half.

I'll have to look around and see what there is, I'm sure this won't take too long crosses fingers

aisaac0009
2015-10-30 08:48:49

I guess another question I might piggyback onto this forum, since everyone here is more knowledgeable. I'm not actually using the Photon Server for a game. I know this seems odd, but he wants an application of sorts with client server capabilities. I'll explain what I'm doing and how I was going to do it.

We're creating a server application that will only have one "server" that just sends messages out to clients. From what I understand of Photon, it uses rooms, which is perfect. I am reading about the load-balancing application, and see that once you join, you can ask it to create a game and send you to the best game server. Which is pretty cool, but all I really need is for my Android clients to connect to the server machine and all receive messages from the one application/"Server Logic", they don't need to talk to each other, nor is any load-balancing actually necessary. The "Server Logic" just does some tasks on the local machine, and sends timed messages to anyone who happens to be listening. So the lobby/room concept is great. And regardless, my employer wants it this way, who am I to argue.

To get to the point:
Even though I have small requirements for client/server interaction, should I still stick with LoadBalancing API, or can I just use the Lite library/photon-android

I'm just unfamiliar with this server, and though you might have suggestions. I read on the forum somewhere that LoadBalancing was preferred, but I'm reading that LoadBalancing is built upon lite. I'm trying to keep the code very compact, and reducing any unnecessary functionality.

What is the suggested workflow?

EDIT:
I've done some more poking around on the forum, and have read that room based logic is a bad idea. Can the server logic that loads into photon server at start be anything I want it to be? Suppose I should be more specific about the design. The app operates on a private local network, so all clients will be on this network with the server. But clients will always have to be able to receive messages from the "server", to receive notifications. Does the connection time out once made? If so, will the client have to run a listener 24/7 that keeps the connection open, and if I have say 50 or more clients all connected, will this have a negative impact on the local network? Or can I disconnect then be notified that I should connect?

How many clients do you think is unsafe for one room?

donnysobonny
2015-10-30 13:41:26

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.