peoplevrtater - People at Savannah: View a Job


IP network code, hashing for vrtater

Category: Developer
Submitter: green8
Date: Tue 03 Sep 2013 04:32:33 AM UTC
Status: Open

This group is not part of the GNU Project.

vrtater GNU free software

Peer to peers VR.  In pre-alpha.  Written in C providing engine for 'virtual' 'objects'(vobs) /w haptic/other qualities, and facilities for creation, transformation and interaction of vobs.  Now gcc compiles with automake.  Include's gl.h, glx.h, and or others will support i/o and feedback.  The person who runs vrtater will be able to connect their VR representation through peer continuing node to, or accept simultaneous node connections from, others on vrtater peers with node(s) who do likewise.  Thereafter people may interact through their vobs through vrtater's facilities.

To get/compile the source, download a snapshot of the latest milestone from:;a=shortlog

To develop or add to vrtater, please see the README.  You may want to send a patch, or to join as a maintainer.

License GNU General Public License v3 or later

Development Status
: 2 - Pre-Alpha

Details (job description, contact ...):

vrtater needs IP network code.  Similar: chat, multicast... Description: Code is called for transfers per each display update.  Transfers are preemptive both ways.  It also needs to generate a 96 bit hash from a bunch of files, then written to existing struct hash_s.  Pair of these hashes when applied to syncronize pair of vrtater nodes become the sessions for the nodes (not a login per say as there is no authentication yet).  Given session, url for any session sync has lookup function.  Any of one or multiple receiving sessions locally are behind localhost thru authors code.  Per display update, outbound session data is made available grouped by session as a series of calls with last having NULL reference.  The data passed over the network is already supported as a file (.vrtater).  Read and write (also to/from allocation of int) function already written.  Files from IP network are read by a calling function per list sessions with new data, till none left.  This also happen's once per frame.  96 bit hashes would almost never collide.  Those only sent on sync.  The bottom 32 bits in hash_s are used for total namespace for all sessions in any single scope of sessions.  Any collisions therein are already tended to, however during sync, session will have the rest of the hash to differentiate.  At present one other allocations of data will also need to sometimes transfer per session pair, that being block of sessions.  More than one session is usually behind an interface when initiating sync.  For the code accepting sync data these need to be compounded together thereafter when passed to the specific node in url.  So block of sessions could also be accepted when first session with interface is syncing, as later the program may support forwarding to some degree.  Program will be adherent to GNU standards, so that it might be accepted by the GNU Project.

Required Skills:

Skill Level Experience
C Expert > 10 years
TCP/IP Expert > 10 years

Back to the top

Powered by Savane 3.13-b921.
Corresponding source code