Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Feb 2011
Offline Last Active Today, 12:58 AM

#5283480 RSA message limitation (with C++ source code)

Posted by on 25 March 2016 - 05:15 PM

I read somewhere that if used incorrectly, RSA has the security of the lowly Caesar cipher. To get around this, one is supposed to add a pad of (pseudo-)random numbers to the message. Do you put the pad at the beginning of the message, or at the end? Or both?



#5282279 How to abort a file transfer immediately?

Posted by on 20 March 2016 - 11:51 PM

Let's say I did that, now I am sending a file through the first socket, and after a while I decided to abort the file transfer, so I send the string "file transfer aborted" through the second socket and then this string is received by the other end, what should the other end do now?


The second end can then "gracefully" close his socket and let the OS clean up in the background while it moves on to other stuff since it now knows the transfer is aborted. That's if you really want to close it gracefully; like I said, if you need to tear down a connection NOW and don't care what happens to the data already committed to the TCP stream, then a hard shutdown is acceptable (to be fair, such situations are rare; when transferring large files it is common to transfer them block by block with, depending on your requirements, periodic status and integrity checking, which allows you to send control information over the same socket with minimal latency).

#5282273 How to abort a file transfer immediately?

Posted by on 20 March 2016 - 11:14 PM

Yes, that is what "gracefully" means. Another way could be to keep a separate connection with another socket over which you send control information ("file transfer started", "file transfer complete", "file transfer aborted" and so on).


Also, ungracefully closing a TCP connection is not inherently bad, it's only bad in that you may lose buffered data or data in transit that, from the application's perspective, has already been sent (unless the application implements its own acknowledgment protocol on top of TCP). If you're aborting a transfer, you presumably no longer care if the file arrives intact, so it's okay. Just make sure the remote can distinguish between a completed transfer and a prematurely aborted transfer, and make sure the socket is not used for anything else.

#5280659 A ray with an ending position?

Posted by on 11 March 2016 - 02:55 AM

A ray with an ending position is called a segment.

#5279856 How C++ Programs Are Compiled (A Brief Look)

Posted by on 06 March 2016 - 12:51 PM

that _is_ the reason. it has to be able to load anywhere, so it can co-exist in ram with other apps. wouldn't work too well if all apps expected to be loaded at some specific address. what if you tried to run two of them at once?


Replace "apps" with "dynamic libraries" and it'll be correct. Each application already has its own address space all for itself, and maps segments of dynamically loaded libraries into its address space.

#5278429 Vulkan command pools and buffer questions

Posted by on 27 February 2016 - 06:42 AM

If I can't call vkBeginCommandBuffer(), how would a command buffer ever be used? Isn't it a requirement to call vkBeginCommandBuffer() prior to recording any commands in the buffer? Is it that command buffers from a pool without the bit set are already implicitly in a 'recording' state and vkBeginCommandBuffer() isn't required or is vkBeginCommandBuffer() only callable once and can't be used a second time to reset the command buffer (it seems to imply the latter in 5.3 but doesn't really out right state it)?


You can call it once, while the command buffer is still in the "initial state", and it only becomes executable after some commands have been recorded into it for the first time; see the first few paragraphs of "Chapter 5. Command Buffers".


- When vkResetCommandPool() is called are the command buffers just reset or are they destroyed and have to be recreated?


I'm not sure but I think it only resets it, but it may release internally-used host memory depending on the flags passed (that memory would presumably be allocated back when recording a new batch of commands in that command buffer).


Also experimenting with Vulkan so take my comments with a grain of salt smile.png

#5275258 What theory explains this?

Posted by on 11 February 2016 - 05:44 AM

Even of the time length there, it is a fact (is?) that there is no observable acceleration before the object travels its speed? Man, how big force would that be, and it seems to not be emited by matter adjusting during collapse, too few energy to overcame donated energy of contact, right?


There is an acceleration, it's just extremely fast because the objects only touch for a very small amount of time and a large kinetic energy transfer is carried out over that time interval. The acceleration can be huge (like on the order of several thousand g's) but it isn't infinite.

#5275217 Clinical studies on overlooking stupid bugs

Posted by on 10 February 2016 - 10:25 PM

It's not really specific to code or programmers. Have you never re-read a sentence you wrote several times without spotting a repeated article like "the the" or a missing word? Then you get someone else to read it and they spot it instantly, because they didn't write it so they don't "optimize away" the act of actually reading the sentence like you do because you already (believe you) know what's there and they don't.


One thing that I find helps is to add a generous amount of whitespace in your expressions, keep your lines short (not necessarily in terms of characters but in terms of information content) and not just cram everything into a tiny line full of symbols. For the rest, let the compiler check the syntax for you, and make sure that it can catch accessing undefined variables at compile-time or at least runtime with some kind of error. That should make sure that the syntax you write is approximately the syntax you had in mind.


I don't know about others but it's not rare for me to start coding something up, try and compile it 20-30 minutes later and spend a few seconds fixing a dozen little syntax errors or typos that I didn't catch (or didn't bother to) in my new code.

#5275091 Note to self

Posted by on 10 February 2016 - 12:58 AM

Fortunately we had good QA at a previous job, but once I was using SHDeleteFile and apparently instead of deleting a specific directory, I was deleting EVERY directory!




QA noticed it during install once Windows started throwing up errors.  Apparently not all critical files are locked at all times, but when it needs them and they aren't there then it's not a good thing.  XD


Good thing QA "noticed" it laugh.png

#5272402 C++ exceptions

Posted by on 23 January 2016 - 03:56 PM

Also, queue push, regardless of the prototype, can fail. It can fail if it fails to allocate memory, and it could potentially have a ring buffer implementation, that would run out of queue space sooner.


Not necessarily. If the queue uses a fixed-size circular buffer then pushing an item into it can never fail. In many situations old queue items can be discarded over new items.


Using operations that cannot fail whenever possible and making use of transactional memory patterns for destructive operations that could fail is a good way to increase your software's reliability. But that may be overkill for many applications such as games; after all, in a game most of the time you can just abort on error, as long as the player's save file is not corrupted and not too out of date, no harm done.


Although I agree that just checking the prototype isn't enough by itself; you want to have a good read of the library's documentation and maybe peruse its source code a bit to see how it handles errors. When you know for sure that functions that return void legitimately cannot fail, then you are good and can just refer to the prototype for quick reference. Of course, if the library is written by baboons that use longjmp to escape to god knows where on error, do you really want to use it in your software that's supposed to be reliable? smile.png

#5272071 Risks Of Using Computer As Webhost?

Posted by on 20 January 2016 - 05:52 PM

Honestly it's not worth it. You can get away with hosting private, low-availability or low-bandwidth services locally, but for anything more serious such as a public website or a game server you will never meet an acceptable uptime, someone might flood your residential line (super easy) or, worse, if you have a data cap and have a shitty ISP you may find overnight that you've gone 300% over, have been charged $600 over-cap and have had your subscription suspended.


You can get a shared VPS for as low as a couple dollars a month and a dedicated server for $30/mo or less, the difference is they will be sitting in a data center connected to a fat network pipe, will have better uptime, and you can actually use them for mostly anything you want (for many ISP's hosting commercial servers, torrenting hubs or even game servers is against their terms of service).


Also don't forget that if you host a server at home that is separate from your own desktop/laptop/whatever (which is probably a good idea) then you also need to pay for the electricity to run it; and you may find that comes out about as (or more) expensive than just renting hosting... having an appliance running 24/7 is actually pretty costly these days even if it doesn't draw much!

#5270811 Weird access violation when copying data

Posted by on 13 January 2016 - 02:24 AM

Imagine if the entire forum contained "deleted post" in every post of every thread. Please don't remove your questions, it helps no-one and simply means people in the future are led to this thread by its title and find... nothing sad.png if you find your solution please share it for future visitors!

#5270499 Render to a texture

Posted by on 11 January 2016 - 01:07 AM

I believe the swapchain is only used when you commit the backbuffer's contents to your display device using the Present() method. If you are just rendering to a texture, then you just don't present, after drawing you can then retrieve the contents of your texture and do whatever you want with it.


I am pretty sure if you are only doing offscreen rendering (for instance some command line conversion tool) then you don't even need a swapchain at all.

#5270228 One function for several structs in a void**

Posted by on 09 January 2016 - 12:34 AM

*ppVerts is of type void*, so you need to cast it to your array's type (PosCol* in this case).

#5269266 Criticism of C++

Posted by on 04 January 2016 - 03:48 PM

Which is just the issue... pointer arithmetic that lands outside the bounds of an array is undefined behavior. I'm not going to argue that this makes 99% of all programs ill-formed (with haphazard results) because every pointer arithmetic bears a result that is outside the bounds of some array (and given the fact that there is argv, there is always at least one other array).


... what? not some array, the array that is involved in the pointer arithmetic expression! And while that specific part of the standard seems arbitrary in light of the modern, unified, fully byte-addressable memory model of today's architectures, it makes more sense when you view it in the context of segmented memory architectures, where in C you still only have, say, an int* pointer type, but you could have two int arrays in two different memory segments, and it's just not possible to meaningfully, say, subtract the two array pointers, or add an integer to one array to reach the other somehow; with this in mind it makes sense to not have distinct arrays be able to interact in any way (not that most code does this anyway)


EDIT: I think I see your misunderstanding now; the standard states that a pointer not otherwise part of an array may be treated as a one-element array in the context of pointer arithmetic (it is actually very clear on that point)


I agree some aspects of undefined behaviour can seem punishing in that a meaning could have been assigned to the operation that everyone would have been happy with and it would have made life much simpler. But, these things were decided upon a long time ago, and in many cases there were historical reasons for why the standard is written a certain way.