peer2peer / private server

It is a completed fix, but in an area I think needs more work. It would
be good if that fix can go in now, it at least gets Private Servers working.

On 3/04/2013 11:36 PM, Joel Uckelman wrote:

Thus spake Brent Easton:

No, It’s a bug that should be fixed in 3.2.4

Was 8607 a change you were intending for me to pick up on the trunk?
I couldn’t tell from the commit message whether this was a completed
but temporary fix, or if you were simply in the middle of working on
a fix.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Thus spake Brent Easton:

It is a completed fix, but in an area I think needs more work. It would
be good if that fix can go in now, it at least gets Private Servers working.

Merged to trunk@8620.

I’ve uploaded a new build (VASSAL-3.2.4-svn8623) contianing this:

vassalengine.sourceforge.net/builds/

Try it out.


J.

I can confirm that this build works! I still have another problem with it, but that is a different issue.

I tested the build linked above, with blocked Vassal site. 3.2.3 gave me connection errors with all modes, 3.2.4 seems to sort of work.

I was able to connect to an empty (!) server through the legacy server option.
I was able to start private server.
A friend was able to connect to my server. However, he did not bother to block vassalengine.org first, so there’s still a possibility that people connecting to private server require main server at some point.

Note however that he wasn’t able to connect initially due to some external IP issues I don’t quite understand. My invitations simply didn’t reach him until he changed something on his side.

Either way, it’s still a major step forward.

I suggest that you remove player invitations, and instead let the host set the password, and let anyone connect using host’s IP and password. Should be safe enough (works quite well in Gametable) and much more simple to use. The way it currently works, it’s a mess. You need to add every player separately, and the list is not the best solution for people with dynamic IPs.

Invite list does not even save properly - it’s clear every time I restart Vassal.

No, they should not.

If he is sitting behind a router, he will have to enable Port Fowarding (also called Virtual Server) on the router to pass the invites through to his PC.

Yes, that is my plan, to be able to set up other Private Servers in your address book and just select one of them.

Do you plan to implement it in 3.2.4?

No, It is a major job and 3.2.4 needs to be released shortly. I have
made a start with the UI changes but the changes needed under the hood
are more extensive. I hope to get it done within the next week or two,
perhaps for a 3.2.5 release.

On 6/04/2013 1:00 AM, Filip wrote:

Do you plan to implement it in 3.2.4?


Read this topic online here:
peer2peer / private server - #11 by Filip


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6225 - Release Date: 04/04/13


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Well, I’ll gladly do some testing for this feature as soon as you have something.

I am just finishing up a revamp of the Peer 2 Peer networking, ready for 3.2.5. The major changes are:-

  1. Removed the distinction between Server and Client. In a p2p network there is no such thing. There is just one sort of p2p server to choose from.
  2. The ‘Invite Players’ button becomes the ‘Connect’ button. Once you start up the p2p server, you can use the address book to connect to peers. You can connect from either end. A group of players can connect to any peer in any order.
  3. I added a ‘network password’ to the p2p Server definition. Two peers will not connect unless they both specify the same password.
  4. You can define separate p2p networks, each with a different name, password and listening port. Only 1 can be active at a time.
  5. Fixed numerous bugs involving failing connections and hanging threads left running after disconnects.
  6. Rooms are not currently support in p2p mode so I am removing the ‘New Game’ prompt. Everything will happen in the Main Room.

NOTE that there are some caveats with p2p mode. There is no checking whatsoever as to whether players in a p2p network are running the same version of a module, or even the same module.

Brent.

Is this an upgrade of current 3.2 private servers or just a revamp of the old 3.1 p2p connection mode? I’m getting good results running my own server with my 3.1.17 hack, but Vassal wasn’t working properly in our attempts with 3.1 p2p connections. The best we ever got with p2p was a game that involved regular disconnects, and it also messed up our notes and character sheets due to some encoding issues between windows and linux. If you are only revamping p2p rather than providing better private server interface, chances are those issues remain.

Thus spake Brent Easton:

I am just finishing up a revamp of the Peer 2 Peer networking, ready for
3.2.5. The major changes are:-

  1. Removed the distinction between Server and Client. In a p2p network
    there is no such thing. There is just one sort of p2p server to choose
    from.
  2. The ‘Invite Players’ button becomes the ‘Connect’ button. Once you
    start up the p2p server, you can use the address book to connect to
    peers. You can connect from either end. A group of players can connect
    to any peer in any order.
  3. I added a ‘network password’ to the p2p Server definition. Two peers
    will not connect unless they both specify the same password.
  4. You can define separate p2p networks, each with a different name,
    password and listening port. Only 1 can be active at a time.
  5. Fixed numerous bugs involving failing connections and hanging threads
    left running after disconnects.
  6. Rooms are not currently support in p2p mode so I am removing the ‘New
    Game’ prompt. Everything will happen in the Main Room.

NOTE that there are some caveats with p2p mode. There is no checking
whatsoever as to whether players in a p2p network are running the same
version of a module, or even the same module.

Merged to trunk@8658. Try any build from 3.2.5-svn8660 onward:

vassalengine.sourceforge.net/builds/

I looked this over, but it’s a lot of changes. How much testing has
this had?


J.

I spent about 3 days full-time on this in the debugger and across my home network. There where serious problems with the existing version and these changes are desperately needed.

Yes, it certainly does need testing by a wider audience, but it basically didn’t work before and I think rarely used.

Thus spake Brent Easton:

I spent about 3 days full-time on this in the debugger and across my
home network. There where serious problems with the existing version and
these changes are desperately needed.

Yes, it certainly does need testing by a wider audience, but it
basically didn’t work before and I think rarely used.

Hopefully other people on this thread will try it.


J.

Uh, why was the private servers mode entirely removed, when it seems to be working fine in 3.2.4 (other than the impractical interface thing)?

Is it still required that each player adds everyone and connects to everyone else, like with the old p2p?

I didn’t have an opportunity to test it with other people yet. However, it doesn’t seem to save contacts properly. The test entry I added is still there when I restart the module, but if I restart Vassal entirely the entry disappears and the list is empty again.

VASSAL 3.2.5 is working like a champ for P2P games. Me and a buddy installed it and are having no issues connecting directly to each other, to play a game.

Client/Server p2p servers have been replace by a single P2P Network Server type. This combines the functionality of the two. Each play who want to participate in the network need to start this up and have specified matching passwords.

Each player needs to EITHER

Connect to one other player already in the network

OR

be connected to by one otehr player already in the network.

what order you do this and from what direction is flexible. All players can be Connected to by one player, or all can Connect in to one player

I have reproduced this now and am looking into it.

BTW,

Filip, I would very much like the details of your 3.1 hack to get a private server working. I would like to merge this in to the main Vassal.

It may not be possible to get all of the standard server functionality working (messages, historical module usage etc.), do you see this as a problem?

Brent.

The details are in this thread: viewtopic.php?f=2&t=3804&start=30

And I believe initial issues with private servers in 3.2 originated from the same source (i.e. it wasn’t enough to change the URL of getServerImpl, since some classes reference other files hosted at vassalengine.org - my hack now references dummy dropbox files).

I don’t see the lack of messages or server stats as a problem, personally - I’m only starting my server when there’s a game, and we’re using Skype for communication anyway. I even removed the chat input line to free some screen space, as it was redundant for my group’s purposes.

I’m still waiting for an opportunity to test this new P2P mode with other people. It’s a bit complicated, as I don’t even want to bother testing it with just one other person (I recall the old P2P mode was causing some synchronisation issues with three players).

Oh, and one more question:

Care to explain synchronisation mechanism?

In particular, is there any way to ensure everyone is still properly synchronised to everyone else after gaming for a while?

Completely manual. Each player who joins the network must manually synchronize with another player who is already synchonized with the main group.

I’m not quite sure what you mean by this. Once synchonized, players should no become out of sync unless they are disconnected and reconnect, in which case they should immediately re-synchronize.