another small issue : a multi monitor mojo doesn't show as multi monitor on the other computers mouseover settings screen
Printable View
another small issue : a multi monitor mojo doesn't show as multi monitor on the other computers mouseover settings screen
I'm not sure what you mean by check both sides. Mojo doesn't check anything having to do with IP addresses. Here's how Mojo actually works.Quote:
Originally Posted by Moorea
Each Mojo sends out UDP packets to the whole network saying, "I'm a Mojo, call me if you're interested." Meanwhile other Mojos are listening for these packets on all their adapters. There is no special IP address used.
Where the specified IP address comes in (the one you had to change) is that when a Mojo sends out the message, "Call me if you're interested," it has to provide an IP address at which it will be called. In other words, it actually says, "If your'e interested, call me at the following IP address: XX.XX.XX.XX." By default, Mojo lets the OS choose this IP address. That didn't work, so you intevened and chose an address manually. That didn't work either.
What's happening here is (apparently) some peculiarity in the way ICS works. It's possible that it doesn't propagate UDP broadcasts. I don't know anything about ICS. I'll look into it.
Do they have a blue connection? (Blue in both directions?) They won't show up properly if they aren't connected properly.Quote:
Originally Posted by Moorea
another bug: I set my "bring cursor home" key to Ctrl-Home
when I press that key; it leaves Ctrl stuck on the slave the cursor was in (when going back and using the native keyboard/mouse there everything is like if ctrl is pressed; for instance mouse wheel on firefox zooms in/out instead of scrolling)
Edit: On second thought, that's probably the same sort of thing as the old Alt-tab problem. Mouseover gets terminated at the instant you press the Home key. Then, a few milliseconds later, you release the Ctrl key, but by then mouseover is no longer happening and therefore the "release Ctrl" signal doesn't get sent to the remote.
I'll have to change something. Thanks for letting me know.
it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojosQuote:
Originally Posted by Freddie
so to solve the first case; can you send in that msg all the IPs instead of just one ?
it's windows' built in 0 config NAT and it's kind of handy; I expect several people to use it - but maybe not in the weird setup that I have where I try to save 1 wireless latency yet still use extra computers on both side of that natQuote:
What's happening here is (apparently) some peculiarity in the way ICS works. It's possible that it doesn't propagate UDP broadcasts. I don't know anything about ICS. I'll look into it.
the bug I reported about screens is unrelated - I go back to a "working" setup - it's related to my request of wrapping in the faq thread but I didn't want to put a bug report there as it's probably very short lived (you'll fix it soon ;-) )Quote:
Originally Posted by Freddie
I think you are color blind (it's ok, no shame, my dad is too) as it's yellow (or maybe mustard rather as it's a dark yellow) and not purple :-)Quote:
Originally Posted by Freddie
This being said, more seriously/interestingly, why do you need 2 sockets - a socket is bi directional; so you should only need either of the machine to connect to the other; not both
I only get yellowish when my firewall is blocking one or more mojos. But its yellow for sure.
Black for disconnected.
Blue for connected and ready to go.
I need to understand why it's not working before I can fix it. I'll have to set up ICS here, watch the programs in a debugger, log their communications, etc.Quote:
Originally Posted by Moorea
Edit:
I don't understand the two cases. I don't know what "inside" and "outside" mean.Quote:
it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojos
Every IP address that a computer knows about itself is on its drop down list. If at least one of those IP addresses works, you can select it.
If none of them work, then a human being needs to enter it. Send them all automatically won't help if none of them work.
Because I discovered through testing that Windows sockets are capable of making more transmissions per second in one direction than the other. Winsock connections aren't symmetrical in terms of performance.Quote:
Originally Posted by Moorea
IC, Are you sure it's direction issue ? I think what you may have found is you get more throughput using 2 sockets than using 1 (for the same latency, and depending on stack tuning) but the direction itself shouldn't(*) matter - is the difference really noticeable ? Maybe you can fallback to using 1 socket if somehow you can't get the second one ? (though that may make your code more complicated) - I guess sending all IPs would probably work)Quote:
Originally Posted by Freddie
*: I know TCP/IP pretty well; admittedly I have no clue about windows specifics though so I don't know how the folks in redmond may have botched it up so I guess anything is possible...
Quote:
Originally Posted by Freddie
Given what you said about how it works I know why the connection fails: if you send the default (external) IP to the computer using ICS it can't connect to that IP from it's side of the network, which is why it fails - sending all the IPs and trying them all would work
ps: maybe we should use the IRC chat or something so we don't create hundreds of post for a simple dialog :-)
Yes.Quote:
Originally Posted by Moorea
No, because only one connection is used at a time.Quote:
I think what you may have found is you get more throughput using 2 sockets than using 1
Yes, it's quite noticeable during mouseover. That's the only time that Mojo (or HotkeyNet 2 where I first noticed this) tries to make many transmissions per second on the same connection. Cursor motion on the remote is noticeably snappier (a higher FPS rate, so to speak) when the socket connection is used in the preferred direction.Quote:
is the difference really noticeable ?
When the program is mature and fully debugged, at that future time, I'll do that. But if I do it now, it will only conceal problems.Quote:
Maybe you can fallback to using 1 socket if somehow you can't get the second one ? (
I want the problems to be seen and reported to me so I can fix them.
I thought you said that picking different IP addresses from the drop down list didn't fix the problem (or it half solved the problem but not completely). All the IP addresses are on that list. If picking them from the list didn't fix the problem, then sending them automatically won't fix it either.Quote:
I guess sending all IPs would probably work)
In any case, this idea would have some bad effects because normally, on most computers, all the IPs would connect and Mojo would end up with many (possibly many dozens) of socket connections between every pair of computers. If you have two PCs and each one has four interfaces, you'd end up with 4 x 4 x 2 = 32 socket connections. During mouseover, every time you moved the mouse, the local PC would send 16 different TCP packets instead of just one. The receiving Mojo would receive every communication multiple times on every one of its adapters. I would have to add serial numbers to the messages so the receiving Mojo could throw away the duplicates.
To avoid this, I would have to add complicated code to Mojo to audit the number of connections and prune them.
I don't think this asymmetry is particularly surprising, and I don't think it means that Microsoft botched anything.Quote:
*: I know TCP/IP pretty well; admittedly I have no clue about windows specifics though so I don't know how the folks in redmond may have botched it up so I guess anything is possible...
There are always limits to peformance because performance can't ever be infinite. Even the speed of light is finite.
All this proves is that the code for the client end and server end of sockets isn't exactly the same. Since it's not exactly the same it has different maximum performance limits.
By the way, I only tested this on XP and Vista. It may be different in Win 7. For all I know, the situation is reversed in Win 7.
There are two issues, UDP and TCP.Quote:
Originally Posted by Moorea
We don't know if the UDP packets are getting received in both directions.
Regarding TCP, if the problem is what you say, you would have been able to fix the problem by selecting a different IP address from the drop down list.
But you said that didn't fix the problem (or it solved the problem partly but not completely).
You say that sending all IP addresses would fix the problem.
But all IP addresses are on that list. You can select them manually. If sending one at a time (after choosing manually) doesn't fix the problem, then sending them all together automatically won't work either.
and after the first time you put in a post that I'd say it didn't work after setting IP manually:Quote:
Originally Posted by Moorea
followed by another 2 or 3 post on why sending both ip would work... I don't know how else to say it... but it does highlight that using some sort of instant messaging would be much better medium for those than posts (would clear misunderstandings faster)Quote:
it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is [...]
Also to clarify something else; when I say try the other IPs; it means try something else only if the previous one fails; not brute force open many-many connections - in most case it would work as today, and sometime would just make another attempt and succeed if the first connection fails, instead of getting stuck...
Part of the reason I don't understand is that you wrote the following:Quote:
Originally Posted by Moorea
I don't know what "inside" and "outside" mean. I thought you were saying that manual selection didn't solve the whole problem. Or didn't solve both of two problems.Quote:
it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojos
If there are two problems, I don't know what the second problem is.
Before I can do anything -- before I can even think about a solution -- I have to understand the observed behavior.
When you tell me about a problem, what I need is a clear description of the program's visible behavior. That's the priority. I can't do anything without that.
Problem 1
--------------
Step 1: 2 computers A and B; B sharing the A's internet connection (Windows built in ICS feature, need 2 interfaces)
Step 2: start mojo on both
Step 3: on A (the computer which has 2 ips) you'll get a black screen for the B mojo
Step 4: on A go to advanced connection settings; pick 192.168.0.1 instead of "let the operating system choose"
Step 5: 2 mojos are now blue on both A and B and everything now works (which shows it's "fixable")
The bug is step 3 and the need for step 4
My personal opinion again on the fix is that sending both IPs in the UDP packet and having the slave try the second one if the first one doesn't succeed would fix it easily and simply with no downside I can see
Problem 2
--------------
Step 6: Add a 3rd computer C on the "internet" side of A (ie not on same network as B)
Step 7: Start Mojo on C: C is yellow picture (in computers section) and purple text (in geeky stuff section) on A - 3rd column of text shows "C" (B is still blue with "AC"); A is yellow on C; B's screen shows A,B blue unchanged (doesn't see C which is normal)
Step 8: pick the other IP; C becomes blue too
So here again, trying both automatically will fix the problem - More work (and not necessary imo; would introduce complexity), i.e write a proxy, would be needed for C to see B and B to see A (proxied through A)
Diagram
B --------------------> A (ICS share) -------------> C
"private ICS side" ................... "internet side"
(aka 'inside') .............................(aka 'outside')
internet side isn't really the internet; just another network that's not the ICS private one and happens to also have the router to the actual internet
If problem 2 is confusing - just look at problem 1 as fixing it will fix both
Note btw this problem is not specific to ICS - any computer with 2 interfaces where you can't route/access 1 of the IP from the other side will have the exact same problem (ie will advertise the same IP on both side which won't work on one of the network, with again an ez fix (a cleaner fix would actually be to get the IP of each interface and broadcast separately but that's more work and unnecessary)
Thanks
ps: It's 3am here so hopefully this is clear enough - and if not - well I'll try again some other day as I need sleep now
This is a know problem with Windows ICS.
ICS is Windows Native Nat Router software. {Last I checked ICS does not use a standard NAT trasnlation]
What Moorea is experiancing is that his one machine that he is using to Route out to the internet must have 2 IP adresses. one recived by his IP provider to go out to the internet, and a internal private address which his network uses.
On that one machine that is acting as his router Mojo is finding and using the IP provided by his IP provider, and not his internel private address. thus Mojo on that maching is not conecting properly to the other till he goes in and tells that mojo to use the private network.
I suppose to fix that you could put in an algorithm to priortise a private network befor a standard network ip.
However ICS is not considered very efficent Nat Router software so not sure how many serious Multi boxers will use ICS [Internet Conncetion Sharing]
And this can allready be solved on that one pc by going under MOJO connection settings under more optiens and add the private network this then should make it use that network as default.
I think they're talking about on the "left side" and "right side" of a firewall. Why would you put mojo on the outside of your internal firewall?
ICS=Internet Connection Sharing is the built-in NAT feature in Microsoft Windows and allows a Windows PC to “share” its Internet connection to other networked devices. In this configuration, the PC with ICS is directly connected to the Internet in some way (modem, ISDN, etc.) and networked with other computers. The ICS-enabled PC can then share its connection with other Windows computers, acting as an NAT device. In addition, the ICS-enabled PC can automatically assign IP addresses through DHCP.Quote:
Originally Posted by Fursphere
The problem in Mooraes case is that when Mojo is running on the machine running ICS its detecting the IP address provided by the Cable/ISDN Router and choosing this as defualt and not his Private Internal address.
Most of that if I remember correct is how ICS Handles Nat translation and generates its internal DHCP.
Aragent, Fur ^^^Quote:
Originally Posted by Moorea
Thank you very much for taking time to explain this clearly. This is what I needed in the first place. All the time we spent going back and forth about this last night -- what a waste.Quote:
Originally Posted by Moorea
Here's my summary of what happened. Please correct me if I misunderstand.
You had to adjust a setting manually (using the drop down list) to make the computers connect.
After you adjusted the setting by clicking on a drop down list, the program worked perfectly.
You're calling that a bug.
That's my summary. Is that correct?
Please let me know if the program worked perfectly after you clicked on the drop down list. I need to know. Thank you.
True But thats pretty standard in Subnetwork protocol. and normmaly when you want it to pass you setup addvanced network Rounting and port forwarding. but now your getting into more advanced networking, and Those who use subnetworking should be a bit more advanced than the average user and shouldn't have problems with changing the ip address under mojo.Quote:
Originally Posted by Moorea
You guys are assuming that the OS always picks the "wrong" IP address in this situation.
Do you have some basis for believing that the OS's algorithm works this way?
I havent looked at what your using for a discovery protocol, I am making a couple assumptins here. and I will try to look latter and see what MOJO is acually using.Quote:
Originally Posted by Freddie
I am assuming your using DHCP discovery when detecting network addresses and UDP ARP for detecting other running Mojo clients.
Last I looked it was standard when discovering 2 Network IP's especially on one network card, to give Priorty to a Public IP address over a Private one.
I Might have a couple suggestions however I think I should try and see if I can find the accual Code first befor I do.
When a computer has 2 interfaces, using 1 of the IPs on a random interface has 50% chance to be wrong; using that same IP on both interfaces has 100% chance to be wrong; which is exactly what is happening here (causing the user to have to click 10 times to workaround this while it's just a matter of trying both IPs (or asking the correct one from the OS for the correct interface, but that's (again) more work and actually unnecessary when the trying until it works would work just fine))
But I'll rest my case on the topic; spent too much time on this already
I explained what it does earlier in the thread. It broadcasts a UDP datagram. It doesn't use DHCP. It doesn't detect network addresses. It doesn't look at the network in any way.Quote:
Originally Posted by Aragent
The only thing it does with addresses is ask the operating system for a list of IP addresses that belong to the PC it's running on.
If you want to look at the code, it's in class cFinder in the mojo_engine project.
If you want to understand the whole connection mechanism, you'll also have to look at class cPool, which handles TCP communications.
I'm going to go out on a limb here - but running 2 nics in one PC is a non-standard config.
Want proof? Go look at any desktop PC made by Dell, and find me one that comes with two onboard NICs standard.
I use multiple nics in one PC for two things:
1) FIrewall servers (Microsoft ISA, Soothwall, etc)
2) Redundant connections on server hardware.
All laptops come with 2+ nics : wireless and ethernet - if you want the best network performance and have 2 such laptops you will setup the ethernet to try to pay the wireless latency "price" only once - which is again my real (not hyphotetical either) case - if you have 1 wired computer, 2 laptops and want to box you may want to setup the way I had: the 2 laptops linked to each other with ethernet; and the rest in a home network; ie 2 interfaces used with 1 of the laptops in the middle
Anyway, we spend more time arguing whether this is an issue or not than actually fixing it would take - I'm not saying it's the highest priority issue just that it shouldn't be summarily dismissed - typically you weigh the cost vs benefit of any fix to see if it's worth it - here I see big benefit for an admittedly small fraction of users but at a small cost - so personally I'd rank that "medium", not "low" as a result
I look forward to a ticketing system where interested party can follow the issues they care about and the people who do not care don't necessarily have to feel obliged to comment (can "vote" it down if they want I guess) - even if the resolution is "wontfix" at least it'd be documented why etc...
Wheee. Our first drama on the Mojo project. :) Not fun.Quote:
Originally Posted by Moorea
Moorea, nobody is arguing about that except you (in the PM you just sent me).
All I've been doing is trying to find out what the problem is. From your posts last night, I couldn't tell if
(1) Mojo didn't work on your network at all, or
(2) Mojo worked but you had to resort to a manual setting.
Those are very different things.
If I had understood that you were saying (2), I would have told you:
--- The connection code is unfinished.
-- Of course I intend to enhance it.
-- Of course I am going to try to make it connect automatically under as many conditions as possible.
-- I can't talk about solutions for a problem until I understand what the problem is and I'm certain of what caused it.
And I would have made a special build that logs connection events and asked you to run that build on ICS, so I can see exactly what's happening.
Regarding the question of two NICs, I don't want to get too far off track here. But since it came up:
When I wrote the early version of Mojo's connection code that we are using, I ordered a USB wireless adapter from Newegg and plugged it into my development machine.
The whole time I wrote and tested the code, there were two NICs in the machine. I did this to make sure the drop down list works with multiple NICs.
The drop down list is an important part of the program. It's there as a fail safe in case the automatic connection code fails.
At this early stage, the automatic connection code is unfinished. It's buggy. It's unreliable. For that reason, the drop down list is especially important in these early alpha builds.
My priority at this early stage is making sure that testers can use the program enough to test new code as I add it build by build.
Ok, you've got a point.Quote:
Originally Posted by Moorea
But the intent is for the end user to use one or the other, not both at the same time (even though its possible)
And for the record, I said desktop PCs - not laptops.
I'd like to put this thread in perspective.
This is an alpha test. That means you're watching the program's basic features get built. . Nothing is finished. Auto Connect isn't finished.
If a feature seems incomplete, or if you wished it did more than it does, that doesn't mean there's a bug. It probably just means the feature hasn't been finished yet.
Eventually, at some future time, I'll get back to Auto Connect and improve it. But for now, at this stage of the alpha test, as long as everybody can connect with manual settings, that's good enough.
Unless somebody finds a serious problem in Auto Connect that prevents people from using the program I'm not going to work on Auto Connect in the near future because just four days ago we decided on the development schedule for the next few builds. Here's what we decided.
Quote:
Originally Posted by Freddie
my view of a simple straightforward dnp is that it's not tied statically to a given wow but only tied to the focused window: the window under the cursor (or last clicked if the user didn't setup follow cursor) gets everything always and all the other ones get everything except the keys mentioned in dnp - in that sense "launch wow" (step 2 above) shouldn't matter - now again I can see that there is value in having a more complex setup too but I do hope this simple use case stay simple (and dynamic as I said; the "wow" that gets or doesn't get the key change depending on where the mouse is)
but I'll take any new build with any feature in any order either way
ps: this thread should probably die off and move on to another one
The issue that came up here -- the Auto Connect stuff --- is a design recommendation. You noticed that the program required you to use a manual setting and you're recommending that the automatic feature be enhanced so the manual setting isn't needed in that particular situation.Quote:
Originally Posted by Moorea
You want to call this a "bug." That's fine. Call it anything you like. But let's be very clear on what this bug is. You're recommending that I add additional functionality to unfinished code. That's the nature of your "bug."
Recommendations of this kind are very good. I welcome them. I rely on users to design the program. I want people to recommend new features and new functionality.
But I think it would be a bad idea to track design recommendations with a bug tracking system for several reasons.
For one thing, any given design recommendation is a spectrum of possibilities. It's not a single "item." You can't "track" a spectrum of possibilities. You can only discuss it.
For another thing, it would force us to design things prematurely. I want the program's design to evolve iteratively through a process where I publish builds, people react to them and make suggestions, I publish more builds, they react again, etc.
That kind of design is open ended. We make design decisions as we go along. We don't lock ourselves in by writing down what they will be more than a litle bit in advance.
Edit:
I just realized that it would be completely absurd to track design recommendations in a bug-tracking system, because potentially, the number of design recommendations is infinite.
There's no limit to the number of recommendations that people could make.
The purpose of a bug tracking system is to drive the number of entries to zero.
But if you put design recommendations in the system, it never gets to zero. It just gets larger and larger.
Let's keep this discussion in the thread where we're discussing it, okay?Quote:
Originally Posted by Moorea
http://www.dual-boxing.com/showthrea...677#post260677:
Freddie - the only thing missing here is a clear project scope.
"A multiboxing program" is just way to vague. To design and publish a proper scope would take hours / days / weeks / months. This is what there are project development "teams" out there in the wild.
In this fashion you can track scope creep - when new feature requests are outside the original design intent.
But since this project is ad-hoc, the users should treat it as such. Freddie drives, we can all make recommendations on where to stop next, but ultimately Freddie gets to choose how and where we all go.
I'm just happy to be along for the ride. :D
I like the way things worked with HotkeyNet. It was based on the idea "This program is like AutoHotKey, but easier and designed for networks."
That was the whole formal specification. :)
Then I published builds and people made suggestions. More builds, more suggestions, round and round. We just kept doing that for two years.
It worked great, it was fun. Eventually it bogged down because the original code was written in a half assed way and it got hard to add things.
P.S. I'm glad you're along for the ride too. :)Quote:
Originally Posted by Fursphere