Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Mon Dec 11, 2017 8:49 pm

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: NetCode Questions ...
PostPosted: Wed Nov 18, 2009 8:44 pm 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

Several quesiton about netcode:

Taking some server sample (mania_server.c for example).

In main we are adding a netcall
Code:
raydium_network_netcall_add(broad,RAYDIUM_NETWORK_PACKET_ODE_EXPLOSION,1);

who broadcast message received using broad function.

But loop function already broadcast all received message:
Code:
if(raydium_network_read(&id, &type, str)==RAYDIUM_NETWORK_DATA_OK)
    {
    raydium_network_broadcast(type,str);
//    printf(".");
    }


Is there a trick ?
The message isn't send twice ?

Secondly:

in
Quote:
raydium_ode_network_element_send
or
Quote:
raydium_ode_network_element_send_all

even if no data need to be send over the network For example only static element at this time.

Last line is executed,
Code:
raydium_ode_network_element_send(n,e);
and a packed is send with nelem=0. So a buffer is send over the network with random data.
Trying to filter this cause network server to disconnect client due to inactivity (normal).


Have a nice day.
Ouille


Top
 Profile  
 
PostPosted: Wed Nov 18, 2009 10:45 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
About the first point, I was preparing a short answer, explaining that raydium_network_read() is only supposed to read "main data stream", not netcalls and such things ... but there's a bug somewhere : currently, raydium_network_read() *is* returning netcalls as RAYDIUM_NETWORK_DATA_OK, we should fix that ! (a few bytes saved for bandwidth)

Nice spot !

About the second point, the idea is exactly what you're talking about: avoid timeouts, even if you've nothing to send to the server. In other words, see "nelem=0" packets as keepalive.


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 8:02 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

For second point, to help me: is there a timeout client handling on the client side of the network api ?

I began to search for this, but you probably have a idea.

For the first point ...
What's problem raised by raydium_network_read handling netcall ?
Do you want to block some netcall on server side ?

Have a nice day
Ouille.


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 8:10 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
No timeout on client side, currently. This should be done, during and after connexion to the server.

About raydium_network_read(), yes, the sever should be able to get netcalls and manage it by itself (at least for ACK and timeout management). The function should return NONE in case of a netcall.


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 10:33 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
(tried a patch about raydium_network_read() and netcalls with rev 920. Need more testing, just tested with test6/willt5 currently)


Top
 Profile  
 
PostPosted: Sun Nov 22, 2009 10:36 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
ouille: last revs 921 and 922 needs would have required some comments before committing, since Network API is a very "sensitive" part of the project. Some ideas are good but needs polishing (you've injected some ODE related things in network.c, for instance), some others needs to be discussed. The patch also includes mixed things (changes in log system and a cleanup, live.h cleanup, ...)

I really would like to be consulted before such important changes.


Top
 Profile  
 
PostPosted: Mon Nov 23, 2009 8:43 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

Sorry for communication problem, i didn't think it was so critical :oops: .

Here is some explanations:

For the first point, it is an issue to this thread:Etrange parkinson

NIDWHO work for object created after network connection, not before. DrawBack is ode code in network. I didn't realise potential problem, you're right.Perhaps i can handle this specific part of code in ode_net.c (raydium_network_element_send_*) what do you think about this ?

For live.h api, it is a code cleanup ;) perhaps a big commit with all code cleanup is better.

There is no change to log system. In fact only two define in common.h, but i'll commit the full code when it is done. So thoses two defines have no influence on raydium for instance.

The main idea was to not disturb with unsignificant problems, but for sure i was wrong :(
Revert thoses commit if you want, i'll polish the code and commit again, if you are ok.

Have a nice day.
Ouille.

EDIT: Typo


Top
 Profile  
 
PostPosted: Mon Nov 23, 2009 10:44 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Currently reverted in rev 923. (for future ref: svn merge -r HEAD:920 svn://raydium.org/raydium/trunk)

The trouble is "on my side", I never explained how I want that we work with this network API. Getting the current network stack working "properly" took ages and required a huge amount of tests (up to 5/6 people at the same time, for hours, using various network and Internet access) and revealed that any tiny change (packet rate or size are the best examples) can have a huge impact on "network performance", sometimes without any logic. From this, I'm very suspicious to any change to this API.

Then, don't get me wrong, your ideas are good:
1 - client timeout
2 - connection to a server with "pre-existing" elements on the client. I think we've never tested this (great) idea, since our test applications always started with the connection, before creating anything. I've added raydium_network_client_connect_to() to the console in rev 924 to make tests more easy on this.

But each of these features would require a tested and separate commit, so we can track easily any regression we may found later. And no other cleanup or next-time-feature should interferer in these commits ! :) It makes patch reading very hard, and disallow quick regression tracking.

Can you explain a bit how you've implemented solution for the second point ? For instance, what NID>=1000 means ? And I'm confused by things like memset(data,raydium_network_uid,RAYDIUM_NETWORK_PACKET_SIZE); (ode_net.c, around line 180)

Last point, I'm pretty sure that removing "empty load" packets (nelems=0) is an error. Packet rate is low enough and helps to "stabilize" the network in our "real time" situation (it may sound a bit naive, but network needs a bit of time to adjust timings when rate changes. Jumping from 0 packet/sec to 15 packets/sec is quite "heavy" for instance). But it would require tests, and the best option is perhaps somewhere in the middle (reducing nelems==0 packet rates).


Top
 Profile  
 
PostPosted: Tue Nov 24, 2009 8:28 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,

First:
About timeout, Xfennec says :)
Quote:
No timeout on client side, currently. This should be done, during and after connexion to the server.


So i implement a null packet keepalive, with a new packet type. The period is actually half the timeout period.
Ancient netcode is bugged, with nelem=0 a packet is send but data are not initialised. So a "random" packet is send over the network (from my point of vue). This can cause lot's of problems, if for example some fields are correct and some other not.

Creating a "keep alive" packet is needed (i thought). Sending this keep alive packet at normal packet period is perhaps better than waiting timeout/2.

Secondly:
Pre existant element are not send over the network. Their nid is -1 as the network is not "connected" when element is created.
Then thoses packet are never send over network api, so no NIDWHO ...
As network api support well hot network connection (i make lot's of test about this). This point is really ennoying.

Here is my reverse engenering of network api, hope i'm not wrong !!!
Actually element nid can have two type of value: >1000 and -1
ode_net.c line 487. As it use (raydium_network_uid+1) all network(ed) element will have an nid>1000.
It seem that somewhere in the code element filtering use 1000 as trigger value. I can't find reference now.
The idea is: nid==-1 element is not networked at all.
nid >=0 and <=1000 element is "ready" for network. Just waiting network connection.
nid>1000 normal behavior.

Line 180 in ode_net.c is client time_out handling.
If no element need to be send and timeout/2 time elapsed i send a dummy packet. type RAYDIUM_NETWORK_PACKET_KEEP_ALIVE_CLIENT
To avoid random data in the packet i fill with raydium_network_uid which is a value as an other but fixed.

Hope this clarify a bit things.

I made lot's of tests about thoses modification, on local network but with wide load charge. It not enough for sure, but it work quite well for cases tested.

i'll continue to work on it when we found the correct solution ok ?

Have a nice day
Ouille


Top
 Profile  
 
PostPosted: Tue Nov 24, 2009 11:21 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Quote:
Creating a "keep alive" packet is needed (i thought). Sending this keep alive packet at normal packet period is perhaps better than waiting timeout/2.


I'm OK with you on this point, but isn't that what the current behavior's doing ? Because the other thing here is that you see the old/current behavior as bugged, and I'm not :) When nelems is 0, ODE Net sends a RAYDIUM_NETWORK_PACKET_ODE_DATA packet with the usual header: a 16 bit integer with the number of following ODE elements in the packet (0). I don't see any bug here, even if you're right saying the end of the packet is not initialized. A such packet cannot be "mis-understood" because of this random data, since the header is correct and says that no data is following. It's the same story when there's not enough elements to fill the packet, in facts.

And since we're supposed to talk about connection timeouts on client side, let's make things clear. Are we OK with the idea that what is not currently implemented in Raydium is the case were the server is "shutdowned" while clients are still connected ? If yes, if your code solves this and disconnects the client, I don't understand how and I may need an explanation :)

--

About client hot connection, your idea of [0..999] range for network-ready-but-not-networked-yet elements sounds correct to me. We should probably add a comment somewhere (perhaps ode.h or headers/ode.h) to explain the 3 cases (-1, [0..9999] and 1000+) since it becomes quiet complex. On this subject, your patch seems correct to me as well. I think we can remove "Affecting uid" log messages, and find a nice way to move the code to ode_net.c and remove any dependency on ODE for network.c (a OnConnect callback perhaps ?)

Another quick point, your patch is reducing RAYDIUM_NETWORK_BEACON_DELAY. Is it a "mistake" (a change specific to your applications) or do you think it should be changed in the engine ?

And I've just seen (remembered ?) that capsules are not supported by ODE Net ! :) Another (easy) thing we should add in the TODO.

Since I'm again somewhere in a hotel with the usual crappy/laggy/intermittent WiFi connection, I can't guaranty it will work, but I can try to connect IRC so we can talk about all this a bit more quickly if you want (any preferred time ?)


Top
 Profile  
 
PostPosted: Wed Nov 25, 2009 9:24 am 
Offline

Joined: Sun Oct 09, 2005 10:46 pm
Posts: 759
Hello,
Quote:
number of following ODE elements in the packet (0)
Ok it's a mistake nothing to change on this part.


Quote:
And since we're supposed to talk about connection timeouts on client side
no, in fact i speak about keep alive to avoid connection timeout and not connection timeout itself. There is a "bug" on this part it seem that on specific network confiuration it is possible to connect to a server but data packet are not routed correctly to the server -> TODO.

Quote:
(a OnConnect callback perhaps ?)
I was waiting for your proposal, i'll correct the code and commit for this specific point.

Quote:
RAYDIUM_NETWORK_BEACON_DELAY =1
Mistake ... sorry ... again ...

IRC tonight after 21H if you can, but i can work on hot connection meanwhile.

Have a nice day.
Ouille


Top
 Profile  
 
PostPosted: Thu Nov 26, 2009 10:19 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Nice commits on this subject, ouille ! :)

Just a small (detail) thing: http://raydium.org/svn.php?d=/trunk/raydium/ode.c&v=930
Isn't it possible to move the nid final assignment in raydium_ode_network_element_send() to reduce code duplication ?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group