Re: pushDataPacket(...) performance

[cumulus dev]

Hi,

You can remove the two lines "client.writer.reliable = false" and "client.writer.reliable = true" (completly useless here? I don't know why you call it).

Then, it's missing a flush just :-)

add:

respPublication:flush();

and it should be good ;-)

2013/2/15 Robert Tarasov <tutank...@gmail.com>

Hello,

It looks like delivery of a packet using pushDataPacket() function can take from 400 and up to 2000 msec.

function onPublish(client,publication)

respPublication = cumulus:publish("metadata_resp");

if respPublication == null then

ERROR("Unable to create publication!");

end

end

function onDataPacket(client,publication,name,packet)

respPublication = cumulus.publications("metadata_resp");

client.writer.reliable = false

respPublication:pushDataPacket("OnData",packet);

client.writer.reliable = true

end

BTW, delivery of a packet from a client to a server is instantaneous:

_sendStream.send("OnData", message);

Am I doing something wrong?

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes OpenRTMFP Cumulus.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse openrtmfp-cumu...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Robert Tarasov]

Thank you,

Actually I guessed about it yesterday (since then I'm trying to read your manual carefully) :). Now everything works just perfect. client.writer.reliable was used before and I just forget to delete these strings, actually, i just tried to find the reason of that delay. 

BTW, I need just udp connection, but there is no such thing as UDP sockets in flash :( .. What I need is low latency communication between 3-5 clients, which have to send very small packets to each other every 15-30 msec. Do you think this way of communication is best solution in terms of using Cumulus server? 

Thank you very much for your project!

[cumulus dev]

Explain it more deeprer, you have need to exchange these packets from client to client, or from server to client (I mean about this 3-5 clients).

UDPSocket (DatagramSocket) is supported in Air (not in Flash, right). Then, RTMFP is UDP based, and you can use RTMFP to exchange between clients (P2P) or by server bypass... Where is your problem? :-)

[Robert Tarasov]

I know that AIR supports UDPSocket, but I can't use AIR... So, I have 3-5 clients per each game session (there can be lot of game sessions on the server) which have to send data to each other (using direct connection), but in some situations clients can't establish direct connection between each other and in that case they have to connect though the server. Another situation when I have to use the server is because I have not the only flash client, but also unity client which uses UDP protocol (not rtmfp).

[cumulus dev]

ok, so your first question was about "UDP packet from server to client".

About RTMFP clients, when P2P fails, you seem using Cumulus publication, it's a good idea, but maybe you could simply use "push" data mechanism "from server to client" (client:writeAMFMessage, see wiki), it's maybe more direct and easy to code.

Then, about Unity client, you can certainly listening packet from Unity client in using cumulus:createUDPSocket() (see https://github.com/OpenRTMFP/Cumulus/wiki/Server-Application,-Sockets) to send it to the RTMFP client (client:writeAMFMessage), and the opposite.

Like that, you have a bridge between "UDP raw of Unity" and "UDP RTMFP of flash".

2013/2/16 Robert Tarasov <tutank...@gmail.com>

[Robert Tarasov]

That is very interested, actually, I thought that client:writeAMFMessage little bit heavier. So, in this case I don't need server->client stream and can just call client:writeAMFMessage ? Will it be more efficient? But in case of client->server communication using NetStream is more efficient than RPC?

About unity - thank you for tip, but I have to support old client's protocol :)

Thank You!!!

[cumulus dev]

"stream" way to communicate between server-client is a "formated" way, designed for multimedia exchange, with some "control" packet (publish, play, sync, etc) to control the stream, certainly useless in your case.

If you want just to compare a data packet sent by "stream" way or direct "RPC" way, it's strictly identical. The two works in the same way (RTMFP-UDP), and their content are alsmot identical.

To get again more fast exchange, you can play with "reliable" option... when it's put on "false", exchange is done without ACK verification (a little more fast), but few packets can be lost sometimes.

2013/2/16 Robert Tarasov <tutank...@gmail.com>

[Robert Tarasov]

Thank You!

Actually, I need low latency communication with high performance server side, but it looks like I can't control the latency and lua is look too slow for my task. About latency:  I send the data every 100 msec from the client using stream:

_sendStream = new NetStream(_connection.connection);

_sendStream.addEventListener( NetStatusEvent.NET_STATUS, OnSendBufferEvent );

_sendStream.dataReliable = false;

_sendStream.publish(_connection.userName,"live");

[...]

private function onTimer(e:TimerEvent):void {

if (_sendStream != null) {

_sendStream.send("OnData", String(_curFrame));

_curFrame = _curFrame + 1;

}

} 

On server side I receive the data and send it back to the user using RPC:

function onDataPacket(client,publication,name,packet)

[...]

client.writer:writeAMFMessage("onPlayerPacket", client.userName, packet);

[...]

end

and client side call back function just prints interval between two calls:

var _timerVal:int = 0;

private function onPlayerPacket(playerName:String, packet:String) : void

{

var nval:int = getTimer();

trace(playerName + " : " + packet + " in (msec) " +  (nval- _timerVal));

_timerVal = nval;

}

And here is what we get:

aaaaa : 0 in (msec) 4611

aaaaa : 1 in (msec) 0

aaaaa : 2 in (msec) 0

aaaaa : 3 in (msec) 0

aaaaa : 4 in (msec) 0

aaaaa : 5 in (msec) 0

aaaaa : 6 in (msec) 0

aaaaa : 7 in (msec) 0

aaaaa : 8 in (msec) 0

aaaaa : 9 in (msec) 2017

aaaaa : 10 in (msec) 0

aaaaa : 11 in (msec) 0

aaaaa : 12 in (msec) 0

aaaaa : 13 in (msec) 0

aaaaa : 14 in (msec) 0

aaaaa : 15 in (msec) 0

aaaaa : 16 in (msec) 0

aaaaa : 17 in (msec) 0

aaaaa : 18 in (msec) 0

aaaaa : 19 in (msec) 0

aaaaa : 20 in (msec) 0

aaaaa : 21 in (msec) 0

aaaaa : 22 in (msec) 0

aaaaa : 23 in (msec) 0

aaaaa : 24 in (msec) 0

aaaaa : 25 in (msec) 17

aaaaa : 26 in (msec) 0

aaaaa : 27 in (msec) 0

aaaaa : 28 in (msec) 0

aaaaa : 29 in (msec) 1983

So, it looks like RPC latency is about 2 seconds. 

[cumulus dev]

you are always facing a flush problem :-)

When you write data for the client, you don't send it immediatly. It has been done like that to be able to "optimize" udp packet in grouping many message in one same packet (you write, and you flush when you want that it goes).

Add a "flush" in your code:

function onDataPacket(client,publication,name,packet)

[...]

client.writer:writeAMFMessage("onPlayerPacket", client.userName, packet);

client.writer:flush();

[...]

end

Finally, know that LUA is very VERY fast :-) I have choose LUA because it's the embedded solution the more light and speed, then I use it just like a "wrapper" for my C++ code, not like a real "script engine". Every LUA call is mapped on a C++ object, finally LUA table contains C++ pointer address, just it. And to finish, I use not "LUA" but "LUAJIT" which allows to compile the script code (on loading) in a native version way (assembler). You can be quiet about LUA ;-)

2013/2/21 Robert Tarasov <tutank...@gmail.com>

[Robert Tarasov]

You're right about flush :). Actually i thought flush doesn't required for RPC... I know that LUA is very fast, actually, several years ago I even chose Lua for my open source mobile rpg game (PocketHeroes). But in my case I have to handle as much as possible clients on one computer, maybe thousands, so, probably I have to implement my own version of simplified RTMFP server which will handle all connection stuff right on protocol implementation level and with using windows things such as i/o completion ports, etc. So, right now I'm just tring to make working model of my C/S and then I'll work on optimization...

Thank you very much for your help and for your project! I really appreciate your concern!

[cumulus dev]

ok, good luck for your project so :-)

By this way, beware this license if you decide to change Cumulus code (you have to share your change with the communauty, see GPL), and know that every I/O operation are async in cumulus, and Cumulus handles many thousands (tens of thousands) players already for some  game compagnies (in production usage).

2013/2/21 Robert Tarasov <tutank...@gmail.com>

[Robert Tarasov]

Thank you,

I think If i'll decide to develop my own server then i won't use cumulus because I also can't use poco and other libraries and I need very limited functionality, so, it will be absolutely different project. Anyway don't worry about that. But I hope I can arrange everything without inventing a bicycle. 

BTW, just in case, do you have any price list or something to let me some information about possibility to license your source code for commercial project?

Thank you!