|
Socoder -> Blitz -> TCP server - get client IP? |
|
| Wed, 05 Dec 2007, 14:25 | |
flying_cucco
|
Hiya! Quick question, I have a TCP server in blitz2D that is receiving http connections with AcceptTCPStream() Is it possible to get the IP address of these clients? TCPStreamIP() returns my IP, and I don't have a hostname for HostIP(). Any ideas? |
| Sun, 09 Dec 2007, 10:59 | |
|
Teasy |
not sure what the context is, but this works for me: not sure what u want to do with HostIP either unless you mean resolving a hostname. maybe u can give a specific example or elaborate a little more. 
|
| Mon, 10 Dec 2007, 15:16 | |
|
flying_cucco
|
I hope this helps Always returns "IP = 192.168.1.10", which is my local IP. I am behind a NAT router, but even so, why my IP and not the client, or even my router? |
| Mon, 10 Dec 2007, 16:42 | |
Dabz
|
Offtopic:- I remember that avator from years gone by... Teasy, are you known as theChange in a former online life? If so... good to see you still dotting around!  Dabz P.S. Carry on! 
-=-=- Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
|
| Wed, 19 Dec 2007, 08:31 | |
|
Teasy |
Maybe your router likes to play tricks on you  You could try forwarding port 80 specifically to your local machine, to become a real server -- e.g. as if it's connected directly to the internet. (you could also try another port ofcourse, e.g. https://myhostname:port/) maDenathorn/Dabz: Hi again!  (note the gimmick: T-C -> Teasy)
|
| Thu, 20 Dec 2007, 11:16 | |
Afr0
|
I can't be bothered to write up another post on this, so I'll just quote my own reply to one of DNA's topics; 'I hope you're not trying to make an MMORPG with Blitz? Or any MMO game for that matter. If so, I wouldn't reccommend it. Blitz uses the select() command internally to accept new connections. Without going into too much detail, chances are you're not going to be able to get a larger throughput than 64 players online at the same time before your server crashes. If you use BlitzMax, you can go up to 900 players if you compile and run your server on Linux, but that's still not a whole lot. I'd reccommend you use C# or C++.NET for the easy route, or C++ for the difficult route. If you wanna use C++, here's some things to look into: A simple IOCP client/server class Writing IOCP Winsock Application - forum thread A simple application using I/O Completion Ports and WinSock Writing scalable server applications using IOCP Winsock tutorial Edit: Or was it 90 players on Linux? o.O Either way, I wouldn't take the chance if I were you.' -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sat, 22 Dec 2007, 14:35 | |
|
Scienthsine |
Afro> I would be interested in more information on this. Just restarted a MUD I was building in BMax, and I've never been told of this limit. Also, it seems to me that someone could change this if that section of BMax is open... or make a better sockets wrapper for it?
|
| Sat, 22 Dec 2007, 14:55 | |
Scherererer
|
Scienthsine? Hello! Weren't you on BC? I think I remember you as the one that made the really cool lighting demo if I'm not mistaken. If I'm thinking of someone totally different then its good to have a new member, otherwise, good to have you back in the community! -=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Sat, 22 Dec 2007, 15:11 | |
|
Afr0
|
@Scienthsine: The two most informable articles I could find on Google within 5 minutes were these: mail.python.org/pipermail/python-list/2001-May/083820.html geekswithblogs.net/quension/archive/2006/06/30/83760.aspx And yes, it's possible to write a different socket layer for BlitzMax - you can access the entire WinSock library natively through some libs that are included. Better, though? Doubt it, at least not for Windows. I recall experimenting with IOCP in BlitzMax, and I got as far as to initialize IOCP and no further, simply because BlitzMax is an inherently non-multithreaded language. As I recall, the program I wrote simply froze or fucked up Windows when I tried to run it. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sat, 22 Dec 2007, 16:34 | |
|
Scienthsine |
Instinct> I was on BC, though I can't remember any lighting demos. I kept to the 2d realm of things back then, though I have done a bit with 3d and shaders since. Afro> About to read those links, but if I understand you right, it's mainly due to the lack of multi-threading? I guess I can see that... guess I'll go read those links now  . Lol, this was just a very different attitude than you had when you first showed up around here (Blitz community)... I remember thread after thread of 'Don't let anyone tell you that mmo's can't be made in blitz!' and 'WoW killer progress'...I guess I would have quite a while before I reached 60-90 players in a MUD anyway. I would be insanely surprised to reach a popularity of 50 players online at any one moment. EDIT: Ohh and btw, I havn't been coding game stuff in pretty much 2 years or so... I keep trying to get back into it, thinking a MUD will help as it won't get slowed by lack of artists, or progress. I can build onto it as it's being run and possibly played some. |
| Sat, 22 Dec 2007, 17:26 | |
|
Afr0
|
Yeah, Scienthsine.. it's mainly due to lack of multithreading. But it's not a good idea to spawn a new thread for each connection either... thereby IOCP. I can't remember exactly how it works, because I've been working with C# and .NET for too long, but basically it's about spreading the load of processing many sockets at once over 3 - 20 (20 is typically a very high number, you shouldn't need many more worker threads than this) threads.
-=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sat, 22 Dec 2007, 18:08 | |
|
Scienthsine |
So I've read up on it a bit. Even though BMax doesn't support MultiThreading, why couldn't someone just launch multiple instances of the server that each handled some of the connections, and then with 1 connection to the main thread, communicated everything? I've never done any multithreaded programming, so I'm a bit new at this... but it seems to me that it'd work almost as well. Furthermore, these could be offloaded to different physical machines, without any structural changes.
|
| Sat, 22 Dec 2007, 21:02 | |
|
Scherererer
|
Generally multithreading only becomes necessary in C# because its entirely event-driven. Since you can't just have it retrieve packets at one point in the game loop, you have to make a loop on a separate thread to allow for the GUI to function based off of the events. You could do it in BMax or BB, and you wouldn't need to launch multiple instances of anything. Just in the main loop, have the program at one point retrieve and send all its data over the intertubes.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Sun, 23 Dec 2007, 05:10 | |
|
Afr0
|
Instinct, who said anything about a GUI? Maybe Scienthsine is making a GUI driven server, but in my experience that's just silly - just stick to a console! Oh and; 'You could do it in BMax or BB, and you wouldn't need to launch multiple instances of anything. Just in the main loop, have the program at one point retrieve and send all its data over the intertubes.' No, you couldn't do it off the bat in BMax or BB, not without limitations. Haven't you read what I've been trying to warn about? Look here! '[Victor Muslin, about select on Windows] > After some experimentation it appears that the number of socket > objects allowed in select is around 64. This seems to correspond to > FD_SETSIZE pre-processor constant defined in winsock2.h. There are three issues here: 1. FD_SETSIZE is used by the Microsoft libraries to allocate space for select-related structures *at compile time*. This makes FD_SETSIZE an absolute upper limit. 2. While you can #define FD_SETSIZE to be as large as you like, there's no guarantee you can actually use that many sockets. You have to consult the docs for your socket provider to find that out (and good luck finding them). 3. You're using an old version of Python. Recent versions have this at the top of selectmodule.c: /* Windows #defines FD_SETSIZE to 64 if FD_SETSIZE isn't already defined. 64 is too small (too many people have bumped into that limit). Here we boost it. Users who want even more than the boosted limit should #define FD_SETSIZE higher before this; e.g., via compiler /D switch. */ #if defined(MS_WINDOWS) && !defined(FD_SETSIZE) #define FD_SETSIZE 512 #endif > However, in C or C++ it is possible to redefine FD_SETSIZE before > including winsock2.h. Is it possible to do something similar in Python > to wait for data on more than 64 sockets at a time? As above, since Microsoft's libraries latch on to FD_SETSIZE at compile time, if 512 isn't enough for you your only choice is to recompile Python from source yourself, or use another approach entirely. > If not, how does one write a server in Python that can have more > than 64 concurrent connections? Leaving that to someone else.' Edit: And no, you don't have to use threads in C# because it is an 'entirely event driven language'. C# asynchronous socket commands are based off of IOCP internally, otherwise they wouldn't be asynchronous! Of course, you can write your own multithreading system around this, but yeah... The only way I could see BB or BMax work with >64 simoultaneous connections would be for Sibly to recompile them from source himself with FD_SETSIZE #define'ed to something like 1000, or simply implement multithreading capability into the languages so someone could write an IOCP wrapper for them. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sun, 23 Dec 2007, 08:01 | |
|
Scherererer
|
I meant that, you generally only need threading when you're using an event-driven GUI; that you don't need threading in this instance because he isn't using an event-driven GUI.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Sun, 23 Dec 2007, 08:33 | |
|
Afr0
|
Ah yes, that's true. But that still doesn't mean he's gonna get more than 64 sockets without threading support in the language to support IOCP. Edit: Not in Windows anyways... Edit2: It is possible that you can simply recompile BlitzMax's networking module (since it's written in BMax) with FD_SETSIZE on your machine set to 1000 or whatever, but I will not personally guarantee for this method, and neither will likely Sibly. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sun, 23 Dec 2007, 15:08 | |
|
Scienthsine |
ok, so is this limit on a per-computer basis, or per-application? Obviously it's defined per application, but you said the actual socket provider limit is also there, is that a limit on all applications using sockets at that time?
|
| Sun, 23 Dec 2007, 15:42 | |
|
Afr0
|
Yes, AFAIK this limit is on a per-computer basis. I believe it's there to prevent cache-leakage in Windows when dealing with too many sockets at once or whatever. However, this was a very good question, so you should investigate further for more accurate answers! -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sun, 23 Dec 2007, 16:39 | |
|
Scienthsine |
My main reason for asking, is that if it where a per-computer basis, I would think MUD hosts and the such would have requirements that yours not use this method, since 10 MUDs all doing that would easily limit the amount of players per one. If IOCP gets around this, then I suppose it's not based on sockets? Sorry if I sound newbish btw. I'm going to look around and see if I can get more information. If it's a per application basis, then the method I proposed above would work to get around it. Even without multi-threading, a kind of 'forced' multi-threading through multiple instances of an application communicating via a socket stream, should work. EDIT This is very specific to WinSock, but I think 4.9 is the same limitations. According to the article, both limits can be sidestepped with multi-threading. This -to me- makes it sound like it's a -per application- situation. More specifically -per thread-. So, I think a simple application that takes data on a socket, and then forwards data across several sockets would work. A better plan would be to program your server application to host certain areas, and connect to other instances of the server. The first instance would set itself up as a 'master', and others would connect to it. This not only should get around the socket number problem, but should also allow instances to be run on separate machines, and still work the same. I think you'll still run into a limit at some point, but this limit should atleast be in the thousands, and the only way I can see getting around that would be to use UDP, as I'd think with it's lack of real connections it would not have this problem. EDIT2 For my MUD, I just need to be able to reach the number of players other MUDs have before. I've seen MUDs with atleast hundreds of players, and MUDs are written using all TCP if they want telnet compatibility... |
| Mon, 24 Dec 2007, 06:16 | |
|
Afr0
|
No, no - if you look here, you'll see that IOCP is still operating with sockets. The thing is that an IOCP (Input Output Completion Port) acts like a kind of a connection switch for the threads attached to it, and when sockets are relayed to this IOCP, they will be relayed to a worker thread as soon as there is one available to do some work on said socket. So yeah, I'm guessing that what you're saying about the socket number limitation being a per thread problem is correct. And yes, some MUDs seemingly has a very large upper connection limit, but that's because most MUD servers are written for Linux/Unix, which has a higher inherent number of sockets it can tolerate using select(), as I already pointed out in the original post. Either that, or they use IOCP on Windows or the Linux equivalent, which is called... hm... bleh, can't remember what it's called. Tried to look up on Google, but couldn't find anything. Perhaps you can? What I *did* find though, was a thread on Gamedev.net that describes IOCP much better than I did here. Here it is! -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Mon, 24 Dec 2007, 07:35 | |
|
Scienthsine |
Cool, cool. Good information. Was nice to talk to you all again, I hope my MUD project won't die off too quickly, and maybe I'll be about for a while. Sorry for hijacking the thread Have a good one, everyone. |
|
|
| |||
|
| ||||