|Keep It Simple, Stupid|
Server/client sync - when can I write to a socket?by techcode (Hermit)
|on Oct 29, 2008 at 19:01 UTC||Need Help??|
techcode has asked for the
wisdom of the Perl Monks concerning the following question:
EDIT: I read that in Perl working with sockets is just like working with file handles - and in some weird way assumed that both sides can't write to it at the exactly same time. That of course makes sense IMO for (one) file - but not quite for the sockets - so can both sides write at the same time?
If they can indeed both write at the same time - and read what they are receiving (if there is anything - will use can_read() to check) when they want (when they are not sending) - then I'm all settled and clear. Each operation is accompanied by some unique (circulating 00 to 99) number - and it's response to the other side also includes that number.
I need some guidance regarding network programming - and specifically it would be excellent if someone has EMI/UCP protocol experience.
My first hope was to use Net::UCP or Net::EMI - just like I did with excellent Net::SMPP - but I just can't get either of these two to work. Finding out that in reality only a small subset of operations (commands) defined in EMI/UCP protocol is still in use today (for SMS's anyway) (and I need even smaller - getting to ~ 5 commands) I would like to give a shot at writing my own implementation.
I understand almost everything but one thing - how is synchronization done? I see there are commands that server initiates (sms delivery report as one of them) - and I wonder how can I know when I can write to a socket?
EMI/UCP specification leaves much to be desired (docs of Net::EMI and Net::UCP even more so) in terms of explaining the "whole forest" and not just specific "trees". So if anyone knows specifically for it - but even in general network programming - how does one sync up the server and client and ensure that they are not both trying to send at the same time, and there are no lockups (race conditions).
Is IO::Select and it's methods can_read() and can_write() enough of a check? I keep wondering - especially since the other side might try to write in the time our first write packet reaches the remote side so it's can_write() still returns yes you can write ...
OTOH as I understand in most (all?) protocols it's actually only one side that can initiate the write (if only one socket is used for communication) - either send something or ask "do you have anything new for me?" and then wait for the other side to respond - am I on the right track?
I also see that operations in UCP that are not response (ACK, NACK) contain a field called MMS (more messages to send) that I guess means - here you have this, but I keep the write permissions after you send me back ACK/NACK?PS. All I need is a way to connect to server (UCP SMSC), login, send a message (a lot of them actually), receive the delivery notification (for all the messages) and perhaps do a ping (alert operation 31) as a "keep alive". But in lack of existing UCP SMSC software - I need to first write a dummy one - to be used for testing.