Jump to content
  • Advertisement

azherdev

Member
  • Content Count

    207
  • Joined

  • Last visited

Community Reputation

112 Neutral

About azherdev

  • Rank
    Member
  1. I have an already compiled exe that I need to wrap. But I need to create a custom wrapper that will display some UI, do some logic, and then executes the embedded executable. What it is I do inside the wrapper code needs to be controlled by a config file of some sort. Where can I begin to look into doing this? I'm good with C++ / C#.
  2. Quote:Stop fixating over fragmentation and focus on developing a streaming algorithm. Not only will fragmentation become a trivial issue, you'll also reduce working set by a factor of 10-100. Even though 80 clients will be sending 5 Mb files each, you'll only need 10-20Mb additional memory for processing. Basically, this sums it up for me. Thanks guys. PS. This is not a file server. It CAN receive/send files, but it mostly deals with objects. That is why I need to "process" the data (deserialize it, get the object or array of objects, save it to the database, put it in cache, etc.).
  3. Thank you for all of your suggestions. Being that it's a real-time system that needs fast response, barring any 1GB transfers, I am not sure if I can write to a disk and then read back from it, etc. My problem will be array of objects sent back and forth. Object Foo() is 1K and I am sending 400 of them. That is about 400K. I would not want to send the stream to a hard drive, and then process it. I'm hoping to process it all in-memory but without adding to the fragmentation issue of having a byte[400000] and then freeing it. I think I'm going to try to go the route of processing 65K, flushing it, then continue. Just need to account for objects that are spanned accross two fetches and if a single object is greater than 65K. It just might be a limitation of the system: no single object greater than 65K serialized. If someone sends me a file, then that can be streamed easily to a disk.
  4. But I have many clients. Say there are 80 clients connected. They each at some pointed decided to upload 30MB file. There are 80 buffers, 1 for each member. Now, I allocate 30MB buffer per person, 80 people, 2.4GB space. The example I'm worried about is 400K, 3MB, 890K, 200K, 6MB, etc. And then these buffers being freed at various stages. Clients disconnecting. New ones connecting. Soon enough, you won't have LOH space for 400K. I'm using Async methods so multiple clients can be uploaded large files. So far, I have come up with a solution that takes into account 3 scenarios: 1. Header + 16 byte data. This is used if you want to send a date, integer, guid to the server, that's it. Server reads 32 bytes, 16 for header, 16 for data. 2. Header + up to 65K data: When you need to send an object or list of objects that comprise 17 - 65K data. First 32 bytes are read as a header, then up to 65K is filled up by subsequent calls to BeginRead/EndRead. 3. Header + 65K+: This will use my method of having a list of up to 65K entries of byte arrays that contain 65K bytes. Here is where I need to think of how to do it. I might even consider parsing out 65K worth of data on the fly and only have one 65K buffer. Say I send an array of 300 Foo objects. Each objects takes about 1K of space. That is 300K of data. But, I can parse out about 65 of them, de-serialize the data, and flush the buffer. I just need to watch out for when the last object is partially in the buffer at the end, I need to copy the partial data to the beginning of the buffer and continue filling up the buffer again. This way, no need for the array of buffers. But, it is more work. Also, what if a single object takes up more than 65K... that is another edge case to worry about. I need this to be fast and not crash. If edge case of 1GB of data comes along, i'll be fine with some performance decrease, but I won't be fine with a crash.
  5. I understand the idea of pre-mature optimization. This is more to protect myself from worst case scenario. Most of my data transfered will be in few hundred bytes. 80/20 rule. But, I don't want to have an "egg" on my face when customers call in to say my service can't run 4 days without throwing out of memory errors on their 8GB systems. I've encountered LOH issue already on services that have less demand. But I'm not an expert and it seems that my proposed workaround *might* work as intended, even if it's ugly. I'm not worried about speed (GC collecting and compacting cause a stutter here and there) as much as I'm concerned about service crashing due to OOM exceptions.
  6. I am creating a server using the TcpClient sockets. It needs to be able to handle receiving data from 1 byte to about 10MB. The data it receives then needs to be re-processed in-memory. So, I have a buffer to which async calls are made and it is filled up. But, once I hit the 85K or so for the array, it gets promoted to LOH. I can only imagine how fragmented the memory will become when you have 100s of clients sending 100K, 213K, 1Meg, etc of data. My idea was this: array of arrays. Have an array of byte array that is 65K in size. I tried to google about this and can't figure out if that would work. If I had a List<byte[]>. Then say I create 65K list entries of byte[65535]. That would give me 4GB (theoretically). When I free that memory (clear the list and remove all references to the arrays), will GC release all the memory and compact it since the list is not larger than 65K and each of the byte arrays are not greater than 65K? Or does GC do something weird and promote it to LOH even though each individual item is less than 85K? I know I won't have 4GB, but having a client send me few megs will be often.
  7. Got it. So, if my first 4 bytes is the size it should read up to, I can't even count on that? Huh? So, I would need to read into a buffer until I get at least 4 bytes. Then convert that to the size it needs to wait for, then wait for at least that many bytes. Etc etc. Is 0 bytes on ReadBegin possible? Or will it not be called if 0 bytes are received in the payload of the tcp packet?
  8. I'm using the TcpClient and TcpListener in C# .Net 2.0 to create client/server architecture. On the server side, I use BeginRead/EndRead for non-blocking sockets. What I have is a header that is sent before the main payload, the header is 48 bytes long. Can I count on those 48 bytes coming through on a single BeginRead call or will I need to concatinate 31 bytes + 17 bytes, or 1 byte + 1 byte + 1 byte + etc, or whatever comes through?
  9. Hahaha Well, I have cases of Red-bull, cases of 5 hour energy, 4 LCD screens (total of 6792x1200 pixels) all lined up. But even with all that, I have about 30 "started to program before fully designed" projects in my svn repository. This time, I'm going to at least attempt to do it the "right" way.
  10. azherdev

    C# code reuse issue

    What I did in my project is create a base class with the properties I needed and in the derived class would override the properties with a private visibility adding a note in the code that I'm hiding it. Used the 80/20 rule and it worked well.
  11. Thank you for all of your replies. My concern is the "finishing the game" part. Being the only developer probably, I don't have the 3 hours to hunt down some weird memory leak. Doing it in C++ will allow cross compatibility and larger acceptance into the portals, but in C# I might actually finish the product and have at least one download. :) I'm still in design stages of the game so no code needs to be written today.
  12. I'm trying to find if there are statistics as to the install base of .Net 2.0. I understand that any of us can install it easily. But what about my mom that wants to play a tetris like game? How many moms will download a 10Meg game and then be hit up with a prompt to download something else called ".Net" and will be 20+ megs? I deal in .Net a lot and therefore in a bubble of what an average consumer has. Not gamers who have 3 DVD Disc games. Thanks for your nudges over to .Net. :)
  13. I am comfortable with both languages and unfortunately have been away from game development for a few years. Is there still a good reason to use C++ over C# in casual game market? I'm not talking from developer's point of view, but from consumer's point of view. Is .Net 2.0 framework pretty well entrenched in Windows XP / Vista or is it still a burden to have to install for end user?
  14. azherdev

    What path to take.....

    If you are going to get a job in serious game development studio, you will be required to know C++ since it is used for most console game development and AAA titles for PC. But, scripting language will also be a major bonus. As suggested, I'd start with C# to avoid major learning curve of C++ but get the feel for structure and syntax. If you don't have a solid C++ knowledge on your resume, you will not be making anything other than casual games - which might be your thing. In terms of learning, I would suggest: C# -> Python -> C++ On your resume, have at least: C++ (first listed), C#, Python/Pearl/etc My additional 2 cents.
  15. azherdev

    .NET vs Windows API

    Wait, are we comparing Win32 API to .Net API without regard to the language? If so, yes, .Net API is much much better to use and I would not think of writing a Win32 GUI application in C++ with MFC using Win32 calls. .Net WinForms all the way! Even if I'm going to write a Windows Service, it will be in C# with the latest framework I can use. If we are comparing C# (and VB.Net) to native C++, then I would definately recommend learning how to make games with native C++ since your professional options will then not be limited. And I'm talking about proficiency, not making Tetris and thinking you can make an MMO. But, I wouldn't pick to use C# with .Net framework over C++ with Win32 API when developing a commercial game, especially if i'm writing a framework I'd like to reuse for future games, possibly with OpenGL or OSX or Linux or DS or PS3. Remember, if you will apply to work for Blizzard, Activision, EA, or other PC developers, they won't care about .Net framework at all for their game clients or backend servers. You will be required to know C++ and Win32 API very well. Along with a billion other things. :)
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!