[PD] new [tcpserver]

[Martin Peach]

Martin Peach wrote:
> Roman Haefeli wrote:
>> On Sat, 2009-03-07 at 19:54 +0100, Roman Haefeli wrote:
>>> hi again
>>>
>>> a new stupid little problem occured. when working with [tcpserver], i
>>> usually identify the clients by their socket number and not by their
>>> client number; for two reasons: when a message is received or a new
>>> client connects, you can only know the socket number of it (since there
>>> is a dedicated socket outlet), but not the client id. the other reason
>>> is that socket numbers are persistent, while client numbers might
>>> change, if one or more clients disconnect or get disconnected. my
>>> problem is, that the new status outlet and also the method to set
>>> internal buffersize is based on the client number. it's not a that big
>>> problem, since whenever i sent a message to a socket number i will know
>>> the client number as well. but when receiving messages, you don't know
>>> which client it came from. i though about building a look-up table in
>>> order to look up a socket for its client number, but this is not very
>>> feasible, since the client id might not be valid anymore after one or
>>> more disconnects. 
>>> what i want to say, that it is currently not handy to use the new
>>> features, because you are forced to work in both domains, client and
>>> socket, at the same time. personally, i would prefer if everything would
>>> be socket based and i think, if you want to change it, then better now
>>> than later.
>>> another solution (though uglier, imho) would be to implement an internal
>>> look-up: 'get_client_id <socket>' -> [tcpserver] -> 'client_id <client>'
>>> to the status outlet.
>>>
>>> what do you think?
>> i just found out, that there is already something as a look-up table:
>> when i send 'client' or 'client <client-id>' to [tcpserver], i actually
>> get all necessary information.
>>
>> sorry for the noise.
>>
> 
> That's ok, but I've noticed that socket numbers are always in the 
> hundreds while client numbers count up from 1. It would be easy enough 
> to add a bit of code so that if the first number in a [send( message 
> didn't match a client, it would be interpreted as a socket. Do you ever 
> get overlap with client numbers and socket numbers?
> 

Actually if you use a [send( with [tcpserver] the first number is the 
socket number. If you use a [client( message the first number is a 
client number. I guess I meant to say that when you send a message 
containing only floats the first number is supposed to be a socket 
number, but it could also be a client number if the clients are always 
under 100 and the sockets are over 100.
Also the 'sent' output could easily give the socket as well as the client.

Martin