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 - watarok

Pages: [1]
1
Network / Re: Match user's TCP sending speed
« on: August 02, 2014, 07:22:24 am »
The whole point of this thread was to explain that such a limit is pointless...
Actually the point was to avoid overflowing the user's socket buffer with data. :P

What you must understand is that limiting the data transfer rate is done as a convenience for the user.
It was my plan to implement this to avoid taking over the user's bandwidth. But you're right that this is not a critical feature. I should focus instead on sending data in the first place. :-\

2
Network / Re: Match user's TCP sending speed
« on: August 01, 2014, 02:11:42 am »
There's nothing he can do in general... not only with SFML :P.
Hmm, that's unfortunate. I suppose I could just implement a modest limit and hope it works on most systems. Or leave it to be user-defined.

Yes, we could think about adapting sf::SocketSelector accordingly...
Well, I'm glad I was able to do my bit for SFML's (potential) development. :)

3
Network / Match user's TCP sending speed
« on: July 30, 2014, 04:11:36 am »
I wish to send some arbitrary amount of data across a TCP connection. I expect that there will be a problem wherein the size of the chunks of data will be too large or the frequency at which they're sent will be too great, resulting in a backup of data being sent.

For example (pseudo):
sf::TcpSocket socket;
// connect socket
while(!endOfData) {
    socket.send(/*a chunk of data*/);
    // get next chunk of data
}
 

Now if data is being queued for sending faster than the socket can actually send it off, there will be a backlog of data that hasn't really been sent. I therefore want to reduce the speed at which it is sent.

My solution:
sf::TcpSocket socket;
// connect socket
while(!endOfData) {
    sf::Socket::Status status = sf::Socket::NotReady;
    while(status == sf::Socket::NotReady) {
        status = socket.send(/*a chunk of data*/);
    }
    // get next chunk of data
}
 

This now tries to send the same data until the status returned isn't sf::Socket::NotReady. This seems like the logical solution, but I'm not sure that this is the actual status returned in this situation (when the socket's buffer isn't empty).

How can I regulate the sending speed of a TcpSocket to match the user's system? Furthermore, is it also possible/recommended to match the receiver's download speed as well?



PS: The examples above are not meant as actual implementations, but rather only serve to demonstrate the problem.

4
Network / Re: Linking clients and servers on a local network
« on: April 01, 2014, 03:31:54 am »
Thanks for all of the responses.  :D

I think I'll end up using the broadcasting method due to its simplicity and the small scope of my project. I'll keep the master server idea in mind for more serious projects or for non-local connections.

5
Network / Re: Linking clients and servers on a local network
« on: March 31, 2014, 05:10:38 am »
By the way, are you bound to TCP?

No, I've used UDP in the past.
The system I've previously used involved the client prompting the user for the address and port number of a server to which it would then send a request to connect.

Ideally, the user should be given a list of available servers on the network. My plan was to accomplish this by broadcasting. This would give two options: the servers must advertise their presence, or the clients must send a request to which the server(s) would respond. Since it doesn't seem like a good idea for servers to constantly broadcast, I would have the client send an individual broadcast to the servers. To this end, I would need to specify a port to which the client's request would be sent on each machine. This same port number would have to be used by each server for them to receive the client's message and to reply. The only problem I found with this approach was that a server could not use another port if the specified one is taken.

I'm wondering if there's any flaw in my approach or if there's a better alternative for a client to receive a list of servers.

6
Network / Re: Linking clients and servers on a local network
« on: March 31, 2014, 01:41:37 am »
Sorry that I'm being unclear, but I'm not trying to have multiple servers running with the same port on the same machine. What I was wondering was how to best make clients and servers aware of each other.

When broadcasting, you can send to all computers, but you still have to specify a port number, say 8025. If the client broadcasts a request for servers, I believe that all of the servers on any machine in the network would have to be on port 8025 for them to receive the client's request.

The problem with this is that if port 8025 is being used by some other program, then that machine cannot run the server. This therefore doesn't seem like a great method to ensure connection between clients and servers.

7
Network / Re: Linking clients and servers on a local network
« on: March 30, 2014, 05:50:50 pm »
Using multiple servers on the same machine / port is not usual. Why would you need to do that?

I agree, I don't know when it would be necessary to have multiple servers on one machine, but it seemed like I should try to leave the possibility open.

What I meant by sharing a port is that each server, regardless of machine, would have the same port number. This was only necessary because, as I understand it, a client should broadcast a request for available servers. This would be sent to each machine, but only to the specified port on each. This is why I thought that servers would have to have a common port number.

If this is not the case, by all means correct me. :D

8
Network / Linking clients and servers on a local network
« on: March 30, 2014, 08:55:35 am »
I have a system where clients are meant to connect to a server located on the LAN. It seems unreasonable for users to have to enter the address and port of a server, so I was planning on using broadcasting. The problem I'm facing is how it's possible to make all clients aware of all available servers.

As far as I'm aware, broadcasting only sends to a specific port on each computer. This seems to mean that either all of the clients or all of the servers need to have a common port number. Logically, there would be less servers, and it's more likely that they'll be able to bind to a shared port. This is still unreliable and limits each computer to a single server. Is there a better solution that I'm missing?

9
Feature requests / Re: Direct access to window focus
« on: November 17, 2013, 04:04:52 am »
This isn't present in SFML 2.1, but is still, I believe, a feature that should be added.

Pages: [1]