Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jibwa

Pages: [1]
1
Network / Re: Host TCP Port and Receive details
« on: August 07, 2013, 11:18:17 pm »
Great, cheers Laurent!

2
Network / Re: Host TCP Port and Receive details
« on: August 07, 2013, 02:40:00 pm »
It's not just easier, it's also more correct. The potential issues with endianness and types size are explained in the packet tutorial.

I had certainly missed this.  I hadn't appreciated that the overloaded << and >> operators would mean that Packet endianness was sorted properly, but that using .append and .getData wouldn't.

That's a strong case for defining << and >> for my structs.  I wanted to avoid this because if I add something to my struct, I have to revisit the << and >> definitions.

Also, just a quick question, if I have a struct containing an array, I'm assuming it's ok to do something like:

typedef struct _MyStruct{
  sf::Int16 ID;
  sf::Int32 aData[32];
} MyStruct;

sf::Packet& operator <<(sf::Packet& packet, const MyStruct& m)
{
  int i;

  packet << m.ID;
  for(i=0; i<32; i++)
  {
    packet << m.aData[i];
  }

  return packet;
}
 

Does this work?

3
Network / Re: Host TCP Port and Receive details
« on: August 07, 2013, 12:10:59 am »
Ok, I've stuck with TCP, and am using the Packet class.  I think they're pretty easy to use in conjunction with my existing structs because I can just use the Packet::append() member function to copy the entire struct in one go, and can read it out again with the Packet::getData() member function.  Simples! 8) (Haven't checked it works yet though...  ;D)

4
Network / Re: Host TCP Port and Receive details
« on: August 06, 2013, 09:27:05 pm »
Ok, that's great, thanks for the information.  That makes sense with the port number, it's as I would expect, and I got confused regarding other info concerning sockets that linger after they're closed.

After some thought, I am now considering using UDP rather than TCP, since I intend for each "packet" to contain the info needed to work out where it belongs, and if any are missing.  When I started out, I hadn't realised that TCP was a streaming protocol (noob), and had assumed that when you sent a packet, the other end would receive a packet.  Indeed, this is what my initial experiments have produced, so I'm glad I've found out now that I would need to consider the case where I haven't received a full "packet".  If I need to handle that manually, then I may as well work with UDP which also requires a bit of extra work.  Hmmm, decisions...

5
Network / Host TCP Port and Receive details
« on: August 06, 2013, 04:30:25 pm »
Hello,

This is my first post, and I'd like to start by saying I'm very impressed by SFML.  It does exactly what it says on the tin.

I have a few questions regarding TCP sockets:

1) I'm setting up a host, which will need to be connected to by several clients.  (I've read about socket selectors, that's not what my question's about.)  Regarding the use of using a single Port on the host, I seem to be finding conflicting information.

The tutorials typically use a TcpListener, which is told to listen on a particular port.  Let's say 51000.  Then in the examples, if this socket finds a client, a TcpSocket is set up (which inherits port number 51000), and the Listener continues to listen.  As each client connects, local port number 51000 is reused in the local socket.  So we end up with a lot of sockets where the local address and port are the same as each other.

According to http://en.wikipedia.org/wiki/Internet_socket
"A server may create several concurrently established TCP sockets with the same local port number and local IP address, each mapped to its own server-child process, serving its own client process."

So this all sounds ok.  However, I found this post: https://github.com/laurentgomila/sfml/issues/150 where it was stated (although it was 2 years ago) that the behaviour of this arrangement is "basically undefined", and that different operating systems will behave differently.  This makes it sound like I want to avoid the setup I've just described above.

So my first question is: what's the latest on this?  Is it ok to have a host listening to lots of clients all through the same port, or is it not?

Ok, second question.  Probably simpler:

If I have an established TCP connection between a host and a client, and say the client sends 100 bytes data, then I understand that because TCP is a "stream", then the host at the other end may not get this all at once. 

If on the host I have configured the socket to be non-blocking, and I call the receive function, I can expect sometimes that received will be less than I was expecting?  Lets say I only receive 90 bytes (out of the 100 I need to get my full "packet").  In this case, what's the best way to handle it?  Should I wait until the next time I call receive, and then use the data to fill in the rest of my struct?  Is this the point of the Packet class?

Many thanks in advance.

Ollie

Pages: [1]
anything