Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C @14, you can use RemoteAddress to identify clients. Create a dict, perhaps, and store the keys as something you can remember (i.e. a unique identifier) and the key as (say) their remote address, or, hell, the entire conn object. Equality comparisons (current.conn == other_current.con) should fail, or the two get info calls. URL: https://forum.audiogames.net/post/490391/#p490391 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C Here is the dir info on current.con'begin_flushBatchRequests', 'begin_heartbeat', 'close', 'createProxy', 'end_flushBatchRequests', 'end_heartbeat', 'flushBatchRequests', 'flushBatchRequestsAsync', 'getACM', 'getAdapter', 'getEndpoint', 'getInfo', 'heartbeat', 'setACM', 'setAdapter', 'setBufferSize', 'setCloseCallback', 'setHeartbeatCallback', 'throwException', 'timeout', 'toString', 'type'I was looking through the getInfo, which also has it's own members, here is the dir on that if you're interested:', 'adapterName', 'incoming', 'localAddress', 'localPort','rcvSize', 'remoteAddress', 'remotePort', 'sndSize', 'underlying'The two most promising candidates I've checked out from that, underlying and incoming, were None and True respectively for both clients, which doesn't help. URL: https://forum.audiogames.net/post/490378/#p490378 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C Here is the dir info on current.con'begin_flushBatchRequests', 'begin_heartbeat', 'close', 'createProxy', 'end_flushBatchRequests', 'end_heartbeat', 'flushBatchRequests', 'flushBatchRequestsAsync', 'getACM', 'getAdapter', 'getEndpoint', 'getInfo', 'heartbeat', 'setACM', 'setAdapter', 'setBufferSize', 'setCloseCallback', 'setHeartbeatCallback', 'throwException', 'timeout', 'toString', 'type'I was looking through the getInfo, which also has it's own members, here is the dir on that if you're interested:', 'adapterName', 'incoming', 'localAddress', 'localPort','rcvSize', 'remoteAddress', 'remotePort', 'sndSize', 'underlying'The two most promising candidates I've checked out from that, underlying and incoming, was None and True respectively for both clients, which doesn't help. URL: https://forum.audiogames.net/post/490378/#p490378 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C @12, the current object, according to my investigations of the C++11 mapping at least, have a conn objectinside them. That, in turn, has its own members. Check out current.conn -- what doesthat tell you f you dir() it? URL: https://forum.audiogames.net/post/490358/#p490358 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C Yeah, I found that pretty soon after posting. Doesn’t really help until I figure out how to distinguish clients, though. URL: https://forum.audiogames.net/post/490274/#p490274 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C @10, the beautiful thing about the engine is that it generates async versions of sync methods. So you can just call the async versions of the operations you define. In all the languages I've checked out all the async functions end with the suffix 'async'. URL: https://forum.audiogames.net/post/490264/#p490264 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C I just had some more time to play around, and here is what I have found.When creating a proxy, unless you specifically tell the program to do it in another thread, it will wait for the connection to be established. This solves my connection issue, but raises another question:If the engine blocks the current thread when connecting, does it do the same when sending packets to the server? Do you have any ideas on how to test this in Python at least?No luck on the current object. Seems to return everything the same for the two clients I had connected to the server. Damn. May have to do it with a hackish way of sending a request for an Id upon connection. Unless, of course, I'm overlooking something, in which case do point me to the section that talks about detecting differences between the clients. URL: https://forum.audiogames.net/post/490245/#p490245 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C I just had some more time to play around, and here is what I have found.When creating a proxy, unless you specifically tell the program to do it in another thread, it will wait for the connection to be established. This solves my connection issue, but raises another question:If the engine blocks the current thread when connecting, does it do the same when sending packets to the server? Do you have any ideas on how to test this in Python at least?No luck on the current object. Seems to return everything the same for the two clients I had connected to the server. Damn. May have to do it with a hackish way of sending a request to the server for an Id upon connection. Unless, of course, I'm overlooking something, in which case do point me to the section that talks about detecting differences between the clients. URL: https://forum.audiogames.net/post/490245/#p490245 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C @6:1-3. Yes, you can, but you'll need to write those functions yourself in your interface, I think. I haven't looked at the API docs too well so I'm not sure but maybe one of the parameters passed into your functions (current) contains that information for you. URL: https://forum.audiogames.net/post/489951/#p489951 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C This is a networking engine. It is up to you how you use it. This has no specific audience in mind. URL: https://forum.audiogames.net/post/489926/#p489926 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
2020-01-01
Thread
AudioGames . net Forum — Developers room : ashleygrobler04 via Audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C Hi, so is this like a networking engine for programming games and software or what? URL: https://forum.audiogames.net/post/489925/#p489925 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C So I am looking into this, and Ethan was correct. This does look rather interesting and somewhat easy to use. My questions are below. Keep in mind that I have read barely past the "hello world" example.1. Can I see that someone has just connected?2. Can I see that someone has lost the connection to the server or went offline?3. Does the engine have features to identify clients? I.e, if clients A and B are logged on, how can I tell that client A sends a message instead of client B?If some of my questions are answered by a later section or chapter (perhaps a more in depth example or something) just tell me to keep reading, lol. URL: https://forum.audiogames.net/post/489919/#p489919 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C
@3, know, its kind of odd. You would think that this, being such a featureful platform, people would be all over it. But that just isn't the case and I can't fathom why.@4, I'll answer your questions as best I can in order, however the manual does give very elaborate explanations to everything you could ever ask (besides post 3, that is, which only the company backing this knows, I'm afraid, at last I think):First: An example of an Ice file:// Every Ice file must have one or more modules
// This is for target language mappings to work properly
// and to enforce generated code isolation
// That is, module A is entirely separate from module B
// Additionally, modules are in namespaces in C++ and C#, packages in Java, and modules in Python, and so on
// Here, we'll define a simple command shell system
module CommandShell {
// An interface defines the various operations that are executable when this interface is created.
// An interface is created through a "proxy" (see the manual) and not instantiated directly
// Each operation (function) declared in an interface is defined in the target language of your choice
// For example, in C++, operations are virtual functions; in Python they are normal functions that do nothing
// It is the implementors job to implement these functions
interface Shell {
// Now come the operations.
// An operation is just a function that is called in the normal application execution flow.
// Actual execution is handled through remote procedure calls (RPC)
// There are two kinds of operations:
// The first is sent from client to server.
// Notice how there are no special keywords; the function looks like a normal function declaration
void sendCommand(string command);
// The next kind is from server to client.
// In this kind of operation, we use the "out" keyword
// to denote that the server is transmitting this data, not the client
// This makes the contract clearer to read and easier to work with in code
// Here, we define an recvCommand function that the server will call,
// sending back the output of the command and its return code
void recvCommand(out string output, out int retCode);
} // end interface
} // end moduleIf I put this in a .ice file and run slice2py on it, this generates the following class and function definitions:# ...
if 'ShellPrx' not in _M_CommandShell.__dict__:
_M_CommandShell.ShellPrx = Ice.createTempClass()
class ShellPrx(Ice.ObjectPrx):
def sendCommand(self, command, context=None):
return _M_CommandShell.Shell._op_sendCommand.invoke(self, ((command, ), context))
def sendCommandAsync(self, command, context=None):
return _M_CommandShell.Shell._op_sendCommand.invokeAsync(self, ((command, ), context))
def begin_sendCommand(self, command, _response=None, _ex=None, _sent=None, context=None):
return _M_CommandShell.Shell._op_sendCommand.begin(self, ((command, ), _response, _ex, _sent, context))
def end_sendCommand(self, _r):
return _M_CommandShell.Shell._op_sendCommand.end(self, _r)
def recvCommand(self, context=None):
return _M_CommandShell.Shell._op_recvCommand.invoke(self, ((), context))
def recvCommandAsync(self, context=None):
return _M_CommandShell.Shell._op_recvCommand.invokeAsync(self, ((), context))
def begin_recvCommand(self, _response=None, _ex=None, _sent=None, context=None):
return _M_CommandShell.Shell._op_recvCommand.begin(self, ((), _response, _ex, _sent, context))
def end_recvCommand(self, _r):
return _M_CommandShell.Shell._op_recvCommand.end(self, _r)
# ...
class Shell(Ice.Object):
# ...
def sendCommand(self, command, current=None):
raise NotImplementedError("servant method 'sendCommand' not implemented")
def recvCommand(self, current=None):
raise NotImplementedError("servant method 'recvCommand' not implemented")
# ...The ShellPrx class is not important and you should not reimplement any of its methods. t handles RPC and all of that stuff you could care less about. The important class is the Shell class. Notice how both methods raise the NotImplementedError exception. If you follow the "writing an application in Python" tutorial in the Ice manual, you will see how they override these methods in the server and client (respectively) and implement them, thereby eliminating that "NotImplementedError" exception because they redefined it.Second: you need .ice files because .ice files define a language-agnostic system for defining a client-server contract. The idea is: if you define your contract in this simple, easy to read language, you can transpile that contract into much more complicated (and generated) code that handles all of the messy details for you, then remplement the functionality you specified in the contra
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C I looked at this, and let's just say that this caused me quite a large amount of confusion.Can anyone chime in with a really simple demo that explains what each line of code does? Why do we need .ice files? Do we need to create them by hand? If so, what should be included? How do we send packets? What does one and two way mean? What does the secure mode offer? I looked at hello example for Python and found nothing helpful in there... URL: https://forum.audiogames.net/post/486365/#p486365 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
2019-12-17
Thread
AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C Hmm, I tried the HelloWorld example and it seems quite interesting. I've been planning to do something similar with auto-marshalizable Rust enums, but this seems to be even better alternative.I'm just wondering, with all that functionality - about 5 supported platforms, even more supported languages, VisualStudio integration, whole architectural design, complex documentation etc. where are users?I have barely found something about this engine on Google, just their official site, a page on Wikipedia, and one stack overflow question, when I specifically searched for it.That of course doesn't necessarily need to mean that it's bad. I'm just wondering, what does that company standing behind it live from.Best regardsRastislav URL: https://forum.audiogames.net/post/486122/#p486122 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: The Internet Communication Engine (ICE) by 0C
Re: The Internet Communication Engine (ICE) by 0C Very interesting thing. I have checked it and it seems great! URL: https://forum.audiogames.net/post/485855/#p485855 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
The Internet Communication Engine (ICE) by 0C
The Internet Communication Engine (ICE) by 0C
This definitely isn't new -- its been out for a while now -- but thought it might make some things easier for networking. The ICE is a framework for building networked applications using a simple, easy to read and understand specification language (called the "Specification Language for ICE" (SLICE)). Despite the extra overhead of using an external language for defining your network operations, this allows a ridiculous amount of flexibility. The ICE runtime supports clients and servers in Matlab, Python, C++, Java, _javascript_, Objective C, Ruby, C#, PHP, and Swift. It also has a set of tools that allow patch distribution for software updates, superservers, and more. The documentation is available over here. It runs on (at least) Windows, Mac, and Linux, though I strongly suspect that it works on far more than that. Plus, its fully open source!A very basic interface for a server-client contract in Slice looks lke this:module test {
interface test {
void print(string s);
}
}The key to realize here is that you define your contract (your operations) in Slice, which are only definitions and not implementations. You implement those definitions in the target language of choice. Yes, the _javascript_ Ice runtime does support running in a web browser, though I'm unsure how you'd get that working.) Also, slice has something called Slice checksums. This allows the client to send a request to the server, asking for a list of all of the stored checksums for the servers contract. The client could then retrieve its own list of checksums for its version of the contract and scan both for mismatches or missing elements. Should it find one, the client can immediately halt and require you to update before continuing. This is nice because you can only have a fully functional system if both the server and client agree on the contract that they both have (that is, both sets of checksums match).What do you guys think? Would this be useful in multiplayer games? (Side note: it works over TCP, UDP, WebSockets, Bluetooth and iAP, though I'm not sure why you'd want to play a game over bluetooth or iAP.) It would greatly ease network management; no longer would you need to focus on implementing a network event loop, you could just let Ice handle that for you. I encourage you guys to check it out -- you might like it!
URL: https://forum.audiogames.net/post/485828/#p485828
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
The Internet Communication Engine (ICE) by 0C
The Internet Communication Engine (ICE) by 0C
This definitely isn't new -- its been out for a while now -- but thought it might make some things easier for networking. The ICE is a framework for building networked applications using a simple, easy to read and understand specification language (called the "Specification Language for ICE" (SLICE)). Despite the extra overhead of using an external language for defining your network operations, this allows a ridiculous amount of flexibility. The ICE runtime supports clients and servers in Confluence, HTML, Matlab, Python, C++, Java, _javascript_, Objective C, Ruby, C#, PHP, and Swift. It also has a set of tools that allow patch distribution for software updates, superservers, and more. The documentation is available over here. It runs on (at least) Windows, Mac, and Linux, though I strongly suspect that it works on far more than that. Plus, its fully open source!A very basic interface for a server-client contract in Slice looks lke this:module test {
interface test {
void print(string s);
}
}The key to realize here is that you define your contract (your operations) in Slice, which are only definitions and not implementations. You implement those definitions in the target language of choice. Yes, the _javascript_ Ice runtime does support running in a web browser, though I'm unsure how you'd get that working.) Also, slice has something called Slice checksums. This allows the client to send a request to the server, asking for a list of all of the stored checksums for the servers contract. The client could then retrieve its own list of checksums for its version of the contract and scan both for mismatches or missing elements. Should it find one, the client can immediately halt and require you to update before continuing. This is nice because you can only have a fully functional system if both the server and client agree on the contract that they both have (that is, both sets of checksums match).What do you guys think? Would this be useful in multiplayer games? (Side note: it works over TCP, UDP, WebSockets, Bluetooth and iAP, though I'm not sure why you'd want to play a game over bluetooth or iAP.) It would greatly ease network management; no longer would you need to focus on implementing a network event loop, you could just let Ice handle that for you. I encourage you guys to check it out -- you might like it!
URL: https://forum.audiogames.net/post/485828/#p485828
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
