Menu
▾
▴
xenocide-programming
|
From: <red...@pr...> - 2003-10-10 00:28:02
|
Well as most of you will realize after seeing the latest diary entries, you will find that lots happened on the Network Library front this latest 2 weeks. The best announcement I can make is that we are ready to go for integration of the network library connection in the local xenocide client-server model. We can use an extension I had made named IPCP (In Process Communication Port) it is lighting fast, as fast as a memory copy (everybody is encouraged to see that is the pure truth :D) The source will be available in 1 or 2 days cause I cannot commit it from this public terminal so Mamutas will be in charge of it (sorry mamu)... Diary Entries [FREQUENTLY ASKED QUESTIONS] - Why do I get exceptions when run from the debugger, is that OK? + Most of the exceptions that you are going to get are OK, you have to make sure that you can continue with your work after it has been raised. ZThread is highly based on the Exception Mechanism to provide a clean task oriented framework, so be aware that raising some exceptions is OK provided that they get cough where they are supposed to. If that means that the application will fail it is NOT OK. - Can I use the current implementation of NetworkLib in W95/W98/WME? + You cant using the devpack provided, you will have to recompile the ZThread library to be able to use it in those OSs. [PROBLEMS TO DISCUSS] - Let the connection change its interface mechanism of communication with the application after it has been created. - How to make the servers cancel the listening after they are listening. [STILL MISSING IN ACTION] - Simulation mechanism (Have to learn ZThreads first). - Implementation of the NetworkLib internal protocol. (Have to learn ZThreads first). - Event Oriented Interface (Have to learn ZThreads first). - NLIP6NetworkAddress. - Implement the Controller deamon thread via the internal run method required by ZThread. - Get information about the IP4 or IP6 current protocol configuration (like what IP's our cards have and anything useful for the user/programmer). [8-10-2003/9-10-2003] (RK) - The definition of the NLIAbstractServer is even more near of being final, will have to test it a little further but it looks like I found an stable design. I EXPECT LOTS OF EVALUATION WORK, GUYS :D - Include ZThread V 2.3.1 compiled binaries into the proposed devpack + new docs section in the devpack + we are going to put it in CVS under devpack.borland name cause it has matured into a very stable devpack. - Modified the signature of the listenForConnections to handle listening errors. Updated both inprocconnection and multirequestserver. - Modified the IPCP Factory to fail with a NLEInvalidAddressType instead of an NLEInvalidParameter exception. - Added a new exception: NLEInvalidAddressType. It is used to signal an unsupported address type sent into a connection factory. For instance send a NLIP4Address into the IPCP Extension. - Added a new exception: NLEConnectionNotReady. It is used to signal a mistake from the user of the library and make the send method to fail cleanly, it is not intended to be caught just signal a mistake on the user part. However we will see cause if catching this exception makes the code more robust and easier to read and write we can review that rule, extensive testing is needed though. - Moved the class NLIConnectionEventListener inside the NLConnection class as a public inner class. - Modified the signature of the NLConnection's send, connect and disconnect methods to add the return of error information. - Blocking Mode is implemented and the In Process Communication Port Extension (IPCP) already support Blocking Mode, modified the Multirequest Server to use a blocking type of connection. - Ported the code to the new ZThread (V2.3.1) implementation, several design changes had been done since ZThread V2.2.11 . If at the time was the best threading library I had ever evaluated, now it is even better. [5-10-2003] (RK) - Found a defect that can probably be caused by the ZThread, cause I was able to isolate it and couldnt find anything wrong. Gonna test with the 2.3.1 release cause I am using the 2.2.11 (the multirequest server generates that error, so it is defective right now and not included in CVS). UPDATE: The defect was caused by the library, it disappear when ported to the new version. - Modified the NLIAbstractServer to make it easier to use and implement servers using it. Modified the examples to show the changes. - Created a new example, a multirequest syncronized server using the In Process Communication Port Extension (multirequestserver.bfg) at the Examples project file. It shows the use of CountingSemaphores to implement an asynchronic incoming requests processing list. - Minor error corrections in the In Process Communication Port Extension (IPCP Extension) regarding threaded environment. [2-10-2003/4-10-2003] (RK) - Created and Debugged the one request server/client example using the In Process Communication Port Extension (inprocextension.bfg) at the Examples project file. - Added an ASynchronious request processing to the NLIConnectionFactory. - Added Server synchronization for abstract servers (they block after a listenForConnections until a new connection is entablished). - Modifications to the whole library because of minor wrong assumptions regarding thread implementation (more work needed yet, nothing too critical). [1-10-2003] (RK) - Implemented the NLInProcFactory and NLInProcConnection, still have to test them, but the code is already in place and compiling. - Added a NLInProcAddress class to be used exclusively by the In Process Connection Mechanism. [9-9-2003] (RK) - Added Runtime Exceptions classes, throw exceptions when appropiate. For now all unimplemented methods throw a NLEOperationUnsupported exception on call. - Added a getConnectionType method to know what type of connection is used. - Implemented NLController class, some missing details like how to find out the local IP addresses given by the network cards. - Completly redesigned the NLNetworkAddress, made it more a la java. Added the NLIP4NetworkAddress and NLIP6NetworkAddress will be layed out to be implemented after everything is done. [8-9-2003] (RK) - Modify the signature of the internal methods at NLConnection class (the ones that are implemented to have a full fledge and working connection object). - Implemented NLConnection. - Added extra documentation on the NLConnectionStatistics class. - Delete the createEmptyPacket method at NLController. - Fixed header dependency graph (I had ordered and removed useless #include directives). Enjoy... Greetings Red Knight |
|
From: mamutas <ma...@pr...> - 2003-10-12 04:37:30
|
The code is in CVS already. :) -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of red...@pr... Sent: Thursday, October 09, 2003 7:27 PM To: xen...@li... Subject: [Xenocide-programming] Network Library Update Well as most of you will realize after seeing the latest diary entries, = you=20 will find that lots happened on the Network Library front this latest 2 weeks.=20 The best announcement I can make is that we are ready to go for = integration of=20 the network library connection in the local xenocide client-server = model. We can use an extension I had made named IPCP (In Process Communication = Port) it=20 is lighting fast, as fast as a memory copy (everybody is encouraged to = see=20 that is the pure truth :D) The source will be available in 1 or 2 days cause I cannot commit it = from this=20 public terminal so Mamutas will be in charge of it (sorry mamu)... Diary Entries [FREQUENTLY ASKED QUESTIONS] - Why do I get exceptions when run from the debugger, is that OK? + Most of the exceptions that you are going to get are OK, you have to=20 + make sure that you can continue with your work after it has been raised. = ZThread is=20 highly based on the Exception Mechanism to provide a clean task oriented = framework, so be aware that raising some exceptions is OK provided that = they get cough where they are supposed to. If that means that the application will=20 fail it is NOT OK. - Can I use the current implementation of NetworkLib in W95/W98/WME? + You cant using the devpack provided, you will have to recompile the=20 + ZThread library to be able to use it in those OSs. [PROBLEMS TO DISCUSS] - Let the connection change its interface mechanism of communication = with the=20 application after it has been created. - How to make the servers cancel the listening after they are listening. [STILL MISSING IN ACTION] - Simulation mechanism (Have to learn ZThreads first). - Implementation of the NetworkLib internal protocol. (Have to learn ZThreads=20 first). - Event Oriented Interface (Have to learn ZThreads first). - NLIP6NetworkAddress. - Implement the Controller deamon thread via the internal run method required=20 by ZThread. - Get information about the IP4 or IP6 current protocol configuration = (like=20 what IP's our cards have and anything useful for the user/programmer). [8-10-2003/9-10-2003] (RK) - The definition of the NLIAbstractServer is even more near of being = final,=20 will have to test it a little further but it looks like I found an = stable=20 design. I EXPECT LOTS OF EVALUATION WORK, GUYS :D - Include ZThread V 2.3.1 compiled binaries into the proposed devpack + = new=20 docs section in the devpack + we are going to put it in CVS under=20 devpack.borland name cause it has matured into a very stable devpack. - Modified the signature of the listenForConnections to handle listening = errors. Updated both inprocconnection and multirequestserver. - Modified the IPCP Factory to fail with a NLEInvalidAddressType instead = of an=20 NLEInvalidParameter exception. - Added a new exception: NLEInvalidAddressType. It is used to signal an=20 unsupported address type sent into a connection factory. For instance = send a NLIP4Address into the IPCP Extension. - Added a new exception: NLEConnectionNotReady. It is used to signal a mistake=20 from the user of the library and make the send method to fail cleanly, = it is not intended to be caught just signal a mistake on the user part. = However we will see cause if catching this exception makes the code more robust and = easier to read and write we can review that rule, extensive testing is needed=20 though. - Moved the class NLIConnectionEventListener inside the NLConnection = class as=20 a public inner class. - Modified the signature of the NLConnection's send, connect and = disconnect=20 methods to add the return of error information. - Blocking Mode is implemented and the In Process Communication Port Extension=20 (IPCP) already support Blocking Mode, modified the Multirequest Server = to use=20 a blocking type of connection. - Ported the code to the new ZThread (V2.3.1) implementation, several = design changes had been done since ZThread V2.2.11 . If at the time was the = best=20 threading library I had ever evaluated, now it is even better. [5-10-2003] (RK) - Found a defect that can probably be caused by the ZThread, cause I was able=20 to isolate it and couldnt find anything wrong. Gonna test with the 2.3.1 = release cause I am using the 2.2.11 (the multirequest server generates = that=20 error, so it is defective right now and not included in CVS). UPDATE: = The=20 defect was caused by the library, it disappear when ported to the new version. - Modified the NLIAbstractServer to make it easier to use and implement=20 servers using it. Modified the examples to show the changes. - Created a new example, a multirequest syncronized server using the In=20 Process Communication Port Extension (multirequestserver.bfg) at the Examples=20 project file. It shows the use of CountingSemaphores to implement an=20 asynchronic incoming requests processing list. - Minor error corrections in the In Process Communication Port Extension (IPCP=20 Extension) regarding threaded environment. [2-10-2003/4-10-2003] (RK) - Created and Debugged the one request server/client example using the = In=20 Process Communication Port Extension (inprocextension.bfg) at the = Examples=20 project file. - Added an ASynchronious request processing to the NLIConnectionFactory. - Added Server synchronization for abstract servers (they block after a=20 listenForConnections until a new connection is entablished). - Modifications to the whole library because of minor wrong assumptions=20 regarding thread implementation (more work needed yet, nothing too critical). [1-10-2003] (RK) - Implemented the NLInProcFactory and NLInProcConnection, still have to = test them, but the code is already in place and compiling. - Added a NLInProcAddress class to be used exclusively by the In Process = Connection Mechanism. [9-9-2003] (RK) - Added Runtime Exceptions classes, throw exceptions when appropiate. = For now=20 all unimplemented methods throw a NLEOperationUnsupported exception on = call. - Added a getConnectionType method to know what type of connection is = used. - Implemented NLController class, some missing details like how to find = out=20 the local IP addresses given by the network cards. - Completly redesigned the NLNetworkAddress, made it more a la java. = Added the=20 NLIP4NetworkAddress and NLIP6NetworkAddress will be layed out to be=20 implemented after everything is done. [8-9-2003] (RK) - Modify the signature of the internal methods at NLConnection class = (the ones=20 that are implemented to have a full fledge and working connection = object). - Implemented NLConnection. - Added extra documentation on the NLConnectionStatistics class. - Delete the createEmptyPacket method at NLController. - Fixed header dependency graph (I had ordered and removed useless = #include=20 directives). Enjoy... Greetings Red Knight ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. = SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED = US provide better services: Click here: = http://sourceforge.net/supporters.php _______________________________________________ Xenocide-programming mailing list = Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.516 / Virus Database: 313 - Release Date: 2003/09/01 =20 |
Thanks for helping keep SourceForge clean.
X