Determining the size of data being sent from Socket Server

[Frinavale]

I'm implementing a Silverlight application that uses Sockets to receive data that is pushed to it from a Socket Server. (Silverlight only supports the TCP protocol)

The Socket Server pushes a series of images to the Silverlight application which displays them. Every 2 seconds the next image in the series is sent until all of the images have been sent, at which time the Socket Server just starts over again.

Everything's working fine right now but that's only because I've made the receive buffer size for the SocketAsyncEventArgs large enough to accept the whole image file.

When the receive buffer size is smaller than the file more than one packet is sent from the server to the client until the whole file's been sent.

My question is: how do I know how large the file is that's being sent?


Thanks for your time,

-Frinny

[Plater]

Do you control the file sending? Send a datasize first?

[Frinavale]

Thanks Plater,

Yes I control both sides.

I have thought of that solution too but it seems that there should be another way to do this....

The BeginSend method even takes a parameter that indicates the size of the data being sent.

Why can't I see this value client side?

I was actually thinking about serializing each packet so that the size would be included at the beginning....I was reading an article on this last week but when I tried access it this morning it wasn't there any more.....

Maybe this serialization thing isn't the best idea?

-Frinny

[Plater]

Well msdn.com and my local msdn library both seem to be broken when it comes to looking up that SocketAsyncEventArgs object.
If you have access to the socket, you can see how much data is currently on the stream though, that might help a bit?
I generally avoid using ASync stuff for these very "grouping" reasons.

[Frinavale]

@Plater
I have no choice but to use the async stuff because Silverlight requires it.

I have access to the socket, and I can see how much data is currently on the stream but I have no idea how much data's supposed to be sent....how big the end result is supposed to be...so I have no idea how large to grow my "data collection" buffer or when the file actually ends and new data begins. I'm quite a newbie when it comes to Sockets so I might even be over looking a property/method that tells me this...but I did go through every single property/method intellisense displays looking for anything that could help me out.

-Frinny

[Plater]

Well sending a header with the datasize is still my recomended action. This backwards client/server business boggles my mind (I prefer the polling process)
If you send the datasize first, your async thing can go "Ok I'm getting this many bytes" and you can keep appending the bytes to some sort of object until you have them all and create you image object from it.

How do you currently know what seperates image A from image B?

[Frinavale]

@Plater
The whole image fits into the receive buffer right now because I've made the buffer large enough to accommodate the whole file... so it's pretty simple, when I receive the data (in the OnReceive event) I know that it's the whole file.

Right now, for practice, the Socket Server sending static image files (images that exist in a folder) to the client. This is how I was able to determine how big to make the buffer (just used the largest image size); however, in my real world application the socket server is going to be receiving raw byte data from a physical device and pushing that to the Silverlight application. So you can understand why it's important that I some how be able to tell how big the data is.

@Plater
I have no idea how to do this...what should I be keywords would you recommend that I research with to find the answer?

@Plater
Would you do this in a header or in a separate "init" push to the client?

[Plater]

However you want really. You could steal the idea from how http works with a robust header system (you can include things like the name of the image, the size, the type, date modified, any meta-data, etc) or just something simple like the first 8 bytes represent a size and anything after it are bytes for the image.

What happens when a 2nd image is sent before the first one is done being received? Wouldn't the OnReceive events inter-mix with each other? There mose be some way to tell them apart? Perhaps the remote port from the Socket object could tell you which "image" the receive event belongs to?

[Frinavale]

@Plater
I think I'll try sending the file information first and then send the file because at least I understand how that works...I don't know how to get at the header information using the SocketAsyncEventArgs right now and google's not helping me today.

@Plater
I've thought about this problem too but I'm not ready to solve it yet. That's why I have the timer for 2 seconds...and sometimes I extend this

When I'm debugging and have the client paused for more than 2 seconds the server throws an exception saying something or other...I'm not sure what happens when more than one file is sent within milliseconds of each other yet...I'm sure that the packets are going to be all mixed up. Asynchronous Socekts are pretty hard to work with.

I'll look at that later. First I just want to figure out how big the expected data is. Then the bigger can of worms will be opened.

One step at a time :)

-Frinny

[Frinavale]

@Plater
On second thought I think I know how I'll be able to tell them apart......I Think.

When the application calls BeginSend, it will use a separate thread to execute the specified callback method, and will block on EndSend until the Socket sends the number of bytes requested.

I would assume that if a second file were to be sent before the first file it would be queued. I don't know for sure though.

This would kind of defeat the purpose of sending via asyc though.
I'll have to look into this later.

Err, I'm off track now...back to the original problem: determining the size of the file.

[Plater]

Oh! When I said header i didn't specifically mean something relating to the Socket and TCP transfering protocol, I meant like create your own "header"

[Frinavale]

Thanks for your help Plater :)

I sent an "init package" to the client which contained the size of the data before I sent the actual data. From there I was able to allocate the correct amount of memory to the array I'm using to appended the received data to.

[Frinavale]

Hmm this solution is not working well at all.

[Plater]

Are they getting mixed up now?

[Frinavale]

@Plater
How can you tell?

All I know is it's easy to crash this.

I change the implementation to append 2 bytes to the data being sent to the client. The 2 bytes contains an Int16 used to indicate the length of data that's being sent to the client....this way I don't have to send an "init package" before the real send begins.

Now that I've been playing with this more I'm thinking of trying the other way again...where I send an "init package" to the client with the length, and then the data.

The problem that I was having with the original implementation is that if anything takes a bit longer to process than usual (lag) in the client everything sent from the server gets thrown out of sync.

I can't figure out when the begin send/end send is happening to get it back into sync.

I think the something similar is happening with this new implementation when I increase the the timer to a value of 100th of a second...some how the data sent from the server is getting out of sync with the client after some time passes and I open more socket connections to the server.

If I knew when the begin send and end send was happening in the client I would be happy...I think.

And I thought sockets were easy when I first started playing with them :P
It only took me 5 minutes to figure out how to get a synchronized solution to work using a normal windows application (client) and console application (server). Between using asynchronous sockets and Silverlight I'm starting to feel like a newbie.

[Frinavale]

I went back to the first solution again: sending a separate intializing package to the client before sending the data.

When I receive data from the server I check the size of the data and whether or not the I'm expecting an initializing package. If both requirements are met then I reset the Object I'm using to store the data I'm receiving from the server and begin the collection process.

If, while I'm gathering the data, something gets messed up I reset and wait for the initializing package again.

The client code:

Private Sub OnReceive(ByVal sender As Object, ByVal e As SocketAsyncEventArgs)
        Try
            If _isInitPackage And e.BytesTransferred = 4 Then
                Dim amountExpected As Integer = BitConverter.ToInt32(e.Buffer, 0)
                If amountExpected > 0 Then
                    ReDim _receivedData(amountExpected - 1)
                    _isInitPackage = False
                Else
                    _receivedData = Nothing
                End If
            Else
                If _receivedData IsNot Nothing Then
                    If _amountOfDataReceivedSoFar + e.BytesTransferred <= _receivedData.Length Then
                        Array.Copy(e.Buffer, 0, _receivedData, _amountOfDataReceivedSoFar, e.BytesTransferred)
                        _amountOfDataReceivedSoFar += e.BytesTransferred
                    Else
                        ErrorOccurred = "File doesn't fit." + Environment.NewLine + "Amount received so far: " + _amountOfDataReceivedSoFar.ToString + Environment.NewLine + "Amount Expected: " + _receivedData.Length.ToString + Environment.NewLine + "Amount recieved this time: " + e.BytesTransferred.ToString
                        ResetRecieve()
                    End If
 
                    If _amountOfDataReceivedSoFar = _receivedData.Length Then
                        CompletedData = _receivedData.Clone
                        ResetRecieve()
                    End If
                End If
            End IF
        Catch ex As Exception
            ErrorOccurred = ex.Message + Environment.NewLine + ex.StackTrace
            ResetRecieve()
        End Try
        _socket.ReceiveAsync(e)
    End Sub
 
   Private Sub ResetRecieve()
        _amountOfDataReceivedSoFar = 0
        _isInitPackage = True
        _receivedData = Nothing
    End Sub

The Server Code:

 Public Sub Send(ByVal data() As Byte)
        If Not _disposedOf Then
            If IsConnected Then
 
                SendInitPackage(data.Length)
 
                Console.WriteLine("Sending data to client...")
                _client.BeginSend(data, 0, data.Length, SocketFlags.None, New AsyncCallback(AddressOf OnSendCompleted), Nothing)
            Else
                Console.WriteLine("Client is closed: cannot send data to client")
            End If
        End If
    End Sub
 
    Private Sub SendInitPackage(ByVal size As Integer)
        If Not _disposedOf Then
            Dim sizeInBytes() As Byte = BitConverter.GetBytes(size)
            Console.WriteLine("Sending init package to client...")
            _client.BeginSend(sizeInBytes, 0, sizeInBytes.Length, SocketFlags.None, New AsyncCallback(AddressOf OnInitSendComplete), Nothing)
        Else
            Console.WriteLine("Client is closed: cannot init package to client")
        End If
    End Sub
 
    Private Sub OnSendCompleted(ByVal res As IAsyncResult)
        If Not _disposedOf Then
            Try
                Console.WriteLine("Data Sent to client.")
                _client.EndSend(res)
            Catch ex As ObjectDisposedException
                Me.Dispose()
            Catch ex As Exception
                Console.WriteLine("Could not send data to client:")
                Console.WriteLine(ex.Message)
                Console.WriteLine()
                _client.Close()
            End Try
        End If
    End Sub
 
    Private Sub OnInitSendComplete(ByVal res As IAsyncResult)
        If Not _disposedOf Then
            Try
                Console.WriteLine("Init package sent to client.")
                _client.EndSend(res)
            Catch ex As ObjectDisposedException
                Me.Dispose()
            Catch ex As Exception
                Console.WriteLine("Could not send init package to client:")
                Console.WriteLine(ex.Message)
                Console.WriteLine()
                _client.Close()
            End Try
        End If
    End Sub

I haven't seen anything that indicates the data's out of sync since I've made this change. I can't reproduce the problems I was having yesterday with this new modification.

I am having problems with my socket connection collection being changed while in the middle of sending data to the clients. I think I'm going to have to look into using a proper, thread safe, object for this collection now...but this is a whole different issue.

I think I've solved the problem...for now at least.

Thanks again for your help :)

[Frinavale]

@Plater
Ok, the data's all mixed up now!
Now, I'm experiencing what you were getting at earlier.

Before the socket server was sending the file when a timer ticked. The timer was slow and this allowed the sending process to work properly. I've removed the timer and the socket server now sends data whenever a file has finished being read into a byte array.

What I noticed was that the initializing package was being sent several times before the actual data was sent....and sometimes when the data was being sent a new initializing package would be sent.

The client corrects itself when the data doesn't fit properly so the images are being displayed (very rapidly) but it's constantly losing data too.

I'm looking into using the IAsyncResult to solve the problem....except that I don't have a reference to this when the data's being sent so I'm not able to make the thread wait until both the init package has been sent before the actual data has been sent....and wait until data has been sent before the next init package.

The problem is that there's synchronized processing that has to take place in an asynchronous setting.


I'm not sure if I'm approaching the problem correctly (trying to fix the problem on the Server side of things) so any guidance at this point would be greatly appreciated.

This mini project has been a really interesting adventure!

[Plater]

I would say you might need a custom object, and then a colelction of them.
Whenever you get an intializing package, create an object and stick it on the collection. Use the socket's port# as a unique id (should work, i'm hoping) and maybe track the DateTime that it came in as.
Any data that is not an init package, gets appeneded to the data stored for the correct object, based on the socket port.
Once all the data (based on your init package's datasize) is in place, you can use and remove the object from your collection.
Same thing with if it hasn't received any data packets for awhile, or if you get another init package with the same port number (assuming they were coming up as different). Just wipe out the old object completely.

[Frinavale]

I changed the implementation back to pre-pending the size to the byte array (the file) being sent to the client.

This avoided the situation where the init packages didn't match with the data being sent.

I started experiencing other exceptions with this method but I think that they were mainly being caused by the speed at which I was sending the files. Every time the server read a file it sent it to the client (asynchronously), then read the next file.

I think that the garbage collector in the client could not clean up the released arrays fast enough and I would quickly get OutOfMemoryExceptions.

I returned to using the timer...setting the interval value to 10.

I ran the app for a good minute or two before I decided to update this thread. It didn't throw any exceptions until I opened the browser ....hmmmm out of memory again.

There's got to be a better way to do this. I don't know if I can actually use this timer method to stream data from the physical device when I start interfacing with it. It would be best to figure out how to avoid this problem now before I start the real project.

-Frinny

[Banfa]

I haven't read the details of your attempts but I thought some information on TCP/Sockets might be useful.

A TCP connection is a stream, that is the data is not packetised. While it is true that the transport layer packetises the data for transmission across the network at the level where you send and receive data to/from the socket it is, and needs to be treated as a simple byte stream.

One of the effects of this could be, for instance, if you sent 2 small items (or images) in rapid succession from the source then the network protocol layer might well place these into a single transport layer packet. The result would be that your receiver would only get 1 notification of data to read. In general you may not get as many notifications of data available as the number of times you sent data because of the transport layers ability to concatenate data for efficient transmission.

Another is that the transport layer has no way of knowing the size of the data objects you have encoded into its byte stream.

TCP provides the following guarantee, if data arrives then it is correct and it arrives in the order it was transmitted. If 2 images arrive mixed up in the stream it can only be because the data was transmitted in a mixed up fashion (or some wired .NET effect that I take no responsibility for).

I thought some additional knowledge of the underlying transport mechanism might help.

[Frinavale]

@Banfa
So this would explain why my idea of sending an "init" package before the data was not a good idea. It's a simple byte stream, not actual packets I'm dealing with.

Ok this is starting to make more sense.

@Banfa
I'm going to look into a way to determine if 2 or more items are in the stream. I never considered using a Stream object instead of a byte array....

@Banfa
This much I knew from my research (although I didn't know it when I originally asked the question). I've encoded it into the byte stream to get around this. But I'm wondering if I can use an actual Stream object instead of a byte array.

@Banfa
What is the order when everything's asynchronously sent.....hmmm.

@Banfa
It wasn't that the images were mixed up it was the problems I was facing by sending a separate "init package" before the actual data stream.

@Banfa
Thank you so much!
You've given me a lot to consider.

[Frinavale]

I cannot use streams because of the limitations of the controls I'm using.

I think that the control is taking the TCP stream and breaking it up into several pieces... it fills a buffer with the data. The buffer is a byte array.

Things are messed up when I try to put it back together again in the client.

I'm taking what's in the buffer and appending it to a byte array.

In order to determine how big this array is I've pre-pended the file size to the file sent down. When receiving data I fist grab the size of the file and start filling the array with what's in the buffer.

When I increase the frequency that the files are being sent down to the client something gets messed up.

When I finish reading in the the amount of bytes I'm expecting I try to grab the size of the next file....but sometimes the file sizes I grab are Huge. This is why I'm running out of memory. I think that it's grabbing the size from the middle of a file instead of the beginning:

@Banfa
I think this is how everything's being thrown out of sync.

[Plater]

I wish I had a good way to test out these things for you finny. I have not done anything with silverlight really (Save for a brief example from TR )
I suppose I could just make a project that uses the send/receive async calls and it should be the same yes?

[Frinavale]

I could post what I have but it's a Really big mess right now.

PS re-read my previous post...I've edited it.

[Plater]

Could you tell the server to not push the next file to the client until the client says its ok?
The only thing I can think of is that another even is coming in(and starting being processed) before you have finished with the previous event's handler code? (Known as re-entry)

[Frinavale]

I can't really tell the server to wait before sending the next image because I'm not entirely sure what my physical device is going to be sending in the future. Depending on the device manufacturer, it could be images or it could be streaming video that has no end. The first device that I'm going to be integrating with will be sending raw byte data of images.

Right now I just want to get the images to work. I'm not even connecting to the device...I'm simply reading files off of the hard drive and sending them down to the client.

I think that Banfa was on to something when he mentioned that more than one image is being placed into a single transport layer packet.

Instead of just displaying an error stating that the file doesn't fit I'm reading the amount left of what I was expecting....

Then I restart the process right there....reading the next 4 bytes to determine the size, resizing the _retrievedData array for the new file, and fill it with the remaining bytes in the buffer.

It works.......................kind of.

[Plater]

You were not reading the exact amount you needed for each file, but were instead reading everything that was available and filling in your byte array from there?

Think of the TCP connection as a lazy front desk clerk. The clerk only looks up every once and awhile to see if someone is waiting and buzzes an office to notify them(think windows events). Sometimes there is no one, sometimes only one person (think one byte) and sometimes multiple people are waiting by the time they look up.
So X amount of people(bytes) could make it to the desk by the time the clerk goes "hey someone is here". Maybe they are all with each other as a group (or part of your image) maybe there is more then one group there.
The clerk just buzzes in however many "people" are seen and then looks back down. The next time they look up and see people, they will buzz them in too.
Each of those buzzes will be your receivedData event.

With a big image, not all the bytes will arrive before the clerk buzzes them in. And the next time the clerk buzzes, there could be part of the next image in with it.

So you need to only read exactly the amount of bytes you need (as the value you send before the image) and if there is MORE data available to be read in your receivedData event, you need to start over and read the byte size and start reading/appending data again.

As a side note: I should probably be banned from making annalogies.

[Banfa]

So I have some experience of this sort of scenario. I worked on a system where a microprocessor had to receive an image from a IP Camera, it then retransmitted the image over a GPRS link to a server. Because of the nature of the GPRS packet switch radio link the maximum size of a packet is about 1500 bytes. We had some overhead so I split the images into 1024 byte blocks to send. We sent a 2 byte start of block indicator, a 2 byte block size (because the last block is not 1024 bytes) some other data that isn't relevant here, the image data block and finally a checksum. On TCP IP the checksum is strictly speaking not required but our protocol was design to also work using modems on a PSTN.

The receive routine looked something like this (in pseudo code)

PERMANENTSTORE   ExpectedSize
PERMANENTSTORE   DataBuffer
PERMANENTSTORE   CheckSum
PERMANENTSTORE   State = FindFirstStartByte
 
FUNCTION SocketDataReady  // Called when the socket has data to read
 
  LOCALSTORE Byte
  LOCALSTORE Status
 
  Status = ReadByteFromSocket INTO Byte
 
  WHILE STATUS == OK
 
    SWITCH State
    CASE FindFirstStartByte
      IF Byte == FirstStartByte
        State = FindSecondStartByte
      ENDIF
      BREAK
 
    CASE FindSecondStartByte
      IF Byte == SecondStartByte
        State = GetFirstSizeByte
        ExpectedSize = 0
        CheckSum = 0
        CLEAR DataBuffer
      ELSE
        State = FindFirstStartByte
      ENDIF
      BREAK
 
    CASE GetFirstSizeByte
      ExpectedSize = Byte << 8   // Assuming Big Endian Protocol
      State = GetSecondSizeByte
      BREAK
 
    CASE GetSecondSizeByte
      ExpectedSize = ExpectedSize| Byte
      State = FindFirstStartByte
      BREAK
 
     CASE GetData
      PUT Byte INTO DataBuffer
      UPDATE CheckSum WITH BYTE
      ExpectedSize = ExpectedSize - 1
      IF ExpectedSize == 0
        State = GetCheckSum
      ENDIF
      BREAK
 
    CASE GetCheckSum
      IF TransmitedCheckSum == Byte
        PASS DataBuffer TO ImageHandler
      ENDIF
      State = FindFirstStartByte
      BREAK
    ENDSWITCH
 
    Status = ReadByteFromSocket INTO Byte
 
  ENDWHILE
 
ENDFUNCTION
 

Obviously for use the image handler had to stitch together the 1k blocks back into images which it did successfully and then put them into an SQL Server DB.

Here are the important points about this code though that make it able to handle a byte stream rather than a packet stream

• The receive function does not assume that it will receive only one block every time it is called.
• The receive function does not assume it is receiving a whole block every time it is called.
• The receive function makes no assumption of where it is in the data stream the when it is called for the first time, it looks for synchronisation markers in the stream.
• The receive function checks that when it thinks it is at the end of a block it actually is at the end of a block. In theory on TCP using a checksum for this is very over the top and end of block marker should work just as well.
• Having received a block the receive function does not assume that it is automatically at the start of the next block but looks for the synchronisation marker again.

Im some ways this should not be necessary over TCP/IP, however every protocol I have ever seem does something like this.

If you are worried about the underlying correct functionality of you libraries then write a little program that transmits like this

UNSIGNED STORE Byte = 0
 
OPEN SOCKET
 
FOREVER
  SEND Byte TO SOCKET
  Byte = Byte + 1 // Assuming that 255 it will wrap to 0
ENDFOREVER
 

It should be simple to receive and verify that you are receiving every byte transmitted.

[Frinavale]

@Banfa
I'm not using a checksum right now but it might be a good idea to explore later.

I've used a very similar solution to yours but instead of infinite loops, I'm using something similar to recursion. I had to because of the nature of the asynchronous sockets.

Every time the socket receives data the OnReceive method is called. At the end of this method I tell the socket to begin receiving again.

The important thing was that the OnReceive method was implemented so that it:
@Banfa
My problem was that the function originally assumed that it was receiving a single block at a time.

This problem is solved now. The client is processing everything properly now :) Thank you so much for your advice.

@Banfa
This Very similar to what I'm going to be working with but not at a microprocessor level, and it's not just one camera...there's several channels.

When I remove the timer from my server "PictureGetter" component and simply push the images as soon as I read them in I'm running into a problem.

Sending the pictures using socket couldn't be preformed because "the system lacked sufficient buffer space or because the queue was full".

Is this happening because it's placing too much into a single transport layer packet?

How did you get around this problem?

[Plater]

Somewhere you had to tell a listener socket to Listen(), which means you had to supply a backlog (how many connections can be "waiting to be accepted" in this case) You are probably filling up that as the queue being full?
As for an overall statement, the camera can probably produce more pictures then the bandwidth between applications will allow. Just something you need to be able to trap and recover rfom I would guess

[Frinavale]

@Plater
The server's listener allows 10 connections to wait.

I don't know if that's the case....I only opened 1 socket connection to the server.

The server pushed many images but the client stopped receiving them very quickly. The computer's fans turned on because it was working hard...and I was really tempted to stop the server process but I waited it out see what the exception was.

@Plater
Slow it down on purpose to reduce the bandwidth?
It's a possibility I'll keep in mind.

[Plater]

No I mean your bandwidth might be a bottle-neck, you will have to be prepared to "skip" images if you cannot send them. (Get your FPS figured out that way)
Just what kinda of computer are you using as a server? Something from the mid 90s? It should not be baulking at this little of a task?

[Banfa]

@Frinavale
Well you have to remember that I was using a low power microprocessor connected to a self contained GPRS modem module. Given the data sheet of the GPRS module it was safe to assume that the power in the GPRS module in terms of processor power and available memory far exceed what I had available on the microprocessor so anything I could do it could cope with.

I suspect you problem may be at the interface to the TCP stack coupled with your speed of transmission. The TCP stack is what handles the data transmission for you. When you send a byte through a TCP socket what you actually do is queue it on the TCP stack for transmission. The TCP stack sends the byte but can't discard it until it has received the confirmation that it has arrived.

TCP automatically acks received data and retransmits data not acked (roughly), that is how it guarantees correct reception in the correct order.

If you throw data at the TCP stack faster than it can transmit it then in the end it will run out of buffer space.


You can make an estimate of an upper (unreachable) limit of the number of pictures you can transmit.

For instance if you are sending 50kbyte (on average) pictures down a 50Mbit/s link then you can send roughly

50 * 1,000,000 / 50 * 10(convert to bits) * 1000 ~= 100 pictures / s

I know I've used 1000 instead of 1024 but the calculation is very rough because it does not even include transport protocol overhead for instance. This gives you an idea of the point at which the link will fail. If you are having trouble transmitting 10 pics/s then there is a problem to resolve somewhere. On the other hand in you are trying to transmit 90 pics/s and it is failing then may be you are sending too much.

[Frinavale]

It can handle 100 pictures/second very easily without crashing.

I've decided, for now, just to leave it at 30 pics/sec until I actually start looking at the device capabilities.

This little adventure would have been a lot more frustrating without the both of you here for help. Thanks a lot!

:)

-Frinny

[Frinavale]

@Plater
:) will have to check this out later.

@Plater
Haha :)
I think it actually might be. It doesn't have a lot of RAM and it's a processor that I used to use myself years ago (Pentium D)

I hate my DEV machine :) <--- fake plastered smile

@Plater
Precisely why I hate it so much.
It tortures me with making me wait when I'm in the middle of some thought process...sometimes I even forget what I was doing/thinking because it takes sooo long.

[Banfa]

No under-power DEV machines are good because if you can get it working on that then there certainly should be a problem when you install on the brand spanking new production machine.

The problem is if you do it the other way round, that is a sure route for disaster.

[Frinavale]

@Banfa
That's my boss's' exact same reasoning for not purchasing more RAM for my poor machine.

*eyes Banfa* conspiracy?

[Plater]

@Banfa
That only works if the difference is not too significant.

[Banfa]

No if the software is correctly written in a robust manner it should work all the time. One of the main issues is using time for your timings and not processor clocks.