Is it possible for one calculator to act as a server and the rest to be clients? Like one calculator uploads a text file to the main server and leaves, then 5 hrs later another one downloads it from the main server even after the original uploader left the network 5 hrs ago?
Tom, welcome to Cemetech! You should Introduce Yourself when you get a chance. To answer your question, yes, that's perfectly reasonable. In the current CALCnet/gCn systems, a computer program emulating a CALCnet client, by convention given the id 'AAAAAAAAAA', can provide services to the particular virtual hub. If you're dealing with a pure CALCnet network (ie, not connected to gCn), you could easily let one of the calculators be the server, periodically sending a broadcast identifying itself as the server. Clients could listen for those broadcasts to figure out which connected calculator was the server, then send direct put (send) or get (request) messages to that calculator.
Why does the calculator have to identify itself as the server. Shouldn't any message being sent out automatically go to all of the calculators, and only the server responds?
graphmastur wrote:
Why does the calculator have to identify itself as the server. Shouldn't any message being sent out automatically go to all of the calculators, and only the server responds?
That's probably how I would do it. When the calc joins the network it sends out an "I need a server" packet, and the server responds with "oh! oh! That's me!". That way the client doesn't have to wait to get the "I'm a server" packet, and the server isn't broadcasting unnecessary stuff.
Fair enough, I like that design too. Smile If clients joined, on average, with lower frequency than the frequency of an "I am the server" broadcast, your design makes sense. If for some reason they joined at a higher rate, then it would generate more traffic (of course). And I think for something like this it's obvious the former scenario would be the realistic one.
I don't think the server needs to send that out either. I mean honestly, to send stuff to the server, the client would say "I need to send something to the server" and the server would say "I'm a server, you can send it to me"

To receive stuff, it could say "I need this file from a server", and the server would say "I'm the server, and I have your file"

This way, no extra traffic is generated.
graphmastur wrote:
I don't think the server needs to send that out either.
Send what out? There should be some sort of handshake/negotiation. Look at TCP, it does the SYN,SYN/ACK,ACK thing, but that's because it already knows the endpoints. Before that there's a broadcast and IP negotiation and all sorts of stuff under the hood that the calcs don't provide, so for the sake of sanity, you want some sort of "I need a server" "Ok, that's me" "Great, here's the stuff" thing. Obviously you don't need it, you can just have "Here's my stuff", but it makes more sense to give it to the server directly. That's the whole point of handshakes in networking.

It also makes the protocol a little more flexible because you can later add negotiations to the handshake etc. That's why people tend to leave reserved byes in their protocols (especially in the handshake--DICOM has 32 bytes of 0 in a row... I hate DICOM), they can then add on more if they need to.
I understand that. I was just saying that the server didn't have to announce itself directly when a calc joined each and every time. Especially if there's a chance the server could disconnect.
graphmastur wrote:
I understand that. I was just saying that the server didn't have to announce itself directly when a calc joined each and every time. Especially if there's a chance the server could disconnect.
But he's not suggesting the server announce it directly. He's suggesting that when a server sees a broadcast "any servers here?" it respond with a direct (one-to-one/point-to-point) message "yes, I'm a server, and here is what I can do for you."
KermMartian wrote:
graphmastur wrote:
I understand that. I was just saying that the server didn't have to announce itself directly when a calc joined each and every time. Especially if there's a chance the server could disconnect.
But he's not suggesting the server announce it directly. He's suggesting that when a server sees a broadcast "any servers here?" it respond with a direct (one-to-one/point-to-point) message "yes, I'm a server, and here is what I can do for you."

Ah, okay. I misunderstood. i had thought he meant that it was whenever a calc joined, he would determine the server first, not when he actually needed data.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
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 vote in polls in this forum

 

Advertisement