Vvvv instances communication

vvvv beta question
21

To be honest I haven’t tried it with MultiBoygrouping yet and I am currently a little busy and can’t test it right now.

But I think you “just” have to specify a different _Network Port _ on Boygroup (VVVV Server) for every instance running as server. Then startup the client-instances with localhost + port of every server-instance they should be assigned to. Like this:

H:\vvvvs\vvvv_45beta31.2_x86\vvvv.exe /allowmultiple /server /o H:\foo\ServerInstance1.v4p
H:\vvvvs\vvvv_45beta31.2_x86\vvvv.exe /allowmultiple /server /o H:\foo\ServerInstance2.v4p
H:\vvvvs\vvvv_45beta31.2_x86\vvvv.exe /allowmultiple /client 127.0.0.1:5555  /client 127.0.0.1:5556
22

hmm I couldn’t find limitation for the shared memory in the M$ specs
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
or I am missing something?

cheers

23

I don’t know,
maybe one of devvvvs can enlighten us?
As said before, a SharedMemory (raw) node without size limitation problems would be the perfect scenario.

24

i didn’t check all the details here but just to confirm that the obvious 2k limit of the SharedMemory (Windows) was a bug. anyway we should set it to legacy and provide new Reader (Raw SharedMemory) and Writer (Raw SharedMemory). next you’ll ask for a way to sync them…

25

here we go. alpha now has a fix for SharedMemory (Wikndows). but note, it is a bit tricky (and i find it hard to explain):

internally each of the nodes holds an open handle to the specified location name with a default internal size of 2k. if you resize a location to larger than 2k all of the handles need to be closed first which a single node cannot do if you have a second node open pointing at the same name. see? so as long as you have only one instance of the node (which does not make much sense but still…) you can go > 2k in bytes (but also only with latest alpha). if you have two instances looking at the same name you can only cross 2k if for a moment you point the other instance to another name or even delete it.

anyway that node should be legacy soon and here are the new ones:
Reader (Raw SharedMemory) and Writer (Raw SharedMemory). now we could implement the reader to always only open the handle for reading and then closing it again but i tried that and it costs quite some performance. so i rather introduced a Read and a Write for you to deal with this manually. also syncing should be there and the reader has a helppatch.

from skimming over the thread i understood that (if this is working) this would already solve some issues?

26

Reader(Raw SharedMemory) node doesn’t work for me in alpha. neither 32 nor 64 bits versions.
in the help patch, the value from reader doesn’t update.

27

hm…can anyone else confirm this? the helppatch works for me here…

28

For me doesn’t work
win 7 64bit
latest alpha (32-64 )

29

m and how about the SharedMemory (Windows)? it should no longer have a size limit. does its helppatch work for you?

30

SharedMemory (Windows) x86-x64 helppatches have a red node and say that SharedMemory (Raw) is missing.

31

ah indeed, there was a little bugger left. please now try again latest alpha.

32

Here works. I have a question: is it expected that there’s a frame of difference between writer and reader? I don’t know much about SharedMemory stuff, so sorry if it’s just a newbie question.

readraw86test.v4p (10.0 kB)

33

@h99: since the nodes are not depending on each other order of execution is not determined in this scenario. if you alt+rightlick the reader you’ll see that it evaluates after the writer and returns the result in the same frame…

34

What to say? That’s cool, so to say. Thank you.