Determining the size of data being sent from Socket Server

[Frinavale]

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?

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.

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 from I would guess

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]

When I remove the timer from my server "PictureGet ter" 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?

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]

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)

:) will have to check this out later.

Just what kinda of computer are you using as a server? Something from the mid 90s?

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

It should not be baulking at this little of a task?

Precisely why I hate it so much.
It tortures me with making me wait when I'm in the middle of some thought process...somet imes 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]

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.

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

*eyes Banfa* conspiracy?

[Plater]

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.

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.