True, but I know some of those people! I personally run DOS6.22 and Win3.11For Workgroups on my 286 and 486, and then 98SE on my P133, P2/233, and P3/866, and then XP on this P4/3.56. I also run Debian Linux on a Celeron333 and a P200. Game server and FTP server respecitvly. The only real reason I run XP is because I *HAVE* to, to take advantage of my P4. I tried 98SE on this box originally since it is the best Windows OS (largest memory block size, fewest page faults, etc) for gaming (which I do plenty of), but even with the 98SE patches, it shut down so fast data was being lost, it was HORRIBLY unstable for some reason, and it just ran like crap. I guess like if I had a Cyrix chip!

Anyways I did some looking and I think Winsock2 is supported on 95 if you have about a gig of patches, haha! I''lljust code for 98SE and beyond.

-The Great Sephiroth

quote:Original post by foofightr
Suffice to say I think you''re wrong about a lot of things...

Indeed. It''s been a while since I''ve seen so many statements I disagree with in one paragraph

Sounds like you''re a fan of the Visual tools ! I wasn''t trying to bash them to nothing, because they''re a GREAT way for a novice to visually make a window and then look at the code that actually does the work. I remember when I started Win32 coding, I''d have to calculate the crap in my head and visualize it in there too! Sometimes that got annoying, but I got it down after a while.

However, and I don''t care what ANYBODY says because it''s been proven time and again, Visual versions of the same languages are always slower than if the same app was done by hand. The code is almost ALWAYS less organized (hey, it''s a nice app but it isn''t human AI in there), and if you open a Visual app in any text editor (the sources you''re working on, that is) you will see a bunch of extra includes that your app does not need, that are there only because the Visual IDE wants them there.

So if a user is going to write a Visual application, then spend a week to a month optimizing the code so it''ll run good, why not just do it in Wordpad in the first place? The answer for MANY people that I have run across is that they don''t know a lot of the core functions, their arguments, and more. Like I said earlier, I admin three boards at "programmersheaven.com" and a lot of the time, the guys posting Visual questions have no clue about anything beyond the IDE, and when we mention function names, arguments, pointers, memory refereces, and the like, they reply with "huh?".

This isn''t to say there are a handful of true coders who use Visual to get rid of the tedious task of doing the same things over and over again, such as the WinMain() or CallBack functions. Then they do 90% of the actual coding themselves. These guys are fine with me. But the majority of Visual users don''t grasp anything beyond the IDE, and if shown even simple code, will be lost. I''ve been running those boards for a while now, and this is the case nine times out of ten. I didn''t mean to offend any of you, because I know there are good coders out there who simply sue Visual, but I am referring to the majority when I just open my mouth like before.

-The Great Sephiroth

quote:Original post by The Great Sephiroth
Sounds like you're a fan of the Visual tools

Yes and no. I'm a contract programmer, and when I want to quickly prototype a UI for a client, I use visual tools (Borland actually, since I consider the VCL much superior to the MFC for that purpose). Using this method, I can have a pretty functional UI up and running in less than a day, and the client gets a hands on demostration of where I'm going, and can request changes or modifications before I get into serious coding. However, when I get to the actual coding, I usually switch over to vanilla Win32 code, usually, because I prefer to have more control over the controls, so to speak

However, you seem to be failing to make an important distinction. Using an IDE != using VCL || MFC. My code, when written without the libraries, has no more code in it than I put (except for all the standard win libraries we all use). It is no different than using WinPad, except I have all the advantages of the IDE at my disposal, such as color coding the text, smart indents, code stepping, watch windows, class lists, etc, etc. Using WinPad is getting you no advantage, and is actually handicapping you because you are losing out on all sorts of great tools that are there to help you. IMO

But this is the one that got me:

quote:
I've toyed with C++, but it's useless if you already know C.

I so strongly disagree with that statement I can't even begin to go into it There are whole books written on this subject, and if I may suggest, perhaps you ought to look into them to discover why C++ is in fact a superior language to C. C is a fine language, but it can only take you so far. Eventually the complexity of the project will begin to demand OOP techniques, and for that you need C++. I found "C++ Effective Object-oriented Software Construction", by Kayshav Dattatri to be an excellent resource. It takes a while to make the shift from straight C to C++ (it's much the same process as the shift from procedural to event driven programming), but once you do it, you'll never go back, and you'll find you can develop much more complex programs without losing track of what you're doing so much

Anyway, I'm sorry, I don't want to get into a holy war and there are several subjects here that are very volitile and likely to go in that direction If it works for you, use it, far be it from me to act all superior or anything. I'm just suggesting you may want to examine a little closer why C++ and IDEs are so dominant in our industry. It's not an accident that so many smart programmers use these tools

So, to get back on topic and answer your questions (if they haven't already been), UDP packets are guaranteed not to split if they are less than 500 or so bytes (they're not supposed to split even if bigger than that, but my understanding is that some routers will do so). Also if a split UDP packet doesn't come through entirely (if part 2 of 3 was dropped for example) all 3 parts would be dropped (thus you effectively triple your chance of losing the packet).

So:
1) You don't have to worry about dealing with split UDP packets, you should never see them. IF you get them, they are supposed to be complete and in proper internal order.
2) If part of a split UDP gets dropped, the entire packet is silently dropped. For this reason, it is best to keep your UDP packets <= ~500 bytes.
3) Don't have to worry about this.
4) Bascially, yes. As Webby says, you cast into an pointer of chars to send. At the other end, you return them back into the original structure.

quote:
Even if some guy on a 14.4k modem sends a UDP packet that is say, "char Message[8192]", my "recv()" function on the server won't get the packet until it has been COMPLETELY reassembled by the system?

Right. However, it is *very* likely you won't get the packet at all, since it will split up into as many as 16 different packets, and if any one of them is not received, the entire lot will be dropped.

quote:
Is it possible that in a single "recv()" on the server, the server could get a whole packet from guy A and part or all of a packet from guy B?

2 billion, huh? That's a good trick You implied you are using non-blocking sockets(?). You won't get anywhere near that level with them. The IOCP model is your best bet for highly scalable servers. Anyway, to the question at hand, you won't get mixed packets. You won't get a packet complete notification until the entire packet is recieved. It is certainly possible to get packet parts 1-2 (of 3) from client A, then packet parts 2-4 (of 4) from client B, then packet part 3 from client A, then packet part 1 from client B in that order. However, they will (should) be reassembled properly before you get any notification (in this case, you'd get Client A's packet notification first, followed closely by B's).

Hope that helps.

-Ron

[edited by - RonHiler on September 1, 2003 1:01:40 PM]

Thanks, Ron. I''m going to continue my model for the network code on both ends now. The server uses non-blocking but I have yet to make it work in Windoze. I''ll try the method somebody posted earlier in this thread.

And yeah, I shouldn''t have used "IDE" in my statements above. IDEs can be useful, but I have found that most IDEs can make code look funky. Borland is what I use also, and if I install the IDE and use tab instead of spaces of two, half of them come out as actual tabs and half come out as two spaces, so if the source is viewed in any other viewer, it''s mangled. The rest of the IDE is nice though, such as the debugger via menu stuff.

As for C++, I did a lot of research while toying with it. Everything I did in C++ I could turn around and do in C as well, so it didn''t seem worth the effort. My biggest argument on the entire C vs C++ subject is that C++ is converted to C before compiling, so if you already know C, why not just stick with it? Maybe you could explain that to me. I have several books on C++ here at the house, so I could pick it up easily enough, but it''s SO slow to code since just a simple struct (err, class) needs ten times as much code to make it work as it would in C. If you can tell me why it''s worth my time to go to C++ when all it does is get dumped back to what I code in now, I''ll probably make the switch.


-The Great Sephiroth