Re: [PD] new [tcpserver] (was: pd and tcp: what to do against crashes?)
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. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
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? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
On Sat, 2009-03-07 at 14:30 -0500, 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? yes, i do. depending on the box, where the server runs, i get socket numbers starting from 4 (debian lenny) or 8 (ubuntu hardy), though on windows xp they seem to start at 432. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
