Segmentation error popping up

[dwhitney67]

...
Not really. Note how data is defined:

Uint8 data[strlen(message)+1];

So if message length is 11 data is data[12] and I'll loop from 0 to <12 ie 0, 1...11.

Can't see I would see. I added +1 specifically because it crashed before I sent it even once before.

Yeah, I guess the issue is not in the for-loop, but as others have mentioned, in the declaration of 'data'.

BTW how does one approach creating system where one server speaks(both way) to multiple clients? I figured I would have server listening port X. Clients contact them and say they want to talk to them. As far as I can tell UDP packet contains senders IPaddress in it so would it work if I save that to arrays containing clients and then when I need to talk I can send it back?

Your server can retain the foreign address and port used by a client to respond at a later time if necessary.

Should there be more than one port for server(well probably anyway if there's multiple clients...).

Typically a simple UDP server will only require one port. Individual clients can communicate using the same port.

Whatabout clients? Should they have one port for listening and one for sending? And send the listening port in the opening message?

A client should not have to listen; I believe it is only required by the server, when using a connection-based protocol (i.e. TCP).

Some more ideas for the server side code(I think that's the trickiest one since it has to deal with multiple clients AND do the stuff it's supposed to do). Would it be good idea to split the program to multiple threads? One for handling connections(accepting new ones, managing old ones etc), 1 for parsing messages from clients connected and acting through them, one for doing global stuff affecting _every_ client and maybe one for sending messages back(or maybe this one can be integrated to 2nd thread). Might make it more complicated but at least it should in theory work faster? Would Linux take use of multiple processors in computer this way(running each thread in own processor) or would there be more work to do?

For a busy server, using multiple threads can speed up the processing of messages, by using one thread to receive messages, another thread to process the messages, and perhaps yet another thread to respond to the client with a response.

If you plan to use UDP, there are no "connections" by peers. It is connectionless.

Seems like would be good practical use to try thread coding(obviously starting with less complicated stuff with aim of incorporating it to this one).

Get your client/server applications working first before jumping into multi-threaded programming. Unless you are expecting your application to process hundreds (perhaps thousands) of messages per second, you may not need to make it into a multi-threaded application.

P.S. Try to see if you can build the example client and server applications posted within the tutorial I posted earlier. If you design your application "correctly", you should be able to develop your own library that is based on the SDL_Net framework. Your application should be unaware of what framework is being used. For instance, your library could have a functions such as:

void Send(const char* msg, const size_t msgLen, const std::string& foreignAddress, const unsigned short foreignPort);

int Recv(char* msg, const size_t msgLen, std::string& sourceAddress, unsigned short& sourcePort);

The obfuscates the dependency of the SDL_Net framework, including the need to maintain the socket handle.

[tneva82]

A client should not have to listen; I believe it is only required by the server, when using a connection-based protocol (i.e. TCP).

If client isn't listening how client knows server has just sent him information that he needs to act? I would need both sides to send messages to each other and act on them rather than just one way around. That's the thing that tutorial is lacking. It has just one way around posting. How would it work if I want to send data back(even if something as simple as acknowledging that yes I received your message!).

[dwhitney67]

A server cannot initiate contact with a "true" client. Typically the first thing a client will do is send a message to a server, then perhaps await a response. The server cannot send a response (a message) to the client unless it has the client host/port information.

If initially a "client" is waiting for a message from another peer, before it has ever made contact with this peer, then in essence it is a server. The peer would have to know the host/port that this "client" is using.

Does any of this make sense? Basically, it boils down to semantics as to what defines a client vs. a server.

P.S. An Apache web server does not initiate communications with my web browser; my web browser (the client) initiates communications.

[tneva82]

A server cannot initiate contact with a "true" client. Typically the first thing a client will do is send a message to a server, then perhaps await a response. The server cannot send a response (a message) to the client unless it has the client host/port information.

Yes. Basicly my idea so far is:

Client sends message to server telling server I wanna join in! In this message(apart from command join) might be parameter to port number client is using for receiving packets(this is what I mean by listening) assuming client has to use different to read packets than to send. Then server assigns id for client for the session(first available) and sends reply to client containing session id. Address would either be received from clients packet it received(I thought I read somewhere it would contain senders address) or alternatively from data message received from client.

Then communication would proceed sending messages according to program's logic with client passing it's clientid to server so that server knows WHICH client sent the message.

I think I wrote poorly before what I meant(never did I think server would be starting up session. Sorry if I caused misunderstanding ) but above is how I figured this would work. Does above make any sense? And then few clarifications to help making it a reality.

a) where the server would pull needed address. From packet's address field(I could swear I read it is changed on it's way to contain senders address) or should that be part of clients message?
b) does server need to use different port for receiving and sending?
c) same for client. Can it use same port for receiving and sending or different ports?

[dwhitney67]

The quick answer is yes, the client can use the same port for sending/receiving. Similar for the server.

On the server side, make sure that you bind() the port being used. Sometimes it is necessary/prudent to do.

Now I have to run off to work...

[tneva82]

Now I have to run off to work...

Thanks. Much appreciated! I'll start working on simple server/client program to test how this works.

Again big thank you!