sckt - Project Hosting on Google Code

Earlier this year Sep 30, 2009 usage Wiki page commented on by igagis - Hi Ryan, check out my another library which includes threading: http://code.google.com/p/ting/ Actually it also includes sockets now (the latest version in SVN), and I plan to discontinue sckt library support because of that. Also, I am preparing a library for TCP client-server, where server can manage multiple TCP connections in different threads. In C++. Contact me if you are interested in it, I will gather the things up and upload the code, I already created a page for it but did not upload the code yet: http://code.google.com/p/cliser/ Thanks, Ivan Hi Ryan, check out my another library which includes threading: http://code.google.com/p/ting/ Actually it also includes sockets now (the latest version in SVN), and I plan to discontinue sckt library support because of that. Also, I am preparing a library for TCP client-server, where server can manage multiple TCP connections in different threads. In C++. Contact me if you are interested in it, I will gather the things up and upload the code, I already created a page for it but did not upload the code yet: http://code.google.com/p/cliser/ Thanks, Ivan Sep 30, 2009 usage Wiki page commented on by hansonry - Thanks for doing this! I don't think we need to add threading support; that seems a bit outside what this library is trying to accomplish. Although it would be cool if someone else made a project using this library that included threading ;) Also do you think its possible to have something like the SocketSet only with a growable amount of sockets? Thanks again ~ Ryan Thanks for doing this! I don't think we need to add threading support; that seems a bit outside what this library is trying to accomplish. Although it would be cool if someone else made a project using this library that included threading ;) Also do you think its possible to have something like the SocketSet only with a growable amount of sockets? Thanks again ~ Ryan Sep 30, 2009 usage Wiki page commented on by hansonry - Thanks for doing this! I don't think we need to add threading support; that seems a bit outside what this library is trying to accomplish. Although it would be cool if someone else made a project using this that included threading ;) Also do you think its possible to have something like the SocketSet only with a growable amount of sockets? Thanks again ~ Ryan Thanks for doing this! I don't think we need to add threading support; that seems a bit outside what this library is trying to accomplish. Although it would be cool if someone else made a project using this that included threading ;) Also do you think its possible to have something like the SocketSet only with a growable amount of sockets? Thanks again ~ Ryan May 29, 2009 r83 (TCPSocket::GetLocalAddress() function added) committed by igagis - TCPSocket::GetLocalAddress() function added TCPSocket::GetLocalAddress() function added May 21, 2009 r82 (compile for win32) committed by igagis - compile for win32 compile for win32 May 19, 2009 issue 13 (Add Symbian OS support) Status changed by igagis - Status: New Status: New May 19, 2009 issue 19 (Add GetRemoteIP() method to TCPSocket class) Status changed by igagis - first draft changes commited to trunk r81 Needs testing. Status: Started first draft changes commited to trunk r81 Needs testing. Status: Started May 19, 2009 r81 (adding Socket::GetLocalPort() and TCPSocket::GetRemoteAddres...) committed by igagis - adding Socket::GetLocalPort() and TCPSocket::GetRemoteAddress() functions. Not tested. Compiles in linux. adding Socket::GetLocalPort() and TCPSocket::GetRemoteAddress() functions. Not tested. Compiles in linux. May 19, 2009 issue 19 (Add GetRemoteIP() method to TCPSocket class) commented on by igagis - Also add methods to retrieve current local port the socket is bound to (for UDP). Also add methods to retrieve current local port the socket is bound to (for UDP). May 16, 2009 issue 19 (Add GetRemoteIP() method to TCPSocket class) Labels changed by igagis - Labels: Type-Enhancement −Type-Defect Labels: Type-Enhancement −Type-Defect May 16, 2009 issue 19 (Add GetRemoteIP() method to TCPSocket class) reported by igagis - Add GetRemoteIP() method to TCPSocket class. This method will return IP address and port of the connected remote client. Add GetRemoteIP() method to TCPSocket class. This method will return IP address and port of the connected remote client. May 16, 2009 issue 17 (Start using general definitions from ting library.) changed by igagis - Status: New Labels: Priority-Low −Priority-Medium Status: New Labels: Priority-Low −Priority-Medium May 09, 2009 r80 (network to machine and machine to network byte order convers...) committed by igagis - network to machine and machine to network byte order conversion functions added for 16 and 32 bit unsigned integers network to machine and machine to network byte order conversion functions added for 16 and 32 bit unsigned integers Apr 07, 2009 issue 13 (Add Symbian OS support) Labels changed by igagis - Labels: Priority-Low −Priority-Medium Labels: Priority-Low −Priority-Medium Apr 07, 2009 issue 18 (Use getaddrinfo instead of gethostbyname) reported by igagis - Use getaddrinfo() instead of gethostbyname() Use getaddrinfo() instead of gethostbyname() Feb 13, 2009 r79 (IPAddress default constructor moved to hpp and made inline) committed by igagis - IPAddress default constructor moved to hpp and made inline IPAddress default constructor moved to hpp and made inline Older Nov 10, 2008 issue 17 (Start using general definitions from ting library.) reported by igagis - rewrite the sckt so it uses definitions for types etc from the ting library. rewrite the sckt so it uses definitions for types etc from the ting library. Oct 20, 2008 issue 14 (consider changing select() to poll()) Labels changed by igagis - Labels: Type-Enhancement −Type-Defect Labels: Type-Enhancement −Type-Defect Oct 10, 2008 issue 16 (UDP socket uses not expected port) commented on by igagis - by the way, about your question on non-blocking sockets... You can use Socket Sets to check for socket activity without blocking. by the way, about your question on non-blocking sockets... You can use Socket Sets to check for socket activity without blocking. Oct 09, 2008 r78 (tagging release 0.5) committed by igagis - tagging release 0.5 tagging release 0.5 Oct 09, 2008 usage Wiki page edited by igagis Oct 09, 2008 issue 16 (UDP socket uses not expected port) Status changed by igagis - Thanks for testing and confirmation. I have uploaded the version 0.5 of the lib as a zip package, you can find it in Downloads section. Status: Verified Thanks for testing and confirmation. I have uploaded the version 0.5 of the lib as a zip package, you can find it in Downloads section. Status: Verified Oct 09, 2008 r76 (doxygen.cfg file updated to version Doxyfile 1.5.7.1 ) committed by igagis - doxygen.cfg file updated to version Doxyfile 1.5.7.1 doxygen.cfg file updated to version Doxyfile 1.5.7.1 Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by al.s.ivanov - I've tested source code from SVN, so it worked correct with the other socket on this computer. And also I've send some signals by LAN and graped UDP packages with Wireshark. As I can see it works good. I've tested source code from SVN, so it worked correct with the other socket on this computer. And also I've send some signals by LAN and graped UDP packages with Wireshark. As I can see it works good. Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by al.s.ivanov - So I'm using it also as you have told, but my colleague currently working on this problem. So I've shown this lib to him and it was his question. So I'm using it also as you have told, but my colleague currently working on this problem. So I've shown this lib to him and it was his question. Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by igagis - At present, the library does not support non-blocking sockets. It is designed to be used in conjunction with multi-threaded architecture, where the data is received from blocking socket in separate thread and then pass the data to other threads, so the whole program would not block. I may consider adding non-blocking functionality to the library some day. If you have any proposals about interface changing to support that I could consider them as well. At present, the library does not support non-blocking sockets. It is designed to be used in conjunction with multi-threaded architecture, where the data is received from blocking socket in separate thread and then pass the data to other threads, so the whole program would not block. I may consider adding non-blocking functionality to the library some day. If you have any proposals about interface changing to support that I could consider them as well. Oct 08, 2008 issue 8 (Add MacOS support) commented on by al.s.ivanov - Have someone tryed use unix sockets. As I know Mac OS based on unix kernal. Have someone tryed use unix sockets. As I know Mac OS based on unix kernal. Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by al.s.ivanov - I'v just want to ask you about non-blocking sockets, have you got some ideas how could it be done? I'v just want to ask you about non-blocking sockets, have you got some ideas how could it be done? Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by al.s.ivanov - Hello, I've just created few test projects so I've found only one Error. After using htons () function it works correct on Vista. But I haven't tested it in LAN. No other changes was made. According to recv() it works correct. I think I'll test it tonight and write here about results. Hello, I've just created few test projects so I've found only one Error. After using htons () function it works correct on Vista. But I haven't tested it in LAN. No other changes was made. According to recv() it works correct. I think I'll test it tonight and write here about results. Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by igagis - Hi Again, I have just added htons() to UDPSocket::Send(). Could you please take the latest changes from SVN (Head revision) and test them? after your confirm I'll create a package for version 0.5. Hi Again, I have just added htons() to UDPSocket::Send(). Could you please take the latest changes from SVN (Head revision) and test them? after your confirm I'll create a package for version 0.5. Oct 08, 2008 r75 (htons(port) added to UDPSocket::Send() function) committed by igagis - htons(port) added to UDPSocket::Send() function htons(port) added to UDPSocket::Send() function Oct 08, 2008 issue 16 (UDP socket uses not expected port) commented on by igagis - Did you observe the same problems with other UDPSocket functions? (e.g. Recv()) Did you observe the same problems with other UDPSocket functions? (e.g. Recv()) Oct 08, 2008 issue 16 (UDP socket uses not expected port) changed by igagis - Hi, thanks for reporting the issue. So, after you applied htons() to port number passed to IPAddress the things started to work correctly? Status: Accepted Owner: igagis Hi, thanks for reporting the issue. So, after you applied htons() to port number passed to IPAddress the things started to work correctly? Status: Accepted Owner: igagis Oct 07, 2008 issue 16 (UDP socket uses not expected port) reported by al.s.ivanov - What steps will reproduce the problem? 1. Open UDP socket (without port) 2. Define IPAdress structure 3. Use UDP send function with defined IPAdrerss What is the expected output? What do you see instead? Expected using defined port, but Wireshark found some other. I couldn't say how this port was binded What version of the product are you using? On what operating system? Last one avaliable for download 0.4 Please provide any additional information below. I'v used htons() to port number to recieve correct resuls. Also I'm using Vista, so maybe it's only my problem. What steps will reproduce the problem? 1. Open UDP socket (without port) 2. Define IPAdress structure 3. Use UDP send function with defined IPAdrerss What is the expected output? What do you see instead? Expected using defined port, but Wireshark found some other. I couldn't say how this port was binded What version of the product are you using? On what operating system? Last one avaliable for download 0.4 Please provide any additional information below. I'v used htons() to port number to recieve correct resuls. Also I'm using Vista, so maybe it's only my problem. Aug 01, 2008 issue 15 (Socket::SystemIndependentSocketHandle is not large enough fo...) Status changed by igagis - size of Socket::SystemIndependentSocketHandle is now 8 bytes. Fixed in trunk revision 74. Status: Fixed size of Socket::SystemIndependentSocketHandle is now 8 bytes. Fixed in trunk revision 74. Status: Fixed Aug 01, 2008 r74 (size of system independent socket holder changed to sizeof(u...) committed by igagis - size of system independent socket holder changed to sizeof(u64) to make it work on 64-bit Windows platform. size of system independent socket holder changed to sizeof(u64) to make it work on 64-bit Windows platform. Aug 01, 2008 issue 15 (Socket::SystemIndependentSocketHandle is not large enough fo...) commented on by igagis - Hi Dancefire, I have no any experience of working with 64bit machines and I do not have one to experiment. But, I think the problem does exist, I suppose the sizeof(int) on 64bit machine will be 4 (not 8)... can you confirm that? I will change the sizeof(int) to something like sizeof(long long int) then... Hi Dancefire, I have no any experience of working with 64bit machines and I do not have one to experiment. But, I think the problem does exist, I suppose the sizeof(int) on 64bit machine will be 4 (not 8)... can you confirm that? I will change the sizeof(int) to something like sizeof(long long int) then... Aug 01, 2008 issue 15 (Socket::SystemIndependentSocketHandle is not large enough fo...) changed by igagis - Status: Accepted Owner: igagis Status: Accepted Owner: igagis Jul 31, 2008 issue 15 (Socket::SystemIndependentSocketHandle is not large enough fo...) reported by Dancefire - In Windows, the Socket looks like a structure pointer, the sizeof(int) is enough for 32-bit machine, however, it might not be enough for 64-bit machine which is larger than sizeof(int). Could you check it? In Windows, the Socket looks like a structure pointer, the sizeof(int) is enough for 32-bit machine, however, it might not be enough for 64-bit machine which is larger than sizeof(int). Could you check it?

issue 16 (UDP socket uses not expected port) reported by al.s.ivanov - What steps will reproduce the problem? 1. Open UDP socket (without port) 2. Define IPAdress structure 3. Use UDP send function with defined IPAdrerss What is the expected output? What do you see instead? Expected using defined port, but Wireshark found some other. I couldn't say how this port was binded What version of the product are you using? On what operating system? Last one avaliable for download 0.4 Please provide any additional information below. I'v used htons() to port number to recieve correct resuls. Also I'm using Vista, so maybe it's only my problem.

What steps will reproduce the problem? 1. Open UDP socket (without port) 2. Define IPAdress structure 3. Use UDP send function with defined IPAdrerss What is the expected output? What do you see instead? Expected using defined port, but Wireshark found some other. I couldn't say how this port was binded What version of the product are you using? On what operating system? Last one avaliable for download 0.4 Please provide any additional information below. I'v used htons() to port number to recieve correct resuls. Also I'm using Vista, so maybe it's only my problem.

Earlier this year

Older