Socket Server Logic

[Nancy P]

My question is more about basic flow than filepro but I am using filePro sockets to serve data.  What I am not sure of is this:  Does the socket process sequentially or simultaneously?

What I mean is that if two different requests hit the socket at the same time, does filePro handle one then the other or does it handle both at the same time, generating two logical flows at the same time.

The speed of this logic makes it hard to determine this by example.  My issue is that I am getting odd "seg violation" errors that seem to have no explanation and I am wondering if I should be looking at issues related to multiple requests happening at the same time, or stay within the one session to insure more reliable results.

When the code works flawlessly, 1000 times and then fails with a seg violation in a very simple place of code, it leads me to wonder.

Is there a logical point in the server logic where it should return after each request is finished to wait for the next request?

I have been looping around to the accept() point once a socket has been opened for a listen().

Thanks for any enlightenment on this stuff.  It might have been better to have learned sockets in another language to better understand the basics but I work in a filePro world and I always struggle with these new concepts from the top down instead of the bottom up.

[kenbrody]

filePro processing is single-threaded.  If two connection requests were to come in simultaneously, accept() would return one connection (which one is determined by the O/S -- I would assume FIFO) and the other would wait until you were to accept() another connection.

Depending on what your program is going to do with the requests, and how long they will take, would determine how you should handle multiple requests.

You could, for example, break down the requests into partial steps, checking for additional incoming requests (using SELECT on the listening socket) along the way, and looping through each step of each of the client connections round-robin style.

If the process is "fast enough", them you could get away with handling everything single-file.

As to what would cause a SEGV, I would have to at least see a core file from a debug version of dclerk in order to track it down.

[Nancy P]

This is running with 5.0 on a Linux computer and the segv is not at the same place each time.  It has to be related to memory somehow because ,running as a server, it is never stopping, just looping around and around.

(I do stop it and restart each night, but during the day it runs continuously.)

It is very fast (timed 1000 per sec. with some tests we did).