Sockets, windows, and java ...

[dbrb2]

Hi,

I'm working on a robot navigation projet using java. I am using stepper motors to control a navigation camera, and they are controlled by some software I did not write written in C. Having used sockets in Java they seemed relatively simple.

The C code basically sits in an infinite loop waiting for input. When it gets it, it loops, does some stuff, and we start again. I thought it would be relatively simple to implement a socket to listen for incoming connections on port X for input, rather than from the keyboard as now. This would allow my main java program to control my stepper motors by isuing commands to the port the socket was listening to.

However, windows sockets seem an order of magnitude more complicated than in Java - does anyone have any advice / warnings / hints? Is it far more complicated than I imagined?

Cheers,


Ben

 

[cdlvj]

Is not that bad. And would be a lot better as the process would be inactive, and only come awake when the event happened.

 

[marsd]

So is the C service portion of the program basically an
iterative server blocking on a read from stdin?
If this is the case I would simply add an dgram socket,
bind(), and call select() to wait on both descriptors, stdin and the new socket. Should be pretty straightforward unless
you need something like tls/ssl.

 

[dbrb2]

This is the input segment of the current code:

while(!quit)
{
if (echo_flag) fputs("\nCommand: ",stdout);
fgets(buffer,80,stdin);

........
//do stuff here
}

I've been reading up, and maybe its not as bad as I first though... At the moment I've been thinking I'll need to use a function that is called each time the code reaches the fgets section that sets up a socket, waits for input, retrieves commands, then closes socket again. Seems a bit of a messy method, but is this what I should be aiming for?

Cheers,

Ben

 

[cdlvj]

Several ways to do this, ideally one process should sit on the socket and just wait in sleep mode. The other process is going along and wants to do an event, does a send on the socket, the other wakes up to process the data coming in.

Sometimes just have small programs that just do the sending and receiving and use other means like the msgsnd and msgrcv. That way you can have many programs looking at the main data, and doing the event processing whenever necessary.

The select is to check to see if data is available on the socket, then if it is, you do the read.

You can do it either way, but the 1st is just better because CPU cycles are not being used. We had a app which handled 100 instances of collecting data, and the cpu idle normally was 99%.

 

[marsd]

Yeah, but select() shouldn't suck proc time like that in a well behaved environment with a good scheduler and even
though it is a bit cpu intensive, the alternative: waiting on subsequent reads, blocks on the first and means the second never gets serviced unless it is is asynchronous and signal serviced.

Polling is the best and only method here if you've got more than one descriptor and one process. Or fork/thread a child/thread and handle all the socket code there.

 

[dbrb2]

Thanks everyone. I've had some trouble finding an old enough comiler to cope with the code, but that's sorted now.

I think the above makes sense, and hopefully I'll be ok, though I may need to post again!

I think the way I'm going to attempt to solve the problem is to have the c program call a function when it is ready for input that sets up a socket and sits listening till data arrives, at which point it returns this data as the input to the progrm and closes the socket. Two problems with this - the time taken setting up and closing the sockets each time (significant?) and the error recieved if data is sent while the c program is not ready for the data. Howeve, it seems the simplest method, and should work ...

 

[marsd]

Network activity is often highly optimized in modern kernels.
For instance of the 32 possible and six assigned (or so)
softirq bottom half handlers for interrupts in the linux kernel-two are devoted to network tx and rx. C is a
short step up from assembly given a good compiler. Speed
is not an issue IMHO. Higher level considerations like
connection oriented or not,etc..is really a design issue,
and you may see some performance problems as a result of
design or programming flaws.

 

[cdlvj]

Take a look at the fork function.

That way your process would run all the time waiting on the socket. Something comes in, you fork a process to work the information, and loop back to wait on the next amount of data.

 

[cdlvj]

oops, forgot that this is windows, and fork may not be available. You would in that case use threads which can be messy.

 

[dbrb2]

Thanks - I've been looking at the fork() command and it seems that it does not exist in windows. Unfortunately I have been unable to try much out, as I am still missing the neccesary libraries (although not for long...)

I've looked into threads a little. Seems like the nicest solution - used them nicely in Java, but again they seem quite nasty in C. I may end up bodging it slightly (see above), at least for the moment, and just making sure that the main java program leaves a safe inerval between sending commmands, or it it doesn't can cope with the error. Time is passing worryingly fast, and I need to get something working, irrespective of if it is well coded!

Thanks for being so helpful - when I've actually got some code working (or not) I might be back to ask about it again ...